Re: [CCAMP] [Teas] Decision point on scope of draft-ietf-teas-ietf-network-slices

[Tarek Saad <[e-mail]>]

Hi Krzysztof and Luis,

Thanks for sharing your thoughts. See inline..

From: Teas <[e-mail]> on behalf of Krzysztof Szarkowicz <[e-mail]>
Date: Friday, March 11, 2022 at 2:32 AM
To: LUIS MIGUEL CONTRERAS MURILLO <[e-mail]>
Cc: Gyan Mishra <[e-mail]>, Igor Bryskin <[e-mail]>, CCAMP <[e-mail]>, TEAS WG <[e-mail]>, [e-mail] <[e-mail]>, Daniele Ceccarelli <[e-mail]>
Subject: Re: [Teas] [CCAMP] Decision point on scope of draft-ietf-teas-ietf-network-slices
Hi Luis,

Nice summary.

Just wanted to add one comment regarding realization. Today, many service providers have in their offering services with SLO, be it for example business edge services, wholesale services, etc. At vast majority of these operators, in packet switched (IP/MPLS) networks, these services are realized without maintaining any state directly related to the service on transit devices - states are maintained at the edge only. At the 10k feet view level, the service realization is based on

* states at the edge (i.e. service instances)
* strict admission control at the edge (i.e., advanced QoS at the edge)
* overall network capacity planning
* potentially, overall network bandwidth management (i.e. some sort of TE, depending on the operator could be none, some light version of TE, or some heavy version of TE)

And, these operators offer these services not only with SLOs, but as well with SLAs - i.e., they need to pay penalty, if SLO is not meet. Saying that, these operators are making good business out of it, i.e. they don’t go bankrupt due to penalties they would need to pay.

Introducing the states in the transit devices, in addition to states at the edge, is major change in the operational model that involves not only OPEX, but as well CAPEX (transit routers must be able to maintain new states, i.e. advanced QoS policies for NRP separation). So, the transport teams of these operators will think twice (if not 3 times), before changing the operational model, and only do it, when it is really required.
[TS]: yes, maintaining states at the edge may be less intrusive to some network operators addressing catering to specific usecases. In our solution [ID.bestbar-teas-ns-packet], we have introduced a control plane NRP mode that would necessitate such state (knowledge of NRP partitions) being present only at ingresses (or possibly off devices on a PCE). The NRPs (in this case) can be simple topological partitions (topology filters) or hold more elaborate state like per NRP bandwidth reservations.


Past attempts for network architectures that rely on extensive states on transit devices (i.e. ATM, DS-aware TE) miserably failed (ATM is practically dead, DS-aware TE has minimal deployment status), so I am not sure, to which extend new architecture that rely on these new transit states will gain traction.

For example, there is no much difference between business VPN with SLO, and transport for 5G slices with SLO. In both cases, SLOs are similar (i.e. bandwidth, latency, packet loss, …) and in both cases it is about interconnecting VPN sites (business VPN) or mobile functions - UPF, CU, DU, … - at different locations (5G slice) with these SLOs. So, we will live with slicing solutions relying on edge states only (without states on transit) for long, as I see it.

Saying that, there are specific use cases for slicing, where maintaining the states on transit makes a lot of sense. For example, shared infrastructure use case (could be RAN + transport), where infrastructure is shared among say two operators (operator 1 invested 30%, operator 2 invested 70%), and each operator gets a guaranteed part of the infrastructure for its use. NRP with 30% resources for operator 1, and another NRP with 70% of resources for operator 2 is very good fit here.
[TS]: indeed, for usecases (like Infrastructure as a Service (IaaS) or Network as a Service (NaaS)) that require stricter guarantees among NRP partitions, the solution in [ID.bestbar-teas-ns-packet] enables differentiation of treatment for aggregate flows steered on different NRPs -- by maintaining per NRP QoS state (profiles) on the network devices. I don’t think some state on transit nodes to cater for those usecases are a challenge. IMO, the distribution of such state on NRP nodes is key (automation) – I would quote SR flex-algo where it is possible and acceptable to maintain per flex-aglo state for each prefix in the IGP network. The approach in [ID.bestbar-teas-ns-packet] introduces the NRP Policy construct (via suitable SBI interfaces) to automate this state distribution and achieve just that!

Regards,
Tarek


My 2 cents.

Kind regards,
Krzysztof



On 2022 -Mar-11, at 06:32, Gyan Mishra <[e-mail]<mailto:[e-mail]>> wrote:


Hi Luis

I agree with all of your comments as well from an operators POV.

Nice summarization!

There is a lot of value add to be gained by operators being able to provision a high tier VPN  w/ SLO called “Enhanced VPN” with finer granularity with discrete NRP underlay backbone provisioning enhancements for new service offerings with strict requirements.

Responses In-line

Kind Regards

Gyan
On Thu, Mar 10, 2022 at 6:20 AM LUIS MIGUEL CONTRERAS MURILLO <[e-mail]<mailto:[e-mail]>> wrote:
Hi all,

I think it is important to realize the fact that 5G is not simply a new RAN technology, but it is transformational in so many aspects in the way in which networks (in a broader sense) are consumed. This also affects to the network as defined in IETF terms. This imply so many things as automation, SLOs, dynamicity (from ephemeral to long lasting services), SLEs, strict(er) service guarantees, etc. Many of these concepts (if not all) are not new, which is new is to create a framework that allow to handle all of them in the transformational way shown by 5G. But this does not prevent that other services different from those based on 5G RAN can benefit of these same advances, either for “current” version of those services, or “future” variants of them when needing more stringent requirements, in line with the evolution of services (XR/VR, metaverse, industrial, etc).
 Gyan>  Lots to gain for operators for being able to take advantage of IETF Network Slicing for other value added service offerings beyond 5G
So I would like to remind that there is an ongoing piece of work coming from the old times of the Design Team discussions trying to identify use cases and requirements to be supported by the IETF Network Slice Controller, documented in draft-contreras-teas-slice-nbi. According to this discussion and others in the list, I think that a document like that is necessary for settling the scope of the work. I would suggest to bring there the discussion on use cases and needs to ensure we do not limit or we do not skip any need at the time of working on the slicing framework.
Gyan> Agreed. I would be happy to collaborate on the use cases discussions
On the other hand, when we talk about VPN, OTN, etc, we are talking about realizations of the IETF Network Slice concept. Certainly, some technologies for slice realization will be more suitable to other for specific requirements, but not all the slices will have the same set of requirements, so depending on the needs, it would be more convenient the realization of the slices in one way or another.
Gyan> Agreed
Is it an slice equivalent to VPN with SLOs? Maybe in some cases yes, depending on the SLOs needed for the service. Conventional VPNs are created at the edge nodes in the network, where certain level of service awareness can be retained. However, core backbone nodes have no such service awareness, thus not being able to contribute to the distinction of services with different needs from different customers. So for services with stringent requirements, conventional VPN with SLOs could not be sufficient.
Gyan>  Agreed.  Existing VPN w/ SLO is edge provisioning, however the core backbone nodes don’t have the awareness, agreed.  The VPNs w/ SLO can still take advantage and degree of isolation slice like characteristics with RSVP-TE to VPN mapping onto more isolated paths  or SR-TE micro or macro flow steering, however discrete VPN to underlay underpinning resource provisioning with network slicing  is still a gap as you point out that conventional VPN w/ SLO cannot accommodate.
Regarding OTN, certainly it is a technology that can more easily provide certain guarantees, and there are probably mechanisms already there for creating a “logical network structures with required characteristics” according to framework document . Does it mean that slicing is already solved in OTN? Well, there are aspects which are not yet in place (fully or partially) when looking at which is stated in the framework document. For instance, framework document states (in section 1.1, background) “Additionally, the IETF Network Slice customer might ask for some level of control of their virtual networks, e.g., to customize the service paths in a network slice.” Furthermore, the expectation is that slice customer could express slice needs in a terminology agnostic manner, then needing some way of translating SLOs and SLEs to specific slice technologies for realization. All of this (and probably some other aspects) is part of the slice service, even though the realization could (fully or partially) leverage on existing capabilities. But in any case there is a need for developing new ones, for making the different possible realization technologies an alternative for accomplishing the IETF Network Slice service in a consistent manner.
 Gyan> Agreed
Finally I would like to comment on the fact of considering different technologies for realization. Let me here come back again to the old times of the Design Team discussions. While discussing about the usage of the term “transport”, at least in my understanding, the conclusion was that the work being done here could be of applicability to technologies addressed by other WGs (CCAMP, RAW and even DetNet where mentioned in the discussions). So I think it was already agreed on the fact that the framework could host a number of technologies for slice realization.
 Gyan> Completely Agree
Thanks and apologies for the long mail

Luis


De: CCAMP <[e-mail]<mailto:[e-mail]>> En nombre de Igor Bryskin
Enviado el: jueves, 10 de marzo de 2022 1:47
Para: [e-mail]<mailto:[e-mail]>; Adrian Farrel <[e-mail]<mailto:[e-mail]>>; 'Daniele Ceccarelli' <[e-mail]<mailto:[e-mail]>>; 'TEAS WG' <[e-mail]<mailto:[e-mail]>>; 'CCAMP' <[e-mail]<mailto:[e-mail]>>
Asunto: Re: [CCAMP] [Teas] Decision point on scope of draft-ietf-teas-ietf-network-slices

Hi Adrian,


In response to Igor’s series of emails:

  *   If a 5G RAN is supported over an OTN then the concept of an e2e slice requires that there is something that can be called a transport network slice supported by the OTN.
IB:. I think to achieve this it would take basic OTN service delivering non-IP client over p2p links, something OTN has been doing for decades.


  *   If the IETF Network Slicing Service YANG module is agnostic of the underlay network, then it should be possible for any network technology to have a go at supporting it.
IB: This includes not just OTN, of course,  but also flexE. microwave, OCh, physical fiber, lease line, PW and pretty much anything else that can deliver bits from A to B. To paraphrase my favorite Gert's question: what is not a transport slice according to the framework?


  *   If a vendor does not want to implement or an operator does not want to support slicing over an OTN, that is a free choice.
IB: of course.


  *   If the concept of slicing an OTN is no different from building a VN or a set of LSPs in that network, why is this whole thing a big deal?
IB: As one Austrian guy said  "sometimes a cigar is just a cigar" and should be called cigar, rather than, say, tobaco slice );
Yes, it is not big deal if we stick to VNs, which normally are bottom up network building constructs. But it could become a rather big deal if one tries to engage OTN directly in the top down netwrk slicing process by, for example, creating VNs on the fly.

Cheers,
Igor



Sent from Yahoo Mail on Android<https://go.onelink.me/107872968?pid=InProduct&c=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers&af_wl=ym&af_sub1=Internal&af_sub2=Global_YGrowth&af_sub3=EmailSignature>

On Wed, Mar 9, 2022 at 12:01 PM, Adrian Farrel
<[e-mail]<mailto:[e-mail]>> wrote:
_______________________________________________
CCAMP mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/ccamp


________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is confidential and privileged information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição
_______________________________________________
CCAMP mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/ccamp
--
[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<http://www.verizon.com/>
Gyan Mishra
Network Solutions Architect
Email [e-mail]<mailto:[e-mail]>
M 301 502-1347

_______________________________________________
Teas mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/teas