NFV Solution Evaluation Methodology

Wed Aug 3 02:08:15 UTC 2016

On Tuesday, August 2, 2016, Kasper Adel <karim.adel at gmail.com> wrote:

> Hi,
>
> I am interested in hearing the approach and thought-process that senior
> people on NANOG are following when presented with an NFV solution. Assuming
> that the exercise at hand is to consider NFV for future expansions of
> Firewalls and L3VPNs or stay with the existing model of what is called PNF
> (physical network function)...i.e : classic routers and FWs.
>
> There are a lot of factors to consider and Vendors will typically give
> their biased opinion, so i'm trying to get my head out of their game, to be
> able to think agnostically about the whole thing.
>
> 1) Product and Service/Support Cost.
> 2) Operation Complexity/Learning Curve. (open source products included).
> 3) X Factors (Those that are never listed but do bite in the back) :
> Quality, Integration with Classic, Migration, Usability...etc
>
> The main goal behind us exploring NFV is the promised cost-saving, so a
> good method to be able to do the math of whether NFV will save opex/capex
> or NOT is definitely needed here and i'm trying to gather guidelines from
> the list.
>
> I think its easier to keep this post high-level, and later dig deeper.
>
> Cheers,
> K
>

Sorry , just a junior person here. Maybe a sr can pipe up later.

But my business cases and associated data points show NFV like SDN
are snake oil.

If you know your requirements, buy / implement the best value solution. You
can call it NFV if that makes you feel better.

There is nothing new under the sun. Running DNS or bgp on linux cough... is
not a new thing.

If you are google or fb and have the best software engineers in the world,
you can express your requirements to your dev team and they can just build
it. And support it.

But i see a lot of folks paying premium for sdn/nfv and tooting their own
horns ... but the needle is not moving

Buyer beware. Ymmv.

CB

Ps. Also, simpler > complex. Lots of $ in this statement.