Mailing List Archive

> 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

On 12/Aug/20 19:10, adamv0025@netconsultings.com wrote:

> 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.

The limitation is the VM i/o with the metal. Trying to shift 100Gbps of
DoS traffic across smaller VNF's running on Intel CPU's is going to
require quite a sizeable investment, and plenty of gymnastics in how you
route traffic to and through them, vs. taking that cash and spending on
just one or two purpose-built platforms that aren't scrubbing traffic in
general-purpose CPU's.

Needless to say, the ratio between the dirty traffic entering the system
and the clean traffic coming out is often not 1:1, from a licensing
standpoint.

It's not unlike when we ran the numbers to see whether a VM running
CSR1000v on a server connected to a dumb, cheap Layer 2 switch was
cheaper than just buying an ASR920. The ASR920, even with the full
license, was cheaper. Server + VMware license fees + considerations for
NIC throughput just made it massively costly at scale.


> 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?

You miss my point. The existence of these data models doesn't mean that
operators cannot automate without them.

There are plenty of operators automating their procedures with, and
without those open-based models. My point was if we are spending a lot
of time trying to agree on these data models, so that Cisco can sell me
their NSO, Juniper their Contrail, Ciena their Blue Planet, NEC their
ProgrammableFlow or Nokia their Nuage - while several operators are
deciding what automation means to them without trying to be boxed in
these off-the-shelf solutions that promise vendor-agonstic integration -
we may just blow another 10 years.



> 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.

Don't get me wrong - if NSO, Blue Planet, Nuage and all the rest are
good for you, go for it.

My concern is most engineers and commercial teams are confused about the
best way forward because the industry keeps going back and forth on what
the appropriate answer is, or worse, could be, or even more scary, is
likely to be. In the end, either nothing is done, or costly mistakes happen.

Only a handful of folk have the time, energy and skills to dig into the
minutiae and follow the technical community on defining solutions at a
very low level. Everybody else just wants to know if it will work and
how much it will cost.

Meanwhile, homegrown automation solutions that do not follow any
standard continue to be seen as a "stop-gap", not realizing that,
perhaps, what works for me now is what works for me, period.

I'm not saying operators aren't automating. I'm saying my automating is
not your automating. As long as we are both happy with the solutions we
have settled on for automating, despite them not being the same or
following a similar standard, what's wrong with that? There are other
pressing matters that need our attention.

Mark.