Mailing List Archive

>
> What I meant that as we've been deploying NFV as a VM,

cloud-native means we take that VM and containerize it further.


Umm, I don't think so.
At least that's not the impression I got from the CNCF, Intel and Red Hat.
They seem to be striving for K8s without the use of VM hypervisors.

Etienne

On Wed, Aug 5, 2020 at 2:12 PM Mark Tinka <mark.tinka@seacom.com> wrote:

>
>
> On 4/Aug/20 17:45, adamv0025@netconsultings.com wrote:
>
> Not sure what you mean NFV is NFV,
>
> From NFV perspective cRDP is no different than vMX -it’s just a
> virtualized router function nothing special…
>
>
> What I meant that as we've been deploying NFV as a VM, cloud-native means
> we take that VM and containerize it further. It's a further diffusion of
> NFV, in my book. The benefits about the added de-layering (if one can call
> it that) are left as an exercise to the operator.
>
>
>
>
> Also with regards to NFV markets, it’s just CPE or telco-cloud (routing on
> host, FWs, LBs and other domain specific network devices like SBCs), and
> then RRs, no one sane would be replacing high throughput aggregation points
> like PEs or core nodes with NFV ,unless one wants to get into some serious
> horizontal scaling ;).
>
>
> Well, vCPE's and vBNG's have long been the holy grail for some of us,
> especially since it makes IPv6 roll-out significantly simpler.
>
> 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

On 5/Aug/20 18:34, Etienne-Victor Depasquale wrote:

>
> Release 16 is just out and if it has delivered the 5G vision, 
> latency between devices connected over the same radio interface 
> (which I take to mean the same gNB),
> is now < 1 ms.
> Isn't that a good improvement?

Well, I doubt the radio has any service intelligence. It's just a
conduit. Depending on why two devices on the same radio have to
communicate, a cleverer system deep in the core would need to process
that before handing it back to the radio network.

Of course, it makes the case for deploying services at each base station
to localize services, but that could get expensive for an entire radio
network, particularly within a 100km Metro where fibre latency will
remain at ±1ms anyway.

Not to mention that with the exception of things like cars in a traffic
jam or on the same piece of highway, the chances of two devices talking
to each other over the same radio can't always be guaranteed.


>  
> I understand that this is a key enabler for driverless cars
> (real-time, automated vehicle navigation) - the V2I part of V2X.

I look forward to seeing this.

 
> Here's one blogger who agrees with you
> <https://www.brighttalk.com/webcast/16515/349885?utm_source=brighttalk-recommend&utm_campaign=network_weekly_email&utm_medium=email&utm_content=company&utm_term=312020> 
> (@19:46) about coverage - and count me in.
> But, I guess, it's fair to say that this is the chicken-and-egg
> conundrum :)

The video won't play. Could be my browser.

Anyway, time will tell. I see 5G roll-out density like rolling out fibre
in places only where the postal service can get to. But I hope I'm wrong.

Mark.

On 5/Aug/20 18:39, Etienne-Victor Depasquale wrote:

>
> Umm, I don't think so.
> At least that's not the impression I got from the CNCF, Intel and Red Hat.
> They seem to be striving for K8s without the use of VM hypervisors.

Much to learn :-).

Mark.

On 4/Aug/20 18:05, adamv0025@netconsultings.com wrote:

> Yes that's exactly it.
> Instead of a VDOM (or whatever is your FW vendor slicing mechanism) give each customer a FW "instance" (VM/Containerized -if there's such a thing already) and instantiate it on demand and with resources customer requested and enforce utility billing.
> Rinse and repeat for any other NF customer might need on your telco cloud (fancy name for a data-canter full of compute)
> As simple as that -problem is that all vendors haven't quite gotten up to speed with licensing models, we need an overall Gbps throughput pool licenses not per VM/Container Gbps pool.

We attempted this for a vCPE model based on CSR1000v.

The options were to either give each customer their own VM, or share a
single VM across all customers. The former was too resource intensive,
while the latter suffered from an appropriate license billing model with
Cisco.

For me, vCPE's make plenty of sense because you can automatically impose
IPv6 on all customers without them being bothered about what it is.

Mark.

Yes they are for 5G core.

On Wed, Aug 5, 2020, 11:28 AM Mark Tinka <mark.tinka@seacom.com> wrote:

>
>
> On 5/Aug/20 17:07, Shane Ronan wrote:
>
> > I think you'd be surprised how much of the 5G Core is containerized
> > for both the data and control planes in the next generations providers
> > are currently deploying.
>
> It's what I expect for new entrants that don't want to deal with
> traditional vendors.
>
> I'd be curious to see if legacy operators are shifting traffic away from
> iron to servers, and at what rate.
>
> Mark.
>

On 6/Aug/20 15:43, Shane Ronan wrote:

> Yes they are for 5G core.

Right, but for legacy operators, or new entrants?

If you know where we can find some info about deployment and
experiences, that would be very interesting to read.

We've all been struggling to make Intel CPU's shift 10's, 40's and 100's
of Gbps of revenue traffic as a routing platform, so would like to know
how the operators are getting on with this.

Mark.

Mark,

I don’t think you’re going to move those volumes with Intel X86 chips. For example, AT&T’s Open Compute Project whitebox architecture is based on Broadcom Jericho2 processors, with aggregate on-chip throughput of 9.6 Tbps, and which support 24 ports at 400 Gbps each. This is where AT&T’s 5G slicing is taking place.

https://about.att.com/story/2019/open_compute_project.html

Intel has developed nothing like this, and has had to resort to acquisition of multi-chip solutions to get these speeds (e.g. its purchase of Barefoot Networks Tofino2 IP).

The X86 architecture is too complex and carries too much non-network-related baggage to be a serious player in 5G slicing.

-mel

On Aug 6, 2020, at 8:24 AM, Mark Tinka <mark.tinka@seacom.com> wrote:

?

On 6/Aug/20 15:43, Shane Ronan wrote:

Yes they are for 5G core.

Right, but for legacy operators, or new entrants?

If you know where we can find some info about deployment and
experiences, that would be very interesting to read.

We've all been struggling to make Intel CPU's shift 10's, 40's and 100's
of Gbps of revenue traffic as a routing platform, so would like to know
how the operators are getting on with this.

Mark.

On 6/Aug/20 17:43, Mel Beckman wrote:

> I don’t think you’re going to move those volumes with Intel X86 chips.
> For example, AT&T’s Open Compute Project whitebox architecture is
> based on Broadcom Jericho2 processors, with aggregate on-chip
> throughput of 9.6 Tbps, and which support 24 ports at 400 Gbps each.
> This is where AT&T’s 5G slicing is taking place.

My point exactly.

If much of the cloud-native is happening on servers with Intel chips,
and part of the micro-services is to also provide data plane
functionality at that level, I don't see how it can scale for legacy
mobile operators. It might make sense for niche, start-up mobile
operators with little-to-no traffic serving some unique case, but not
the classics we have today.

Now, if they are writing their own bits of code on or for white boxes
based on Broadcom et al, not sure that falls in the realm of
"micro-services with Kubernetes". But I could be wrong.


> Intel has developed nothing like this, and has had to resort to
> acquisition of multi-chip solutions to get these speeds (e.g. its
> purchase of Barefoot Networks Tofino2 IP).
>
> The X86 architecture is too complex and carries too much
> non-network-related baggage to be a serious player in 5G slicing.

Which we, as network operators, can all agree on.

But the 5G folk seem to have other ideas, so I just want to see what is
actually truth, and what's noise.

Mark.

On Thu, Aug 6, 2020 at 11:52 AM Mark Tinka <mark.tinka@seacom.com> wrote:

> On 6/Aug/20 17:43, Mel Beckman wrote:
>
> > I don’t think you’re going to move those volumes with Intel X86 chips.
> > For example, AT&T’s Open Compute Project whitebox architecture is
> > based on Broadcom Jericho2 processors, with aggregate on-chip
> > throughput of 9.6 Tbps, and which support 24 ports at 400 Gbps each.
> > This is where AT&T’s 5G slicing is taking place.
>
> My point exactly.
>
> If much of the cloud-native is happening on servers with Intel chips,
> and part of the micro-services is to also provide data plane
> functionality at that level, I don't see how it can scale for legacy
> mobile operators. It might make sense for niche, start-up mobile
> operators with little-to-no traffic serving some unique case, but not
> the classics we have today.

Isn't this just, really:
1) some network gear with SDN bits that live on the next-rack over
servers/kubes
2) services (microservices!) that do the SDN functions AND NFV
functions AND billing
(extending IMS to the edge etc)

> Now, if they are writing their own bits of code on or for white boxes
> based on Broadcom et al, not sure that falls in the realm of
> "micro-services with Kubernetes". But I could be wrong.

the discussion (I think) got conflated here...
there's: "network equipment" and "microservices equipment" (service equipment?)

and really 'I need a fast, cheap network device I can dynamically program for
things which don't really smell like 'DFZ size LPM routing"'

is just code for: "sdn control the switch, sending traffic either at
'default' or based
on 'service data' some microservice architecture of NFV things.

> > Intel has developed nothing like this, and has had to resort to
> > acquisition of multi-chip solutions to get these speeds (e.g. its
> > purchase of Barefoot Networks Tofino2 IP).
> >
> > The X86 architecture is too complex and carries too much
> > non-network-related baggage to be a serious player in 5G slicing.
>
> Which we, as network operators, can all agree on.
>
> But the 5G folk seem to have other ideas, so I just want to see what is
> actually truth, and what's noise.

5g folk seem to have lots of good marketing, and reasons to sell complexity
to their carrier 'partners' (captive prisoners? maybe that's too pejorative :) )

On 6/Aug/20 21:05, Christopher Morrow wrote:

> Isn't this just, really:
> 1) some network gear with SDN bits that live on the next-rack over
> servers/kubes
> 2) services (microservices!) that do the SDN functions AND NFV
> functions AND billing
> (extending IMS to the edge etc)

I can already see how we are going to spend the next 10 years defining
this :-)...


> the discussion (I think) got conflated here...
> there's: "network equipment" and "microservices equipment" (service equipment?)
>
> and really 'I need a fast, cheap network device I can dynamically program for
> things which don't really smell like 'DFZ size LPM routing"'
>
> is just code for: "sdn control the switch, sending traffic either at
> 'default' or based
> on 'service data' some microservice architecture of NFV things.

I think we've just given vendors job security for another decade, hehe.


> 5g folk seem to have lots of good marketing, and reasons to sell complexity
> to their carrier 'partners' (captive prisoners? maybe that's too pejorative :) )

Amen!

Mark.

>
> Well, I doubt the radio has any service intelligence. It's just a conduit.
> Depending on why two devices on the same radio have to communicate, a
> cleverer system deep in the core would need to process that before handing
> it back to the radio network.
>
5G introduced a number of functional units (RU, DU and CU) in the radio
access network and disaggregation is flexible. Service intelligence doesn't
need to come from the core; it may be far out in the edge. At the RU, there
is packetized data ready for transmission over eCPRI to the DU. In this
webinar <https://www.lightreading.com/webinar.asp?webinar_id=1656> (@6:07),
there's a bit of a projection about use of service intelligence.

Cheers,

Etienne

On Thu, Aug 6, 2020 at 10:21 AM Mark Tinka <mark.tinka@seacom.com> wrote:

>
>
> On 5/Aug/20 18:34, Etienne-Victor Depasquale wrote:
>
>
> Release 16 is just out and if it has delivered the 5G vision,
> latency between devices connected over the same radio interface
> (which I take to mean the same gNB),
> is now < 1 ms.
> Isn't that a good improvement?
>
>
> Well, I doubt the radio has any service intelligence. It's just a conduit.
> Depending on why two devices on the same radio have to communicate, a
> cleverer system deep in the core would need to process that before handing
> it back to the radio network.
>
> Of course, it makes the case for deploying services at each base station
> to localize services, but that could get expensive for an entire radio
> network, particularly within a 100km Metro where fibre latency will remain
> at ±1ms anyway.
>
> Not to mention that with the exception of things like cars in a traffic
> jam or on the same piece of highway, the chances of two devices talking to
> each other over the same radio can't always be guaranteed.
>
>
>
> I understand that this is a key enabler for driverless cars (real-time,
> automated vehicle navigation) - the V2I part of V2X.
>
>
> I look forward to seeing this.
>
>
>
> Here's one blogger who agrees with you
> <https://www.brighttalk.com/webcast/16515/349885?utm_source=brighttalk-recommend&utm_campaign=network_weekly_email&utm_medium=email&utm_content=company&utm_term=312020>
> (@19:46) about coverage - and count me in.
> But, I guess, it's fair to say that this is the chicken-and-egg conundrum
> :)
>
>
> The video won't play. Could be my browser.
>
> Anyway, time will tell. I see 5G roll-out density like rolling out fibre
> in places only where the postal service can get to. But I hope I'm wrong.
>
> 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

On 7/Aug/20 09:35, Etienne-Victor Depasquale wrote:

> 5G introduced a number of functional units (RU, DU and CU) in the
> radio access network and disaggregation is flexible. Service
> intelligence doesn't need to come from the core; it may be far out in
> the edge. At the RU, there is packetized data ready for transmission
> over eCPRI to the DU. In this webinar
> <https://www.lightreading.com/webinar.asp?webinar_id=1656> (@6:07),
> there's a bit of a projection about use of service intelligence.

In my old, the plan is what happens :-).

Mark.

On 7/Aug/20 09:35, Etienne-Victor Depasquale wrote:

> 5G introduced a number of functional units (RU, DU and CU) in the
> radio access network and disaggregation is flexible. Service
> intelligence doesn't need to come from the core; it may be far out in
> the edge. At the RU, there is packetized data ready for transmission
> over eCPRI to the DU. In this webinar
> <https://www.lightreading.com/webinar.asp?webinar_id=1656> (@6:07),
> there's a bit of a projection about use of service intelligence.

In my old age, the plan is what happens :-).

Mark.

I can promise 100% that in LARGE US 5G carriers this is exactly what is happening. Virtual CU’s and DU’s, running on traditional virtualization platforms and in containers.

An entire multi-vendor containerized 5G which replaces the 4G EPC is also in testing, and close to production deployment.

The only non-virtualized devices in the RAN network would be the Radio Units (RU).



> On Aug 7, 2020, at 5:15 AM, Mark Tinka <mark.tinka@seacom.com> wrote:
>
> ?
>
> On 7/Aug/20 09:35, Etienne-Victor Depasquale wrote:
>
>> 5G introduced a number of functional units (RU, DU and CU) in the radio access network and disaggregation is flexible. Service intelligence doesn't need to come from the core; it may be far out in the edge. At the RU, there is packetized data ready for transmission over eCPRI to the DU. In this webinar (@6:07), there's a bit of a projection about use of service intelligence.
>
> In my old, the plan is what happens :-).
>
> Mark.

On 7/Aug/20 14:40, sronan@ronan-online.com wrote:

> I can promise 100% that in LARGE US 5G carriers this is exactly what
> is happening. Virtual CU’s and DU’s, running on traditional
> virtualization platforms and in containers.
>
> An entire multi-vendor containerized 5G which replaces the 4G EPC is
> also in testing, and close to production deployment.
>
> The only non-virtualized devices in the RAN network would be the Radio
> Units (RU).

With any luck, we shall see an "experience preso" at a NOG near us, some
time.

This would certainly be most interesting for the community.

Mark.

On Fri, 07 Aug 2020 07:29:49 +0200, Mark Tinka said:
> On 6/Aug/20 21:05, Christopher Morrow wrote:
> > Isn't this just, really:
> > 1) some network gear with SDN bits that live on the next-rack over
> > servers/kubes
> > 2) services (microservices!) that do the SDN functions AND NFV
> > functions AND billing
> > (extending IMS to the edge etc)
>
> I can already see how we are going to spend the next 10 years defining
> this :-)...

With research consultant reports tagging along every step of the way. :)

And for other stuff as well.



adam



From: Shane Ronan <shane@ronan-online.com>
Sent: Thursday, August 6, 2020 2:43 PM
To: Mark Tinka <mark.tinka@seacom.com>
Cc: adamv0025@netconsultings.com; North American Network Operators' Group <nanog@nanog.org>
Subject: Re: Has virtualization become obsolete in 5G?



Yes they are for 5G core.



On Wed, Aug 5, 2020, 11:28 AM Mark Tinka <mark.tinka@seacom.com <mailto:mark.tinka@seacom.com> > wrote:



On 5/Aug/20 17:07, Shane Ronan wrote:

> I think you'd be surprised how much of the 5G Core is containerized
> for both the data and control planes in the next generations providers
> are currently deploying.

It's what I expect for new entrants that don't want to deal with
traditional vendors.

I'd be curious to see if legacy operators are shifting traffic away from
iron to servers, and at what rate.

Mark.

> From: Mark Tinka <mark.tinka@seacom.com>
> Cc: adamv0025@netconsultings.com; North American Network Operators'
>
>
> On 6/Aug/20 15:43, Shane Ronan wrote:
>
> > Yes they are for 5G core.
>
> Right, but for legacy operators, or new entrants?
>
> If you know where we can find some info about deployment and
> experiences, that would be very interesting to read.
>
> We've all been struggling to make Intel CPU's shift 10's, 40's and 100's of Gbps
> of revenue traffic as a routing platform, so would like to know how the
> operators are getting on with this.
>
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).

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.

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

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)

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)

adam

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.

> From: Mark Tinka <mark.tinka@seacom.com>
> Sent: Tuesday, August 11, 2020 2:19 PM
>
> 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.
>
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

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.



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

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@seacom.com> wrote:

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

On 12/Aug/20 09:49, Etienne-Victor Depasquale wrote:

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

I'm not sure that's a viable argument considering that any good employee
(network, software, e.t.c.) will inherently have considerable leverage
over their employer. And any good employer knows what to do when they
realize they have good talent - either they do what is required to
maintain that talent, or live with the risk of losing that talent to the
competition.

Moreover, an employer doesn't have to give in to the whims of a
conceited employee; and most do not.

Standardizing processes would do little to allay the fears of a CTO who
is worried about being "cornered" by his/her staff. The real fear such a
CTO would have is in implementation and operation of those processes at
a technology level, i.e., where the rubber meets the actual road.

If companies are going to be that scared by their employees, and if
employees are going to play games with their employers, they each have
other problems to solve, first :-).

Mark.

>
> Moreover, an employer doesn't have to give in to the whims of a
> conceited employee; and most do not.
>

This point plays straight up the path of the argument I recounted.

Yes, I agree that there's a relational problem inherent to the situation I
described.
Wouldn't any wise employer playing the relationship game ensure that he's
got cards to play?
And wouldn't the standardization approach be part of the deck?

Cheers,

Etienne

On Wed, Aug 12, 2020 at 10:00 AM Mark Tinka <mark.tinka@seacom.com> wrote:

>
>
> On 12/Aug/20 09:49, Etienne-Victor Depasquale wrote:
>
> > 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.
>
> I'm not sure that's a viable argument considering that any good employee
> (network, software, e.t.c.) will inherently have considerable leverage
> over their employer. And any good employer knows what to do when they
> realize they have good talent - either they do what is required to
> maintain that talent, or live with the risk of losing that talent to the
> competition.
>
> Moreover, an employer doesn't have to give in to the whims of a
> conceited employee; and most do not.
>
> Standardizing processes would do little to allay the fears of a CTO who
> is worried about being "cornered" by his/her staff. The real fear such a
> CTO would have is in implementation and operation of those processes at
> a technology level, i.e., where the rubber meets the actual road.
>
> If companies are going to be that scared by their employees, and if
> employees are going to play games with their employers, they each have
> other problems to solve, first :-).
>
> 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

On 12/Aug/20 10:50, Etienne-Victor Depasquale wrote:

> This point plays straight up the path of the argument I recounted.
>
> Yes, I agree that there's a relational problem inherent to the
> situation I described.
> Wouldn't any wise employer playing the relationship game ensure that
> he's got cards to play?
> And wouldn't the standardization approach be part of the deck?

In theory, yes.

But the department most interested in this might be HR, while the ones
most able to implement it will be the CTO team.

Until NOG's start having breakout sessions on employee-employer
dynamics, or until HR conferences start thinking about telecoms industry
orchestration standardizations to mitigate employee-employer dynamics,
it will remain a theory :-).

Mark.