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.
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.
mr by isn't wrong there are lots of ... over sold things.
but, NFV isn't necessarily 'cloud'... It CAN BE taking purpose built
appliance garbage that can't scale in a cost effective manner and replacing
it with some software solution on 'many' commodity unix-like-hosts that can
scale horizontally.
Simpler > complex *sometimes*. It turns out that sometimes the complexity is worth it (eg https://youtu.be/-iiXsbrEv3U ). Perhaps "as simple as possible, by no simpler" would be reasonable?
but, NFV isn't necessarily 'cloud'... It CAN BE taking purpose built
appliance garbage that can't scale in a cost effective manner and
replacing it with some software solution on 'many' commodity
unix-like-hosts that can scale horizontally.
my main worry about nfv is when they need more forwarding horsepower
than the household appliance <tm mo> has, and the data plan is is moved
out of the control plane and they are not congruent. we've had too many
lessons debugging this situation (datakit, atm, ...).
beyond that, i am not sure i see that much difference whether it's a
YFRV or a SuperMicro. but i sure wish bird and quagga had solid is-is,
supported communities, ...
> but, NFV isn't necessarily 'cloud'... It CAN BE taking purpose built
> appliance garbage that can't scale in a cost effective manner and
> replacing it with some software solution on 'many' commodity
> unix-like-hosts that can scale horizontally.
my main worry about nfv is when they need more forwarding horsepower
than the household appliance <tm mo> has, and the data plan is is moved
out of the control plane and they are not congruent. we've had too many
lessons debugging this situation (datakit, atm, ...).
YES! This 1,000x.
The internet is a very interesting place when viewed from the lense of
Automata theory, greedy self optimizing nodes.... very similar to
biological systems (including economics ). Very robust since each node is
greedy and self optimizing in its decision making power. This a
fundamental component of the Internet's suceess.
Some folks talk about sdn controllers and seperating control plane and
forwarding plane. This breaks the ability for nodes to self optimize and
thus undermines a key component of the robustness. It also diverts of the
parallels of biological systems. Control and forwarding had beeb separate
on the node for almost 20 years now.
Sdn is like authoritarianism and divine creation rolled up into one and
sold at 20% premium to easily duped telco types that want to travel to
endless conferences
> but, NFV isn't necessarily 'cloud'... It CAN BE taking purpose built
> appliance garbage that can't scale in a cost effective manner and
> replacing it with some software solution on 'many' commodity
> unix-like-hosts that can scale horizontally.
my main worry about nfv is when they need more forwarding horsepower
than the household appliance <tm mo> has, and the data plan is is moved
this is a scaling problem, and one which points to the need to not do 'all
of one thing' ('all nfv will solve us!') you may still need other methods
to load balance or deal with loads which are higher than the nfv
platform(s) can deal with properly.
In some sense this is the same problem as trying to push too many pps
through a linecard which you know has a limit lower than line-rate.
out of the control plane and they are not congruent. we've had too many
lessons debugging this situation (datakit, atm, ...).
seperation of data/control plane ... does require knowledge about what you
are doing and has clear implications on toolling, troubleshooting, etc.
To some extent this mirrors anycast dns deployment problems. "I made a much
more complex system, though from the outside perhaps it doesn't appear any
different." be prepared for interesting times.
Sdn is like authoritarianism and divine creation rolled up into one and
sold at 20% premium to easily duped telco types that want to travel to
endless conferences
Sure, you have to know what you are doing/buying... magic doesn't exist in
this space.
I struggled with this whole SDN/NVF/insert marketing term for a while at
first, until I sat down and actually though about. When I strip away all
the foo, what I'm left with is breaking things down to pieces and and
putting logo blocks together in a way that best suits what I'm doing. It
is really going back to the way things were a long time ago in the days of
12/2400 baud models and 56k frame relay. It doesn't help vendors vendors
that want to sell you over priced foo for features you don't really need.
It lets you, if you have clue build your own right bits. It will see some
vendors evolve, new vendors of their brand of foo appear and some vendors
die, but end of day, its no different then most of were doing back in the
"good ol days"
The way I see it, the whole SDN/NFV talk has finally devolved into
automation (separating the control and data plane is sooooo 2013).
Automation is not new - a lot of networks have been automating for a
long time now, albeit in custom ways that only worked for them... ummh,
rephrase: was not tested in other networks.
The reason I see SDN/NFV becoming a thing is just to have a standard way
of automating. That's it.
I struggled with this whole SDN/NVF/insert marketing term for a while at
first, until I sat down and actually though about. When I strip away all
the foo, what I'm left with is breaking things down to pieces and and
putting logo blocks together in a way that best suits what I'm doing. It
is really going back to the way things were a long time ago in the days of
12/2400 baud models and 56k frame relay. It doesn't help vendors vendors
that want to sell you over priced foo for features you don't really need.
It lets you, if you have clue build your own right bits. It will see some
vendors evolve, new vendors of their brand of foo appear and some vendors
die, but end of day, its no different then most of were doing back in the
"good ol days"
The way I see it, the whole SDN/NFV talk has finally devolved into
automation (separating the control and data plane is sooooo 2013).
Automation is not new - a lot of networks have been automating for a
long time now, albeit in custom ways that only worked for them... ummh,
rephrase: was not tested in other networks.
The reason I see SDN/NFV becoming a thing is just to have a standard way
of automating. That's it.
That somewhat mirrors my take on it. At the risk of being flamed to hell, I see SDN/NFV being to network operations as DevOps/CI/CM/containers are to dev and systems. Both are bringing in new tools and such, but ultimately they *require* solid automation and having your house (systems, processes workflow) in order to be able to deploy, with the hype train providing budget allocation and sufficient buy-in to get it to fly.
You can do network automation and service provisioning without NFV and centralized SDN controllers, and you can do CM and good tooling without going headlong into DevOps. Obviously SDN/NFV and DevOps have their own pieces that layer on top of that (e.g. control plane / forwarding plane separation and commoditization of the forwarding hardware in the former; development model and "culture" in the latter), and you have to sift through the hype and buzzword bingo to find what if any of that would deliver value in your environment. But, that doesn't mean we can't benefit from the advances and possible standardization in tooling and automation that come along for the ride.
