RE: Has virtualization become obsolete in 5G?

[<adamv0025 () netconsultings com>]

> From: Mark Tinka <mark.tinka () seacom com>
> Sent: Tuesday, August 11, 2020 7:45 PM
>
> On 11/Aug/20 17:55, adamv0025 () netconsultings com wrote:
>
> > 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?)
>
> In an effort to control costs, we considered a vTMS from Arbor.
>
> Even Arbor didn't recommend it, which was completely unsurprising.
>
> Arbor can flog you a TMS that can sweep 10Gbps, 20Gbps, 40Gbps or
> 100Gbps worth of traffic. I don't see how you can run that kind of traffic in a
> VM.
Fair enough, but you actually haven't answered my question about why you think that VNFs such as vTMS can not be 
implemented in a horizontal scaling model? 
In my opinion any NF virtual or physical can be horizontally scaled. 

> > Can you please point out any efforts where operators are trying to
> standardize the orchestration piece?
>
> NETCONF, YANG, LSO.
Right, and of these 3 you mentioned, what is it that you'd say operators are waiting for to get standardized, in order 
for them to start implementing network services orchestration?

> > 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).
>
> What's 10 years between friends :-)...
>
>
> > 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.
>
> Now that's something we can agree on... and once folk realize that getting
> your solution going is the end-goal - rather than bickering over whether
> NETCONF or YANG or SSH or whatever should be the BCOP - is when we shall
> finally see some real progress.
>
> Personally, I don't really care of you choose to keep CLI or employ thousands
> of software heads to automate said CLI. As long as you are happy and not
> wasting time taking every meeting from every vendor about "automation".
Agreed, all I'm trying to understand is what makes you claim things like: progress is slow, or there's a lack of 
standardization, or operators need to wait till things get standardized in order to start doing network service 
orchestration... 
I'm asking cause I just don't see that. My personal experience is quite different to what you're claiming. 

Yes the landscape is quite diverse ranging from fire and forget CLI scrapers (Puppet, Chef, Ansible, SaltStack) through 
open network service orchestration frameworks all the way to a range of commercial products for network service 
orchestration, but the point is options are there and one can start today, no need to wait for anything to get 
standardized or things to settle.      
 

adam