[e2e] j'accuse NFV

[Djamel Sadok]

added value is gained by combining / orchestrating both planes. NFV may
open the way to open network hardware and OS and perhaps cheaper one.
Software development is faster/cheaper than a new hardware project. Take
multicast, just like LDP, a controller may distribute on demand multicast
capable functions to dynamically form an overlay instead of relying on
hardware that supports multicast. Even better, a node may self-appoint
itself with such function.

Djamel


On Wed, Apr 29, 2015 at 8:24 AM, Eggert, Lars <lars at netapp.com> wrote:

> CC'ing the NFVRG, since they may have some opinions here :-)
>
> On 2015-4-29, at 11:34, Jon Crowcroft <Jon.Crowcroft at cl.cam.ac.uk> wrote:
> >
> > Try as I might, I cannot really see Network Function Virtualization as
> much
> > more than yet another telco landgrab on internet stuff. But somewhat more
> > critically, I vew the idea of taking some of our precious middle bodily
> > fluid flow processing functions, and moving them a) off the box built by
> a
> > middlebox expert, and b) off the direct path, as actually
> > counter-productive. Lets just take three boring
> run-of-the-arithmetic-mill
> > such services:-
> >
> > load balancer - this is on the latency critical path before you get to
> any
> > service - additional latency/hops/virtualization overhead is
> > counter-indicated by any sane business model
> >
> > wan accelerator - especially for 2.9x-4.8xG wireless data networking
> > services - these are kind of rather localized by definition, right? I
> mean
> > they are dealing with impedance mis-matches in the interweb (tcp splice,
> > etc - see
> > https://www.icsi.berkeley.edu/icsi/publication_details?n=3730
> >
> > firewall (or ids) - so these sit on trust boundaries, so it seems like a
> > reduction in security to move them anywhere (like above a hypervisor,
> > unless people are running, say, seL4:-), plus they might also be
> protecting
> > the infrastructure itself as well as customers, so it would seem
> > counter-productive to increase their attach surface in any way
> >
> > So ok, not all virtualization involves moving stuff to a different
> location
> > often. But it does also imply some resource pooling (i.e. more than 1
> > instance of a Foo in the NFooV is running above the hyperv) - so this
> seems
> > like you might be buying into a wealth of pain with elasticity, when you
> > had just nailed down super-hard multiplexed allocation of cycles for
> > forwarding or filtering or protocol adaptation or responsive redirection
> > etc etc...
> >
> > I guess if you are in the business of proxies (web content caches etc)
> then
> > it might make sense, but then it isn't really a Network Function that is
> > being virtualized - its just you have some server blades running xen
> > or vmware or clickos or mirageOS or whatever with an HTTPd on them
> >
> > - err, so next, will we be running IP forwarding virtualized? oh, no,
> > wait, thats just a, um VPN...
> >
> > so if the telco folks do manage to Virtualize all those annoying middle
> > boxes Netwreck Functions, perhaps they could just cause them all to
> > evaporate and restore the sublime end-to-end internet
> > goodness....carrier-degrade, surely?
> >
> > j
> > http://openmirage.org/
> > http://cnp.neclab.eu/clickos/
> > https://sel4.systems/
> > etc
> > _______________________________________________
> > end2end-interest mailing list
> > end2end-interest at postel.org
> > http://mailman.postel.org/mailman/listinfo/end2end-interest
> > Contact list-owner at postel.org for assistance.
>
>
> _______________________________________________
> end2end-interest mailing list
> end2end-interest at postel.org
> http://mailman.postel.org/mailman/listinfo/end2end-interest
> Contact list-owner at postel.org for assistance.
>