Has virtualization become obsolete in 5G?

Tue Aug 11 15:55:55 UTC 2020

> From: Mark Tinka <mark.tinka at seacom.com>
> Sent: Tuesday, August 11, 2020 2:19 PM
> 
> On 10/Aug/20 15:15, adamv0025 at 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.
> 
Yes apart from the fog/edge computing all aforementioned is business as usual.

> The main issue, as discussed earlier, was licensing options for CPE-type
> deployments. This is what killed our plan for the same.
> 
Yes vendors need to abandon the old physical unit types of licensing schemes for the horizontal scaling to make sense.   

> 
> > 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.
> 
Can you elaborate? 
Apart from licensing scheme what stops one from redirecting traffic to one vTMS instance per say each transit link or per destination /24 (i.e. horizontal scaling)? (vTMS is not stateful or is it?)


> > 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.
> 
Can you please point out any efforts where operators are trying to standardize the orchestration piece? 
I think industry is not falling over on this just progressing at steady rate while producing artefacts in the process that you may or may not want to use (I actually find them very useful and not impeding).   


> 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.
> 
Personally, I don't need a standard on how I should orchestrate network services. There are very interesting and useful ideas, or better put "frameworks", that anyone can follow (and most are), but standardizing these, ...no point in my opinion.


> > 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 :-).
> 
Really? Never mind then ;)

adam