NFV Solution Evaluation Methodology
morrowc.lists at gmail.com
Wed Aug 3 14:27:57 UTC 2016
On Wed, Aug 3, 2016 at 8:20 AM, Ca By <cb.list6 at gmail.com> wrote:
> On Wednesday, August 3, 2016, Randy Bush <randy at 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
>> 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, ...
More information about the NANOG