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

["Rokui, Reza" <[e-mail]>]

Thanks Luis for your nice summary. I agree with your comments.

Reza

From: CCAMP <[e-mail]> on behalf of LUIS MIGUEL CONTRERAS MURILLO <[e-mail]>
Date: Thursday, March 10, 2022 at 6:20 AM
To: Igor Bryskin <[e-mail]>, [e-mail] <[e-mail]>, 'Daniele Ceccarelli' <[e-mail]>, 'TEAS WG' <[e-mail]>, 'CCAMP' <[e-mail]>
Subject: [**EXTERNAL**] Re: [CCAMP] [Teas] Decision point on scope of draft-ietf-teas-ietf-network-slices
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).

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.

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.

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.

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.

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.

Thanks and apologies for the long mail

Luis


De: CCAMP <[e-mail]> En nombre de Igor Bryskin
Enviado el: jueves, 10 de marzo de 2022 1:47
Para: [e-mail]; Adrian Farrel <[e-mail]>; 'Daniele Ceccarelli' <[e-mail]>; 'TEAS WG' <[e-mail]>; 'CCAMP' <[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 [go.onelink.me]<https://urldefense.com/v3/__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__;!!OSsGDw!e2YObo_ZIMQwUsunBpsQVSTH_uY-8HdC7Bkv0Hofu6AnM18XTaWo-SXqSYf3$>

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 [ietf.org]<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ccamp__;!!OSsGDw!e2YObo_ZIMQwUsunBpsQVSTH_uY-8HdC7Bkv0Hofu6AnM18XTaWo-ZKjd7bd$>


________________________________

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