Re: Has virtualization become obsolete in 5G?

[Mark Tinka <mark.tinka () seacom com>]

On 10/Aug/20 15:15, adamv0025 () netconsultings com wrote:

> Mark, 
> 1) first you have your edge - lots of small instances that are meant to be horizontally scaled (not vertically- i.e. 
> not 40's/100's of Gbps pushed via single Intel CPU) 
> - that's your NFVI.  
> - could be compute host in a DC "cloud", or in a customer office (acting as CPE), or at the rooftop of the office 
> building i.e. (fog/edge computing) -e.g. hosting self-driving intersection apps via 5G -to your point regarding 
> latency in metro), or in the same rack as core routers (acting as vRR), or actually inside a router as a routing 
> engine card (hosting some containerized app).

Nothing new. This happens today already.

The main issue, as discussed earlier, was licensing options for CPE-type
deployments. This is what killed our plan for the same.

But as an RR, yes, since 2014.


> 2) Any of the compute hosts mentioned above can host one or more of any type of the network function you can think of 
> ranging from EPG, SBC,  PBX, all the way to PE-Router, LB, FW/WAF or IDS. 

Yes, but the use-case determines the scale limitations. And there are
many services that you cannot scale by offloading to several little
boxes and expect the same predictability, e.g., a vArborTMS.


>   
> 3) While inside a compute host it's CPU based forwarding, but as soon as you leave compute host's NICs there's world 
> of solely NPU based forwarding (that's where you do 40's, 100's, or even 400's Gbps). 

Yes, plenty of white boxes in the world ready to run an OS and ship with
a version of Broadcom. It's a purpose-built device doing one thing and
one thing only.


>  
> 4) Now how you make changes to control-planes of these NFs (i.e. virtual CPU-based NFs and physical NPU-based NFs) 
> programmatically, that's the realm of SDN.
> - If you want to do it right you do it in an abstracted declarative way (not exposing the complexity to a control 
> program/user - but rather localizing it to a given abstraction layer)
> Performing tasks like:
> - Defining service topology/access control a.k.a. micro segmentation (e.g. A and B can both talk to C, but not to 
> each other).
> - Traffic engineering a.k.a. service chaining, a.k.a. network slicing (e.g. traffic type x should pas through NF A, B 
> and C, but traffic type Y should pass only through A and C)

This is the bit that I see working well on a per deployment basis, if
operators aren't too concerned about standardizing the solution.

Where the industry has kept falling over is wanting to standardize the
entire orchestration piece, which is very noble, but ultimately, fraught
with many a complication.

I'm sure we'd all like to see a standard on how we orchestrate the
network and services, but I'm not sure that is practical. After all,
operators are autonomous systems.


>  
> 5) And for completeness, in the virtual world you have the task of VNF lifecycle management (cause the VNFs and 
> virtual networks connecting them can be instantiated on demand)

So I first read all about this in 2015, through a document Cisco
published called "Cisco vMS 1.0 Introduction and Overview Design Guide".

Safe to say not much as changed in the objective, since then :-).

Mark.