NFV Solution Evaluation Methodology

Wed Aug 3 16:11:18 UTC 2016

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"

-jim

On Wed, Aug 3, 2016 at 11:27 AM, Christopher Morrow <morrowc.lists at gmail.com
> wrote:

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