Has virtualization become obsolete in 5G?

Wed Aug 12 07:49:08 UTC 2020

Two more bits' worth ...

About a year ago, during a discussion with a local network operator's CTO,
I was told that dependency on the operator's employees
for production of software gave the employees too much leverage over their
employer (the operator, here).

Perhaps industrial standardization of internal processes (including
orchestration APIs) weakens this leverage.

Cheers,

Etienne

On Tue, Aug 11, 2020 at 8:48 PM Mark Tinka <mark.tinka at seacom.com> wrote:

>
>
> On 11/Aug/20 17:55, adamv0025 at 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.
>
>
>
> > Can you please point out any efforts where operators are trying to
> standardize the orchestration piece?
>
> NETCONF, YANG, LSO.
>
>
> > 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".
>
> Mark.
>

-- 
Ing. Etienne-Victor Depasquale
Assistant Lecturer
Department of Communications & Computer Engineering
Faculty of Information & Communication Technology
University of Malta
Web. https://www.um.edu.mt/profile/etiennedepasquale
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20200812/3fd997f8/attachment.html>