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

From: Daniele Ceccarelli <[email-masked]>
Date: Tue, 8 Mar 2022 09:10:05 +0000

Hi Igor,

(adding CCAMP as this is becoming a cross-wg discussion)

I get your point but it doesn’t seem fair to me to limit network slicing to 5G just to deprecate slicing at other layers. If there are other technical reasons to do so (some of which you already brought up) that’s fine, but I don’t think we should limit network slicing to 5G.
Moreover I’ve seen quite a lot of support in TEAS not to limit network slicing to 5G (obviously not my call).

Cheers,
Daniele

From: Igor Bryskin <i_bryskin=[email-masked]>
Sent: den 7 mars 2022 19:03
To: Daniele Ceccarelli <[email-masked]>; Daniele Ceccarelli <[email-masked]>; jdrake=[email-masked] <[email-masked]>; [email-masked]; 'TEAS WG' <[email-masked]>
Subject: Re: [Teas] Decision point on scope of draft-ietf-teas-ietf-network-slices

Daniele,

We all agreed that OTN  does not bring anything new into 5G that, for example,  was not happening  in 4G. OTN slicing work is motivated in some way, at least, because NS framework stipulates that the framework  is not limited to 5G. In fact, it seems to be not limited to anything (application -wise or layering -wise) to a point that it is not really clear what could not be considered a network slice.

However,  If the framework was focused on 5G (ideallt going even further and stating  that said 5G style network slicing happenning in IP layer only, which I believe is the case) ,  OTn slicing would have nothing to do with the framework (and the term  slicing) and would have to rely on its own merits ( which,  as you mentioned, you have doubts about yourself) and also  explain why it coincides in time with NS work triggered and inspired entirely by 5G.

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 Mon, Mar 7, 2022 at 12:01 PM, Daniele Ceccarelli
<daniele.ceccarelli=[email-masked]<mailto:daniele.ceccarelli=[email-masked]>> wrote:
_______________________________________________
Teas mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/teas

---

From: Igor Bryskin <[email-masked]>
Date: Tue, 8 Mar 2022 13:10:10 +0000 (UTC)

Hi Daniele,
As you understand, I suggested to clarify NS framework's position and (ideally) narrow it's scope in two dimensions:
1. application-wise (to 5G);2. network-layer -wise (to IP)
Yes, TEAS has clearly rejected my proposal on 1. to be able to not overlook needs of other potential users, such as Enhanced VPNs, on-line gaming, IPTV, etc. I appreciate that. Despite no one so far identified an element in the framework that is not needed for 5G but is needed ,say, for gaming, such things might come up in the future.
But I didn't see much rejection or even resistance on 2.  Some (e.g. Gyan) expressed understanding of the concerns and openness to resolve them. Yes, it is unfair to dismiss OTN slicing by limiting framework to 5G, but it is equally unfair to justify it just because the framework intends to be open to other applications, such as gaming.
So, I think it is a good time to ask TEAS your questions. My main questions are:1. Is one or a collection of several OTN TE tunnels is a network slice?2. Is connection-oriented p2p  connectivity support is sufficient for X to be called network slice?3. Several days ago Adrian defined NS service (how the NS is seen by a customer)  as a collection of connectivity constructs of various types and complexity levels. Can OTN deliver such a service?

I appreciate very much the discussions . Thanks a lot to all involved.
Cheers,Igor
    On Tuesday, March 8, 2022, 04:10:35 AM EST, Daniele Ceccarelli <daniele.ceccarelli=[email-masked]> wrote:  
 
 <!--#yiv5032692978 _filtered {} _filtered {} _filtered {}#yiv5032692978 #yiv5032692978 p.yiv5032692978MsoNormal, #yiv5032692978 li.yiv5032692978MsoNormal, #yiv5032692978 div.yiv5032692978MsoNormal {margin:0cm;font-size:12.0pt;font-family:"Times New Roman", serif;}#yiv5032692978 a:link, #yiv5032692978 span.yiv5032692978MsoHyperlink {color:blue;text-decoration:underline;}#yiv5032692978 span.yiv5032692978EmailStyle19 {font-family:"Calibri", sans-serif;color:windowtext;}#yiv5032692978 .yiv5032692978MsoChpDefault {font-family:"Calibri", sans-serif;} _filtered {}#yiv5032692978 div.yiv5032692978WordSection1 {}-->
Hi Igor,

 

 
Cheers,
Daniele  

 
Daniele,

 

Cheers,
 
Igor
 
Sent from Yahoo Mail on Android

 
<daniele.ceccarelli=[email-masked]> wrote:
 
[email-masked]
 
[email-masked]

---

From: Daniele Ceccarelli <[email-masked]>
Date: Wed, 9 Mar 2022 10:41:48 +0000

Hi Igor,

I believe that OTN already supports network slicing today via existing tools (OTN TE tunnels, OTN ACTN VNs…etc), that why I don’t think we need to label it as OTN slicing (but this is just my personal opinion, CCAMP consensus seems to be different). Hence my answer would be yes to all of your questions.

It would be great to hear someone else’s opinion on both lists.

Cheers,
Daniele

From: Igor Bryskin <i_bryskin=[email-masked]>
Sent: den 8 mars 2022 14:10
To: jdrake=[email-masked] <[email-masked]>; [email-masked]; 'TEAS WG' <[email-masked]>; CCAMP <[email-masked]>; Daniele Ceccarelli <[email-masked]>
Subject: Re: [Teas] Decision point on scope of draft-ietf-teas-ietf-network-slices

Hi Daniele,

1. application-wise (to 5G);
2. network-layer -wise (to IP)

So, I think it is a good time to ask TEAS your questions. My main questions are:
1. Is one or a collection of several OTN TE tunnels is a network slice?
2. Is connection-oriented p2p  connectivity support is sufficient for X to be called network slice?
3. Several days ago Adrian defined NS service (how the NS is seen by a customer)  as a collection of connectivity constructs of various types and complexity levels. Can OTN deliver such a service?

Cheers,
Igor

On Tuesday, March 8, 2022, 04:10:35 AM EST, Daniele Ceccarelli <daniele.ceccarelli=[email-masked]<mailto:daniele.ceccarelli=[email-masked]>> wrote:

Hi Igor,

Cheers,
Daniele

From: Igor Bryskin <i_bryskin=[email-masked]<mailto:i_bryskin=[email-masked]>>
Sent: den 7 mars 2022 19:03
To: Daniele Ceccarelli <[email-masked]<mailto:[email-masked]>>; Daniele Ceccarelli <[email-masked]<mailto:[email-masked]>>; jdrake=[email-masked]<mailto:jdrake=[email-masked]> <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; 'TEAS WG' <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Teas] Decision point on scope of draft-ietf-teas-ietf-network-slices

Daniele,

Cheers,

Igor

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 9 Mar 2022 17:01:19 -0000

Hi Daniele,

I appreciate your call for additional voices.

If, as you say, OTN already supports slicing with existing tools, then what is needed is an applicability statement “Addressing Network Slice Service Requests with an OTN” and that will ‘simply’ point up the existing tools and how the YANG modules are mapped. If, during that work, it is found that there are pieces missing (see also draft-ietf-teas-applicability-actn-slicing) then the document will need to contain more work.

I suspect that the authors of the ‘OTN slicing’ document believe that they have got ahead of us here by already discovering some missing pieces which they are going on to address. In that case, all that is needed is for them to ‘back-fill’ but describing how it fits together and why those pieces are necessary.

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

Cheers,

Adrian

From: Daniele Ceccarelli <[email-masked]> 
Sent: 09 March 2022 10:42
To: Igor Bryskin <i_bryskin=[email-masked]>; jdrake=[email-masked] <[email-masked]>; [email-masked]; 'TEAS WG' <[email-masked]>; CCAMP <[email-masked]>
Subject: RE: [Teas] Decision point on scope of draft-ietf-teas-ietf-network-slices

Hi Igor,

Cheers,

Daniele  

Hi Daniele,

 

Cheers,

Igor

On Tuesday, March 8, 2022, 04:10:35 AM EST, Daniele Ceccarelli <daniele.ceccarelli=[email-masked] <mailto:daniele.ceccarelli=[email-masked]> > wrote: 

Hi Igor,

Cheers,
Daniele  

From: Igor Bryskin <i_bryskin=[email-masked] <mailto:i_bryskin=[email-masked]> > 
Sent: den 7 mars 2022 19:03
To: Daniele Ceccarelli <[email-masked] <mailto:[email-masked]> >; Daniele Ceccarelli <[email-masked] <mailto:[email-masked]> >; jdrake=[email-masked] <mailto:jdrake=[email-masked]>  <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> ; 'TEAS WG' <[email-masked] <mailto:[email-masked]> >
Subject: Re: [Teas] Decision point on scope of draft-ietf-teas-ietf-network-slices

Daniele,

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> 

<daniele.ceccarelli=[email-masked] <mailto:daniele.ceccarelli=[email-masked]> > wrote:

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

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

---

From: Jeff Tantsura <[email-masked]>
Date: Wed, 9 Mar 2022 12:56:54 -0800

From the very beginning of this work we have clearly said that the scoop is wider than 5G slicing however they are one of the driving segments behind this work and their use cases are rather important. There are many other segments that would benefit from this work equally.

Cheers,
Jeff

> On Mar 9, 2022, at 09:01, Adrian Farrel <[email-masked]> wrote:
> 
> 
> Hi Daniele,
>  
> 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.
> 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.
> 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.
> 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?
>  
> Cheers,
> Adrian
>

---

From: Igor Bryskin <[email-masked]>
Date: Wed, 9 Mar 2022 22:35:41 +0000 (UTC)

Hi Jeff,
Of course,  there will be many users of network  slicing, I am not arguing that. This obviously can change, and it is wise to keep mind open, I get it, but for whatever reason to date I cannot find in the framework anything that is needed by one of its potential users, say, on-line gaming applications, but is not needed by 5G, it's, as you said, main trigger and beneficiary.

Cheers,Igor

  On Wed, Mar 9, 2022 at 3:57 PM, Jeff Tantsura<[email-masked]> wrote:   _______________________________________________
CCAMP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ccamp

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 10 Mar 2022 00:46:54 +0000 (UTC)

Hi Adrian,

   - 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

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

---

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Thu, 10 Mar 2022 11:19:57 +0000

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 <[email-masked]> En nombre de Igor Bryskin
Enviado el: jueves, 10 de marzo de 2022 1:47
Para: [email-masked]; Adrian Farrel <[email-masked]>; 'Daniele Ceccarelli' <[email-masked]>; 'TEAS WG' <[email-masked]>; 'CCAMP' <[email-masked]>
Asunto: Re: [CCAMP] [Teas] Decision point on scope of draft-ietf-teas-ietf-network-slices

Hi Adrian,

  *   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

On Wed, Mar 9, 2022 at 12:01 PM, Adrian Farrel
<[email-masked]<mailto:[email-masked]>> wrote:
_______________________________________________
CCAMP mailing list
[email-masked]<mailto:[email-masked]>
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

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 10 Mar 2022 12:38:51 -0000

Hi Igor,

[AF] Good we agree on the architecture.

I think that the slice orchestrator (or whatever you call the thing that composes the e2e slice) will make requests to the transport network using the slice service model. Thus, at the least, we need a way to map the slice service model requests into OTN p2p connectivity services.

[AF] Agreed. Indeed, according to the 3GPP architecture, what is not a technology that can be made as a transport network and sliced?

[AF] Our only limit appears to be that we are the IETF so we are only slicing where IETF technologies are in use. Unless the dataplane is IP or MPLS, that seems to restrict us to cases where we are using an IETF control plane or IETF management structures (YANG models) to control the data plane.

IB: of course.

[AF] At some point, the top down service request has to meet the bottom up network engineering. If the Austrian’s neighbour (perhaps someone from Switzerland) comes into the shop and asks for a slice, the Austrian says, “Yes, of course, sir. What type of slice would you like?” And if the response is, “Tobacco,” does the Austrian laugh and say, “Don’t be ridiculous. Get out of my shop.” Or does he sell him a cigar while calling is a tobacco slice? 

>From my perspective, this is about generalising the top-down concept so that we have a common framework and technology-independent API. That has to be mapped to technologies (according to what technologies people actually want to support – no point in doing a mapping for NetBios?), and that is (I think) what lies behind the CCAMP OTN Slicing work.

Best,

Adrian

---

From: John E Drake <[email-masked]>
Date: Thu, 10 Mar 2022 14:37:18 +0000

A very good note and I agree with most of the points.  Additional comments inline below.

Yours Irrespectively,

John

Juniper Business Use Only
From: CCAMP <[email-masked]> On Behalf Of LUIS MIGUEL CONTRERAS MURILLO
Sent: Thursday, March 10, 2022 6:20 AM
To: Igor Bryskin <[email-masked]>; [email-masked]; 'Daniele Ceccarelli' <[email-masked]>; 'TEAS WG' <[email-masked]>; 'CCAMP' <[email-masked]>
Subject: Re: [CCAMP] [Teas] Decision point on scope of draft-ietf-teas-ietf-network-slices

[External Email. Be cautious of content]

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

[JD]  This is a most necessary piece of work

[JD]  We made the point in the Framework draft that the provider is free to provision its network however it wishes, so it may have to touch interior nodes in order to provide VPNs with SLOs;  I think this what the bestbar drafts propose.  Another approach is here:  https://datatracker.ietf.org/doc/html/draft-drake-bess-enhanced-vpn-07

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.

Luis

De: CCAMP <[email-masked]<mailto:[email-masked]>> En nombre de Igor Bryskin
Enviado el: jueves, 10 de marzo de 2022 1:47
Para: [email-masked]<mailto:[email-masked]>; Adrian Farrel <[email-masked]<mailto:[email-masked]>>; 'Daniele Ceccarelli' <[email-masked]<mailto:[email-masked]>>; 'TEAS WG' <[email-masked]<mailto:[email-masked]>>; 'CCAMP' <[email-masked]<mailto:[email-masked]>>
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:

Cheers,
Igor

Sent from Yahoo Mail on Android<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__;!!NEt6yMaO-gk!Qyoz-r3f5a0EUc-ILpW8PCPeBKGmJcUfWlfrEX_m9Ra2D4dtdftmVBNpwRCSkzA$>

https://www.ietf.org/mailman/listinfo/ccamp<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ccamp__;!!NEt6yMaO-gk!Qyoz-r3f5a0EUc-ILpW8PCPeBKGmJcUfWlfrEX_m9Ra2D4dtdftmVBNpoe1Nze8$>

---

From: "Rokui, Reza" <[email-masked]>
Date: Thu, 10 Mar 2022 15:19:53 +0000

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

Reza

From: CCAMP <[email-masked]> on behalf of LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Thursday, March 10, 2022 at 6:20 AM
To: Igor Bryskin <[email-masked]>, [email-masked] <[email-masked]>, 'Daniele Ceccarelli' <[email-masked]>, 'TEAS WG' <[email-masked]>, 'CCAMP' <[email-masked]>
Subject: [**EXTERNAL**] Re: [CCAMP] [Teas] Decision point on scope of draft-ietf-teas-ietf-network-slices
Hi all,

Luis

Hi Adrian,

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

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

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 10 Mar 2022 17:25:42 +0000 (UTC)

Hi Adrian,
I agree on the architecture and technology agnostic NBI, but this is not what OTN slicing seems to be about. Why would it have NBI of its own, when the whole point is to have orchestrator to talk to all transport technologies in exact same way (the very definition of technology agnostic paradigm)?
I agree on term "OTN slice", if it is understood as a euphenism for "OTN tunnel" or a "set of OTN tunnels" (tabacco slice -》 cigar )
And yes, top down dynamic process must meet somewhere with bottom up pre-planned network building. The question is where in the multi-layer network this point of rendezvoux could realistically be ? If our experience with top down nulti-layer TE is of any indication, this is likely to be the boundary between the top  layer and the layer immediately under it. This would mean that whenever IP layer is in the stack, it would be the only one to face NS  NBI. I hope you can follow this logic.
Igor

  On Thu, Mar 10, 2022 at 7:39 AM, Adrian Farrel<[email-masked]> wrote:   #yiv4963336221 #yiv4963336221 -- _filtered {} _filtered {}#yiv4963336221 #yiv4963336221 p.yiv4963336221MsoNormal, #yiv4963336221 li.yiv4963336221MsoNormal, #yiv4963336221 div.yiv4963336221MsoNormal {margin:0cm;font-size:11.0pt;font-family:sans-serif;}#yiv4963336221 p.yiv4963336221msolistparagraph, #yiv4963336221 li.yiv4963336221msolistparagraph, #yiv4963336221 div.yiv4963336221msolistparagraph {margin-right:0cm;margin-left:0cm;font-size:11.0pt;font-family:sans-serif;}#yiv4963336221 span.yiv4963336221EmailStyle21 {font-family:sans-serif;color:windowtext;}#yiv4963336221 .yiv4963336221MsoChpDefault {font-family:sans-serif;} _filtered {}#yiv4963336221 div.yiv4963336221WordSection1 {}#yiv4963336221 _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {}#yiv4963336221 ol {margin-bottom:0cm;}#yiv4963336221 ul {margin-bottom:0cm;}#yiv4963336221 
Hi Igor,

   

   

IB: of course.

Best,

Adrian

---

From: Fatai Zhang <[email-masked]>
Date: Fri, 11 Mar 2022 01:41:27 +0000

Hi Luis,

I agree with you, especially your points from an operator perspective.

Thanks
Fatai

发件人: CCAMP [mailto:[email-masked]] 代表 LUIS MIGUEL CONTRERAS MURILLO
发送时间: 2022年3月10日 19:20
收件人: Igor Bryskin <[email-masked]>; [email-masked]; 'Daniele Ceccarelli' <[email-masked]>; 'TEAS WG' <[email-masked]>; 'CCAMP' <[email-masked]>
主题: Re: [CCAMP] [Teas] Decision point on scope of draft-ietf-teas-ietf-network-slices

Hi all,

Luis

Hi Adrian,

Cheers,
Igor

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 11 Mar 2022 00:32:46 -0500

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 <
[email-masked]> 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
>
> *De:* CCAMP <[email-masked]> *En nombre de *Igor Bryskin
> *Enviado el:* jueves, 10 de marzo de 2022 1:47
> *Para:* [email-masked]; Adrian Farrel <[email-masked]>;
> 'Daniele Ceccarelli' <[email-masked]>; 'TEAS WG' <
> [email-masked]>; 'CCAMP' <[email-masked]>
> *Asunto:* Re: [CCAMP] [Teas] Decision point on scope of
> draft-ietf-teas-ietf-network-slices
>
>
>
> Hi Adrian,
>
>
>
>    - 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
>
>
>
>
>
> <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>
>
>
>
> <[email-masked]> wrote:
>
> ------------------------------
>
> 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
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*

---

From: Krzysztof Szarkowicz <[email-masked]>
Date: Fri, 11 Mar 2022 08:31:37 +0100

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.

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.

My 2 cents.

Kind regards,
Krzysztof

> On 2022 -Mar-11, at 06:32, Gyan Mishra <[email-masked]> wrote:
> 
> 
> Hi Luis 
> 
> 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 <[email-masked] <mailto:[email-masked]>> wrote:
> Hi all,
> 
>  
> 
>  Gyan>  Lots to gain for operators for being able to take advantage of IETF Network Slicing for other value added service offerings beyond 5G
> 
> 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.
> 
> De: CCAMP <[email-masked] <mailto:[email-masked]>> En nombre de Igor Bryskin
> Para: [email-masked] <mailto:[email-masked]>; Adrian Farrel <[email-masked] <mailto:[email-masked]>>; 'Daniele Ceccarelli' <[email-masked] <mailto:[email-masked]>>; 'TEAS WG' <[email-masked] <mailto:[email-masked]>>; 'CCAMP' <[email-masked] <mailto:[email-masked]>>
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/ccamp <https://www.ietf.org/mailman/listinfo/ccamp>
>  
> 
> 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/ccamp <https://www.ietf.org/mailman/listinfo/ccamp>
> -- 
> Gyan Mishra
> Network Solutions Architect 
> Email [email-masked] <mailto:[email-masked]>
> M 301 502-1347
> 
>

---

From: Italo Busi <[email-masked]>
Date: Fri, 11 Mar 2022 11:19:24 +0000

Thanks Luis for the good summary of the use cases: I agree that it is important to understand the use cases and not to limit the scope of the work

The use cases for OTN slicing are also discussed in the CCAMP draft to motivate that work as a complement to the work done in TEAS

Italo

From: LUIS MIGUEL CONTRERAS MURILLO [mailto:[email-masked]]
Sent: giovedì 10 marzo 2022 12:20
To: Igor Bryskin <[email-masked]>; [email-masked]; 'Daniele Ceccarelli' <[email-masked]>; 'TEAS WG' <[email-masked]>; 'CCAMP' <[email-masked]>
Subject: Re: [Teas] [CCAMP] Decision point on scope of draft-ietf-teas-ietf-network-slices

Hi all,

Luis

Hi Adrian,

Cheers,
Igor

---

From: Italo Busi <[email-masked]>
Date: Fri, 11 Mar 2022 11:33:24 +0000

Hi Igor,

I am not sure I fully understand what do you mean with “top-down” versus “bottom-up”

However, after having read the “creating VNs on the fly”, I have got the feeling that with “bottom-up” you are considering the cases where the connectivity is setup a-priori before receiving any request from the customer while with “top-down” you are considering the cases where the connectivity is setup “on-demand” based on a request received from the consumer

Could you please confirm/correct my understanding?

Thanks, Italo

From: Igor Bryskin [mailto:[email-masked]]
Sent: giovedì 10 marzo 2022 01:47
To: [email-masked]; Adrian Farrel <[email-masked]>; 'Daniele Ceccarelli' <[email-masked]>; 'TEAS WG' <[email-masked]>; 'CCAMP' <[email-masked]>
Subject: Re: [Teas] [CCAMP] Decision point on scope of draft-ietf-teas-ietf-network-slices

Hi Adrian,

Cheers,
Igor

---

From: Italo Busi <[email-masked]>
Date: Fri, 11 Mar 2022 11:36:38 +0000

Hi Igor,

You have said: “This would mean that whenever IP layer is in the stack, it would be the only one to face NS  NBI”

What about the cases where IP layer is not in the stack?

Thanks, Italo

From: Igor Bryskin [mailto:[email-masked]]
Sent: giovedì 10 marzo 2022 18:26
To: [email-masked]; Adrian Farrel <[email-masked]>; 'Daniele Ceccarelli' <[email-masked]>; 'TEAS WG' <[email-masked]>; 'CCAMP' <[email-masked]>
Subject: Re: [Teas] [CCAMP] Decision point on scope of draft-ietf-teas-ietf-network-slices

Hi Adrian,

Igor

On Thu, Mar 10, 2022 at 7:39 AM, Adrian Farrel
<[email-masked]<mailto:[email-masked]>> wrote:

Hi Igor,

IB: of course.

Best,

Adrian

---

From: John E Drake <[email-masked]>
Date: Fri, 11 Mar 2022 17:16:17 +0000

A most excellent analysis.

Sent from my iPhone

On Mar 11, 2022, at 2:32 AM, Krzysztof Szarkowicz <[email-masked]> wrote:

Hi Luis,

Nice summary.

My 2 cents.

Kind regards,
Krzysztof

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

Hi Luis

Nice summarization!

Responses In-line

Kind Regards

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

Luis

Hi Adrian,

Cheers,
Igor

Sent from Yahoo Mail on Android<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__;!!NEt6yMaO-gk!WCCTEnqpGkQTQk1dw1UyzzdMoAYp-N-SgOH4zCdOH7y1Pt_ngLyy52E-KrzGhzs$>

https://www.ietf.org/mailman/listinfo/ccamp<https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ccamp__;!!NEt6yMaO-gk!WCCTEnqpGkQTQk1dw1UyzzdMoAYp-N-SgOH4zCdOH7y1Pt_ngLyy52E-6nohuAQ$>

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
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ccamp<https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ccamp__;!!NEt6yMaO-gk!WCCTEnqpGkQTQk1dw1UyzzdMoAYp-N-SgOH4zCdOH7y1Pt_ngLyy52E-6nohuAQ$>
--

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<https://urldefense.com/v3/__http://www.verizon.com/__;!!NEt6yMaO-gk!WCCTEnqpGkQTQk1dw1UyzzdMoAYp-N-SgOH4zCdOH7y1Pt_ngLyy52E-fn7tKoo$>

Gyan Mishra
Network Solutions Architect
Email [email-masked]<mailto:[email-masked]>
M 301 502-1347

_______________________________________________
CCAMP mailing list
[email-masked]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ccamp__;!!NEt6yMaO-gk!WCCTEnqpGkQTQk1dw1UyzzdMoAYp-N-SgOH4zCdOH7y1Pt_ngLyy52E-6nohuAQ$

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Sat, 12 Mar 2022 01:52:52 +0000

Thanks to Luis for the analysis and summary from the operator's perspective, I agree with most of them.

And please find some replies inline:

From: CCAMP [mailto:[email-masked]] On Behalf Of John E Drake
Sent: Thursday, March 10, 2022 10:37 PM
To: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>; Igor Bryskin <[email-masked]>; [email-masked]; 'Daniele Ceccarelli' <[email-masked]>; 'TEAS WG' <[email-masked]>; 'CCAMP' <[email-masked]>
Subject: Re: [CCAMP] [Teas] Decision point on scope of draft-ietf-teas-ietf-network-slices

Yours Irrespectively,

John

Juniper Business Use Only
From: CCAMP <[email-masked]<mailto:[email-masked]>> On Behalf Of LUIS MIGUEL CONTRERAS MURILLO
Sent: Thursday, March 10, 2022 6:20 AM
To: Igor Bryskin <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; 'Daniele Ceccarelli' <[email-masked]<mailto:[email-masked]>>; 'TEAS WG' <[email-masked]<mailto:[email-masked]>>; 'CCAMP' <[email-masked]<mailto:[email-masked]>>
Subject: Re: [CCAMP] [Teas] Decision point on scope of draft-ietf-teas-ietf-network-slices

Hi all,

[Jie] Indeed, the framework and component functions we build to meet the requirements of 5G could also be used for other existing and emerging services. Thus generalization of the framework is important.

[Jie] Agree that some further discussion on the use cases could be helpful.

[Jie] To me "VPN with SLOs" can be seen as an approach to describe the service requirement. And depending on the specifics of the required SLO,  it may be realized either using traditional VPN and QoS technologies, or it may be realized as an enhanced VPN (VPN+). For the latter, the VPN+ framework introduces the concept VTN to provide distinction and customized treatment of different services or customers in the network.

Best regards,
Jie

Luis

Hi Adrian,

Cheers,
Igor

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Sat, 12 Mar 2022 02:49:13 +0000

Hi Krzysztof,

Thanks for the good analysis. Please see some comments inline:

From: CCAMP [mailto:[email-masked]] On Behalf Of Krzysztof Szarkowicz
Sent: Friday, March 11, 2022 3:32 PM
To: Luis Miguel Contreras Murillo <[email-masked]>
Cc: CCAMP <[email-masked]>; TEAS WG <[email-masked]>
Subject: Re: [CCAMP] [Teas] Decision point on scope of draft-ietf-teas-ietf-network-slices

Hi Luis,

Nice summary.

[Jie] This is the existing realization with traditional VPN + QoS based technologies.  As Luis mentioned, it can meet some SLO requirements, but not all of them in the 5G or other general cases.

[Jie] Agree there will be cost when introducing states to transit nodes, and we should be careful and try to minimize the amount of states when doing so.

[Jie] Indeed lessons should be learned from ATM or DS-aware TE, both of them introduces per-path state on transit nodes, which can have significant scalability issues in large deployment.

The approach described in VPN+ framework is to only introduce per-VTN (instead of per-path) state to the transit nodes, and allows flexible mapping between VPN+ services and the VTNs.

[Jie] As in my reply to Luis in previous mail, “VPN with SLO” can be seen as one approach to describe the service requirements, it can be applied to network slice services for both 5G and non-5G cases (e.g., the business VPN you mentioned). Operators will pick the suitable realization based on the specifics of the SLOs and SLEs. And you have provided a case with requirement for resource isolation.

Best regards,
Jie

My 2 cents.

Kind regards,
Krzysztof

Hi Luis

Nice summarization!

Responses In-line

Kind Regards

Gyan

Luis

Hi Adrian,

Cheers,
Igor

[图像已被发件人删除。]<http://www.verizon.com/>

---

From: Tarek Saad <[email-masked]>
Date: Mon, 14 Mar 2022 15:22:15 +0000

Hi Krzysztof and Luis,

Thanks for sharing your thoughts. See inline..

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

Nice summary.

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.

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

Hi Luis

Nice summarization!

Responses In-line

Kind Regards

Gyan

Luis

Hi Adrian,

Cheers,
Igor

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<http://www.verizon.com/>

---

From: Igor Bryskin <[email-masked]>
Date: Mon, 14 Mar 2022 17:00:20 +0000 (UTC)

Tarek,
In your ns-packet framework do you see NRPs and the knowledge about them (e.g. in the form of NRP topologies) as a pre-configured input to the ns manipulation process or direct part of it? In particular, do you envision creation of  an NRP on the fly reacting to a new NS request?
Thanks,Igor

  On Mon, Mar 14, 2022 at 11:23 AM, Tarek Saad<[email-masked]> wrote:   _______________________________________________
Teas mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/teas

---

From: Tarek Saad <[email-masked]>
Date: Mon, 14 Mar 2022 17:38:47 +0000

Hi Igor,

>> In your ns-packet framework do you see NRPs and the knowledge about them (e.g. in the form of NRP topologies) as a pre-configured input to the ns manipulation process or direct part of it? In part…
[TS]: indeed, as described in draft-bestbar-teas-ns-packet, the NRP can be instantiated on-demand (via the NRP Policy) in order to cater to traffic from one or more IETF network slice(s). Once instantiated, the NRP may also be resized if/when required (via NRP Policy update) to cater for more/less NS(es).

Regards,
Tarek

From: Igor Bryskin <[email-masked]>
Date: Monday, March 14, 2022 at 1:00 PM
To: [email-masked] <[email-masked]>, Tarek Saad <[email-masked]>, Krzysztof Szarkowicz <[email-masked]>, LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Cc: Gyan Mishra <[email-masked]>, CCAMP <[email-masked]>, TEAS WG <[email-masked]>, [email-masked] <[email-masked]>, Daniele Ceccarelli <[email-masked]>
Subject: Re: [Teas] [CCAMP] Decision point on scope of draft-ietf-teas-ietf-network-slices
Tarek,

Thanks,
Igor

On Mon, Mar 14, 2022 at 11:23 AM, Tarek Saad
<[email-masked]> wrote:
_______________________________________________
Teas mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/teas

---

From: Igor Bryskin <[email-masked]>
Date: Mon, 14 Mar 2022 20:04:00 +0000 (UTC)

Tarek,
I don't mind creation/manipulation of NRPs on the fly, but only as long as it does not require re-configuration of underlying  transport layer networks. Otherwise, how do you guarantee any level of optimality of transport resource utilization? For example, how do you ensure that  the newly created 400G Och trails do not remain 5% utilized for the remainder of the NRP's life time? Note that subsequent resizing of the NRP won't help because:- it would be very difficult to achieve, especially, if IP layer spans multiple transport networks;- would be destructive to existing service unpredictably violating their SLOs;- as inefficient and imprudent as the very automatic creation of yhe NRPs in the first place 
In a way it would be not unlike creating , say,  Boeing 777 service Washington DC - Sydney just  because several Australians showed up in the Dulles Airport.Do you agree with the analogy?
Igor
Sent from Yahoo Mail on Android 
 
  On Mon, Mar 14, 2022 at 1:39 PM, Tarek Saad<[email-masked]> wrote:   _______________________________________________
Teas mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/teas

---

From: Tarek Saad <[email-masked]>
Date: Mon, 14 Mar 2022 20:51:49 +0000

Yes, agreed. The management and optimization of NRP resources in the network is key.
It would be possible (and up to the NSC) to decide whether to pin existing NRP resources, or whether to aggregate/multiplex new services on top of a new or an existing NRP.
As you point out, the underlying network resource utilization and/or policies that are in-place can indeed govern the above decisions.

Regards,
Tarek

From: Igor Bryskin <[email-masked]>
Date: Monday, March 14, 2022 at 4:04 PM
To: [email-masked] <[email-masked]>, Tarek Saad <[email-masked]>, Krzysztof Szarkowicz <[email-masked]>, LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Cc: [email-masked] <[email-masked]>, CCAMP <[email-masked]>, Gyan Mishra <[email-masked]>, TEAS WG <[email-masked]>, Daniele Ceccarelli <[email-masked]>
Subject: Re: [Teas] [CCAMP] Decision point on scope of draft-ietf-teas-ietf-network-slices
Tarek,

I don't mind creation/manipulation of NRPs on the fly, but only as long as it does not require re-configuration of underlying  transport layer networks. Otherwise, how do you guarantee any level of optimality of transport resource utilization? For example, how do you ensure that  the newly created 400G Och trails do not remain 5% utilized for the remainder of the NRP's life time? Note that subsequent resizing of the NRP won't help because:
- it would be very difficult to achieve, especially, if IP layer spans multiple transport networks;
- would be destructive to existing service unpredictably violating their SLOs;
- as inefficient and imprudent as the very automatic creation of yhe NRPs in the first place

In a way it would be not unlike creating , say,  Boeing 777 service Washington DC - Sydney just  because several Australians showed up in the Dulles Airport.
Do you agree with the analogy?

Igor

On Mon, Mar 14, 2022 at 1:39 PM, Tarek Saad

---

From: Igor Bryskin <[email-masked]>
Date: Mon, 14 Mar 2022 21:27:30 +0000 (UTC)

Tarek,
I think you are missing the point. You are basically saying that top-down multi-layer TE is possible, and it is up to a smart NSC to realize it. I am saying that we have tried that many times from different angles and have failed to achieve that so far, even on two-layer OTN/Och networks - most natural low growing fruit for this kind of thing. What makes you think that NS effort shows a better promise for the success?
Cheers,Igor

  On Mon, Mar 14, 2022 at 4:52 PM, Tarek Saad<[email-masked]> wrote:   _______________________________________________
Teas mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/teas

---

From: Aihua Guo <[email-masked]>
Date: Mon, 14 Mar 2022 18:16:30 -0400

Hi Igor,

For OTN/OCh tunnels, both top-down and bottom-up creation are supported and
solutions have been deployed in the field AFAIK. The TE tunnel model also
supports the top-down approach by using the "dependent-tunnel"
configuration.

For example, a request for a 100GE client signal can drive the creation of
an OTU-4 OTN tunnel, which can drive the creation of an underlying OCh if
it is not present and policy permits it.

Thanks,
Aihua

On Mon, Mar 14, 2022 at 5:28 PM Igor Bryskin <i_bryskin=
[email-masked]> wrote:

> Tarek,
>
> I think you are missing the point. You are basically saying that top-down
> multi-layer TE is possible, and it is up to a smart NSC to realize it. I am
> saying that we have tried that many times from different angles and have
> failed to achieve that so far, even on two-layer OTN/Och networks - most
> natural low growing fruit for this kind of thing. What makes you think that
> NS effort shows a better promise for the success?
>
> Cheers,
> Igor
>
> On Mon, Mar 14, 2022 at 4:52 PM, Tarek Saad

---

From: Igor Bryskin <[email-masked]>
Date: Mon, 14 Mar 2022 22:48:17 +0000 (UTC)

Aihua,
I know very well what is in the models. I am talking about what is in the field. It is something up to providers to confirm or deny.
Cheers,Igor

  On Mon, Mar 14, 2022 at 6:17 PM, Aihua Guo<[email-masked]> wrote:   _______________________________________________
Teas mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/teas