nanog mailing list archives

Re: NFV Solution Evaluation Methodology


From: Christopher Morrow <morrowc.lists () gmail com>
Date: Wed, 3 Aug 2016 10:27:57 -0400

On Wed, Aug 3, 2016 at 8:20 AM, Ca By <cb.list6 () gmail com> wrote:



On Wednesday, August 3, 2016, Randy Bush <randy () psg com> wrote:

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.




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, ...

randy




Current thread: