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

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 7 Mar 2022 11:49:52 -0000

Hi,

I’m changing the subject line to extract a question from Igor’s email.

With respect to whether “IETF Network Slices” are limited to use for 5G services, Igor asks, “it would be helpful if the framework identified clearer/narrower its focus.”

What do other people think? Should the document state that slicing of IETF technology networks is intended only to support 5G network slicing as a “transport network slice”?

My personal view is that Igor makes a very good point that “VPNs with SLOs” have been available as a matter of contractual negotiation between customers and service providers, but there has been no standard way of asking for this. Both enhanced VPN and network slicing make moves towards formalising this service.

In fact, my interest in network slicing goes beyond 5G to consider all manner of service users that want complex connectivity services with service guarantees. I feel that enterprises, especially those supporting applications that need low latency (such as collaborative gaming or VR), will become consumers of network slice services.

Cheers,

Adrian

From: Igor Bryskin <[email-masked]> 
Sent: 07 March 2022 01:22
To: [email-masked]; Gyan Mishra <[email-masked]>
Cc: Adrian Farrel <[email-masked]>; Ogaki, Kenichi <[email-masked]>; [email-masked]; TEAS WG <[email-masked]>
Subject: Re: [Teas] Upcoming changes to draft-ietf-teas-ietf-network-slices

Hi Gyan,

Thanks for the thoughtful and detailed response. Indeed, this is an important discussion.

1. IMHO IETF network slicing does not mean something wider than 5G network slicing. On the contrary, I'd argue it is narrower than 5G network slicing. It is  just a way to say that IETF cannot take care of 5G slicing end to end, rather, it can only focus on certain segments of 5G service (e.g. core network, back hawl, etc.), but not all (e.g. RAN).

2. The fact that things like VPN with SLOs existed as an idea for 20 years, but is taken  on realization  only now, after 5G came along (requiring the same SLOs) does not mean that we are defining something that is not limited to 5G - nothing prevents any client to take advantage of some/all  functions of 5G network slicing. This is just a lucky  byproduct.

3. The outcome of this discussion may have consequences that are not entirely harmless. For e ample, as we see in CCAMP,  because the framework stipulates  IETF network slicing to be not only about 5G, folks are already working on things like OTN slicing, and soon will be working on microwave and all other transport layer slicing. Do we really want to go there?

The bottom line: it would be helpful if the framework  indentified clearer/narrower its  focus. 

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 Sun, Mar 6, 2022 at 7:07 PM, Gyan Mishra

<[email-masked] <mailto:[email-masked]> > wrote:

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

---

From: Lou Berger <[email-masked]>
Date: Mon, 7 Mar 2022 12:19:12 +0000

Umm, I thought this was already addressed on page three of the draft.  Are you suggesting that the document be revised to cover just the first bullet - 5g?

Thanks
Lou

________________________________

On March 7, 2022 6:50:15 AM Adrian Farrel <[email-masked]> wrote:
Hi,

Cheers,
Adrian

Hi Gyan,

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 Sun, Mar 6, 2022 at 7:07 PM, Gyan Mishra
<[email-masked]<mailto:[email-masked]>> wrote:
_______________________________________________
Teas mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/teas

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 7 Mar 2022 12:33:39 -0000

I am not suggesting any such thing!

Igor, I believe, is suggesting it.

My job (I believe) is to make sure that questions raised are given an airing
so that I can make any edits that the working group deems appropriate. Hence
the email (because Igor's point was buried in a thread with an old subject
line).

Cheers,

Adrian

From: Lou Berger <[email-masked]> 
Sent: 07 March 2022 12:19
To: [email-masked]; 'TEAS WG' <[email-masked]>
Subject: Re: [Teas] Decision point on scope of
draft-ietf-teas-ietf-network-slices

Umm, I thought this was already addressed on page three of the draft.  Are
you suggesting that the document be revised to cover just the first bullet -
5g?

Thanks
Lou

  _____  

On March 7, 2022 6:50:15 AM Adrian Farrel <[email-masked]
<mailto:[email-masked]> > wrote:

Hi,

I'm changing the subject line to extract a question from Igor's email.

With respect to whether "IETF Network Slices" are limited to use for 5G
services, Igor asks, "it would be helpful if the framework identified
clearer/narrower its focus."

What do other people think? Should the document state that slicing of IETF
technology networks is intended only to support 5G network slicing as a
"transport network slice"?

My personal view is that Igor makes a very good point that "VPNs with SLOs"
have been available as a matter of contractual negotiation between customers
and service providers, but there has been no standard way of asking for
this. Both enhanced VPN and network slicing make moves towards formalising
this service.

In fact, my interest in network slicing goes beyond 5G to consider all
manner of service users that want complex connectivity services with service
guarantees. I feel that enterprises, especially those supporting
applications that need low latency (such as collaborative gaming or VR),
will become consumers of network slice services.

Cheers,

Adrian

From: Igor Bryskin <[email-masked] <mailto:[email-masked]> > 
Sent: 07 March 2022 01:22
To: [email-masked] <mailto:[email-masked]> ; Gyan Mishra
<[email-masked] <mailto:[email-masked]> >
Cc: Adrian Farrel <[email-masked] <mailto:[email-masked]> >;
Ogaki, Kenichi <[email-masked] <mailto:[email-masked]> >;
[email-masked] <mailto:[email-masked]> ; TEAS WG
<[email-masked] <mailto:[email-masked]> >
Subject: Re: [Teas] Upcoming changes to draft-ietf-teas-ietf-network-slices

Hi Gyan,

Thanks for the thoughtful and detailed response. Indeed, this is an
important discussion.

1. IMHO IETF network slicing does not mean something wider than 5G network
slicing. On the contrary, I'd argue it is narrower than 5G network slicing.
It is  just a way to say that IETF cannot take care of 5G slicing end to
end, rather, it can only focus on certain segments of 5G service (e.g. core
network, back hawl, etc.), but not all (e.g. RAN).

2. The fact that things like VPN with SLOs existed as an idea for 20 years,
but is taken  on realization  only now, after 5G came along (requiring the
same SLOs) does not mean that we are defining something that is not limited
to 5G - nothing prevents any client to take advantage of some/all  functions
of 5G network slicing. This is just a lucky  byproduct.

3. The outcome of this discussion may have consequences that are not
entirely harmless. For e ample, as we see in CCAMP,  because the framework
stipulates  IETF network slicing to be not only about 5G, folks are already
working on things like OTN slicing, and soon will be working on microwave
and all other transport layer slicing. Do we really want to go there?

The bottom line: it would be helpful if the framework  indentified
clearer/narrower its  focus. 

Cheers,

Igor

 

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

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Mon, 7 Mar 2022 07:06:43 -0600

Adrian,

I think the scope of the document as is stated in the current version of
the document is apt. I don't see the need to change it.
Please see inline for more..

Regards,
-Pavan

On Mon, Mar 7, 2022 at 5:50 AM Adrian Farrel <[email-masked]> wrote:

> With respect to whether “IETF Network Slices” are limited to use for 5G
> services, Igor asks, “it would be helpful if the framework identified
> clearer/narrower its focus.”
>
>
>
> “transport network slice”?
>

[VPB] No.

>
>
> My personal view is that Igor makes a very good point that “VPNs with
> SLOs” have been available as a matter of contractual negotiation between
> customers and service providers, but there has been no standard way of
> asking for this.
>

[VPB] I think there is no dispute that the notion of "VPNs with SLOs" has
been available for a while. And depending on the SLOs, one might even argue
that there are already standard ways for asking for this. If there is
anything that I have discerned from the discussion on this topic in the WG
in the past few years, it is that there has been a shift in the semantics
of SLOs/SLEs (more and more applications require stricter service
guarantees -- and this is not limited to 5G) and that there are gaps (in
the existing toolkit) in terms of how these newer and more complex services
are requested and catered to.

> Both enhanced VPN and network slicing make moves towards formalising this
> service.
>
>
>
> manner of service users that want complex connectivity services with
> service guarantees. I feel that enterprises, especially those supporting

Cheers,
>
> Adrian
>
>
>
> *From:* Igor Bryskin <[email-masked]>
> *Sent:* 07 March 2022 01:22
> *To:* [email-masked]; Gyan Mishra <[email-masked]>
> *Cc:* Adrian Farrel <[email-masked]>; Ogaki, Kenichi <
> [email-masked]>; [email-masked]; TEAS WG <[email-masked]>
> *Subject:* Re: [Teas] Upcoming changes to
> 2. The fact that things like VPN with SLOs existed as an idea for 20
> years, but is taken  on realization  only now, after 5G came along
> (requiring the same SLOs) does not mean that we are defining something that
> is not limited to 5G - nothing prevents any client to take advantage of
> some/all  functions of 5G network slicing. This is just a lucky  byproduct.
>
>
>
> <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:
>
> [email-masked]
> [email-masked]

---

From: John E Drake <[email-masked]>
Date: Mon, 7 Mar 2022 14:16:46 +0000

Hi,

Comments inline below.

Yours Irrespectively,

John

Juniper Business Use Only
From: Teas <[email-masked]> On Behalf Of Adrian Farrel
Sent: Monday, March 7, 2022 6:50 AM
To: 'TEAS WG' <[email-masked]>
Subject: [Teas] Decision point on scope of draft-ietf-teas-ietf-network-slices

[External Email. Be cautious of content]

Hi,

With respect to whether "IETF Network Slices" are limited to use for 5G services, Igor asks, "it would be helpful if the framework identified clearer/narrower its focus."

What do other people think? Should the document state that slicing of IETF technology networks is intended only to support 5G network slicing as a "transport network slice"?

[JD]  Absolutely not.

My personal view is that Igor makes a very good point that "VPNs with SLOs" have been available as a matter of contractual negotiation between customers and service providers, but there has been no standard way of asking for this. Both enhanced VPN and network slicing make moves towards formalising this service.

[JD]  That's correct.

[JD]  I agree with this.

Cheers,
Adrian

From: Igor Bryskin <[email-masked]<mailto:[email-masked]>>
Sent: 07 March 2022 01:22
To: [email-masked]<mailto:[email-masked]>; Gyan Mishra <[email-masked]<mailto:[email-masked]>>
Cc: Adrian Farrel <[email-masked]<mailto:[email-masked]>>; Ogaki, Kenichi <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; TEAS WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Teas] Upcoming changes to draft-ietf-teas-ietf-network-slices

Hi Gyan,

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!Q2jdenDVcDB6Urtc-Tn1c2d-or3nUFHl4NTfENLlOT-BNyBbYtjX65XzbdCIhdQ$>

https://www.ietf.org/mailman/listinfo/teas<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!Q2jdenDVcDB6Urtc-Tn1c2d-or3nUFHl4NTfENLlOT-BNyBbYtjX65XzzgSUr8A$>

---

From: Igor Bryskin <[email-masked]>
Date: Mon, 7 Mar 2022 14:56:02 +0000 (UTC)

Hi Lou,
This is exactly what I am suggesting. Let's (with open mind) focus first on 5G needs and after that let's see what, if anything, is missing for other potential clients like on-line gaming, IPTV, VPNs with SLOs, etc.After all, if not for 5G, we would probably not be having this conversation at all. As far as I know, we have not defined yet anything that 5G won't need, so why we don't just say that, so that, for example, CCAMPers will not be considered  into believing that the NS framework endorses the work on OTN slicing.
Cheers,Igor

  On Mon, Mar 7, 2022 at 9:17 AM, John E Drake<jdrake=[email-masked]> wrote:   _______________________________________________
Teas mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/teas

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 7 Mar 2022 10:13:35 -0500

Hi Igor

Your main point is that as 5G has driven TEAS to develop the framework
draft, however if we hone in network slicing now that would limit
applicability to other technologies beyond 5G to only later make the
framework inclusive.  Why not make it inclusive now?

The major caveat I can see that as we develop the framework draft, we can
look at it from other use case POV perspective for VPNs with SLO today as
well as any other technology such as Optical or any other use case, so the
framework draft accommodates the immediate need for 5G but now we are also
ensuring that framework will cover other use cases.

If we limit to 5G only we would have to revisit the framework draft in the
future to add back anything that is not 5G specific.  It does seem that the
current revision 8 covers VPNs with SLO today so then why not keep it open.

Optical slicing has come up with CCAMP and there maybe other technologies
but is that a bad thing is the question?

Kind Regards

Gyan

On Mon, Mar 7, 2022 at 9:56 AM Igor Bryskin <i_bryskin=
[email-masked]> wrote:

> Hi Lou,
>
> This is exactly what I am suggesting. Let's (with open mind) focus first
> on 5G needs and after that let's see what, if anything, is missing for
> other potential clients like on-line gaming, IPTV, VPNs with SLOs, etc.
> After all, if not for 5G, we would probably not be having this
> conversation at all. As far as I know, we have not defined yet anything
> that 5G won't need, so why we don't just say that, so that, for example,
> CCAMPers will not be considered  into believing that the NS framework
> endorses the work on OTN slicing.
>
> Cheers,
> Igor
>
>
>
> On Mon, Mar 7, 2022 at 9:17 AM, John E Drake
> <jdrake=[email-masked]> wrote:
-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

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

*M 301 502-1347*

---

From: Igor Bryskin <[email-masked]>
Date: Mon, 7 Mar 2022 15:23:59 +0000 (UTC)

Pavan,
What makes you think that what we have been discussing so far goes beyond 5G needs? Specifically,  which exactly connectivity types, SLOs, SLEs, etc. discussed so far will not be required by 5G?
Lack of focus on 5G, on the other hand, creates confusion. Tell me:what does it mean to guarantee SLO or SLE? 5G has a very clear definition of that.
 Is a bunch of OTN tunnels is a netwrk slice, NRP, bottom up network building option, all of the above, none of the above? Which connectivity service is definitely not a slice?
Igor

  On Mon, Mar 7, 2022 at 9:56 AM, Igor Bryskin<i_bryskin=[email-masked]> wrote:   _______________________________________________
Teas mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/teas

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 7 Mar 2022 10:41:37 -0500

I think I am missing your point Igor.

There are four bullets listed in the introduction.  We could of course 
agree to change that.  Why would we do so?

If there are no differences in the effective needs, them recognizing 
them all is helpful.

If there are differences, knowing what they are and planning early to 
address the broader range seems helpful.

In neither case does narrowing the scope seem to help us.

Yours,
Joel

On 3/7/2022 10:23 AM, Igor Bryskin wrote:
> Pavan,
> 
> What makes you think that what we have been discussing so far goes 
> beyond 5G needs? Specifically,  which exactly connectivity types, SLOs, 
> SLEs, etc. discussed so far will not be required by 5G?
> 
> Lack of focus on 5G, on the other hand, creates confusion. Tell me:
> what does it mean to guarantee SLO or SLE? 5G has a very clear 
> definition of that.
> 
>   Is a bunch of OTN tunnels is a netwrk slice, NRP, bottom up network 
> building option, all of the above, none of the above? Which connectivity 
> service is definitely not a slice?
> 
> Igor
> 
>     On Mon, Mar 7, 2022 at 9:56 AM, Igor Bryskin
>     <i_bryskin=[email-masked]> wrote:
>     <https://www.ietf.org/mailman/listinfo/teas>
> 
>

---

From: Igor Bryskin <[email-masked]>
Date: Mon, 7 Mar 2022 15:43:12 +0000 (UTC)

Hi Gyan,
IMHO network slicing is inherently top-down emerging process aiming at realization of various connectivity constructs of different types and complexity levels that guarantee agreed upon SLOs through the lifetime of a network slice.  OTN, being a transport layer, can only offer bottom-up network building capabilities via realization of p2p data links for higher layer clients. This is the only thing a transport layer has been doing and is expected to be doing in the NS framework.
Consider, for example, an application requiring a p2mp distribution and asking for a network slice. While implementing required slice, network's IP layer may request help from the underlying OTN, but this help should not be understood IMHO as OTN slicing (which would be the case, for example, if IP layer was attempting to map the required p2mp tree onto a p2mp connection established in OTN). Rather, IP, when seeing that it does not have enough resources in IP layer to satisfy the request, may ask from the OTN (and not just one OTN, because IP may span multiple independent OTN networks and not just OTNs, but transport networks of different types, including not involving OTN layer at all, but other transports such as FlexE, microwave, etc.) to enrich the IP topology with additional IP links supported by the underlying transport layer tunnels. Such additions are not OTN (or other transport) slices, rather, they are additional NRPs (Network Resource Partitions) as Pavan's, Tarek's and Co. ns-packet-slicing draft correctly defines.
So, yes, I do not like the idea of OTN slicing, which, incidentally has nothing to do with 5G.
Cheers,Igor
Sent from Yahoo Mail on Android 
 
  On Mon, Mar 7, 2022 at 10:24 AM, Igor Bryskin<i_bryskin=[email-masked]> wrote:   Pavan,
What makes you think that what we have been discussing so far goes beyond 5G needs? Specifically,  which exactly connectivity types, SLOs, SLEs, etc. discussed so far will not be required by 5G?
Lack of focus on 5G, on the other hand, creates confusion. Tell me:what does it mean to guarantee SLO or SLE? 5G has a very clear definition of that.
 Is a bunch of OTN tunnels is a netwrk slice, NRP, bottom up network building option, all of the above, none of the above? Which connectivity service is definitely not a slice?
Igor

---

From: Igor Bryskin <[email-masked]>
Date: Mon, 7 Mar 2022 16:12:48 +0000 (UTC)

Hi Joel,
My point is focusing on 5G  is the most expedite way to help 3Gpp folks and engage them in bidirectional cooperation, just like focusing on Ukrain, for example, is the surest way to help Ukrain, despite, Georgia, Moldova, Kazakhstan have exact same problems, needs and demands.
My second point, is such focus may deter folks from working on things like transport layer slicing,  which I personally think would be a waste of time.
Also yours,Igor

  On Mon, Mar 7, 2022 at 10:43 AM, Igor Bryskin<i_bryskin=[email-masked]> wrote:   _______________________________________________
Teas mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/teas

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 7 Mar 2022 16:25:16 -0000

> My point is focusing on 5G  is the most expedite way to help 3Gpp

> folks and engage them in bidirectional cooperation, just like focusing

> on Ukrain, for example, is the surest way to help Ukrain, despite,

> Georgia, Moldova, Kazakhstan have exact same problems, needs

> and demands.

Igor, that is poor taste, untrue, and unworthy of you.

Can we please stick to technical discussions on this list.

Adrian

---

From: Daniele Ceccarelli <[email-masked]>
Date: Mon, 7 Mar 2022 16:58:07 +0000

Hi Igor,

I still have some concerns regarding network slicing being done at the OTN layer, but I don’t understand how this is related to network slicing being confined to 5G only.
In other words I don’t understand why 5G only needs network slicing at packet layer while other applications would allow extending it to OTN and lower layers.

Cheers,
Daniele

From: Teas <[email-masked]> On Behalf Of Igor Bryskin
Sent: den 7 mars 2022 15:56
To: jdrake=[email-masked]; John E Drake <jdrake=[email-masked]>; [email-masked]; 'TEAS WG' <[email-masked]>
Subject: Re: [Teas] Decision point on scope of draft-ietf-teas-ietf-network-slices

Hi Lou,

This is exactly what I am suggesting. Let's (with open mind) focus first on 5G needs and after that let's see what, if anything, is missing for other potential clients like on-line gaming, IPTV, VPNs with SLOs, etc.
After all, if not for 5G, we would probably not be having this conversation at all. As far as I know, we have not defined yet anything that 5G won't need, so why we don't just say that, so that, for example, CCAMPers will not be considered  into believing that the NS framework endorses the work on OTN slicing.

Cheers,
Igor

<jdrake=[email-masked]<mailto:jdrake=[email-masked]>> wrote:

---

From: Igor Bryskin <[email-masked]>
Date: Mon, 7 Mar 2022 18:03:21 +0000 (UTC)

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

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

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 7 Mar 2022 13:55:43 -0500

Hi Igor

I understand your point and some of us here were as well were on the OTN
slice discussion including both of us and Adrian.

https://datatracker.ietf.org/doc/html/draft-zheng-ccamp-yang-otn-slicing-03

I understand the issue with OTN slicing and maybe we can address that with
the OTN authors regarding top down versus bottom up approach- understood
and agreed as I recall that mentioned in the thread.

So OTN is one concern which I can understand the reasoning.

What is the issue with IP VPN taking being in scope for Enhanced VPN?

Hypothetically if we made an explicit permit making all IP VPN use cases in
scope followed by an explicit deny of any other use cases would that
satisfy your concerns?

Another way to word it would be  Non IP networks are forbidden.

Kind Regards

Gyan
On Mon, Mar 7, 2022 at 10:43 AM Igor Bryskin <i_bryskin=
[email-masked]> wrote:

> Hi Gyan,
>
> IMHO network slicing is inherently top-down emerging process aiming at
> realization of various connectivity constructs of different types and
> complexity levels that guarantee agreed upon SLOs through the lifetime of a
> network slice.  OTN, being a transport layer, can only offer bottom-up
> network building capabilities via realization of p2p data links for higher
> layer clients. This is the only thing a transport layer has been doing and
> is expected to be doing in the NS framework.
>
> Consider, for example, an application requiring a p2mp distribution and
> asking for a network slice. While implementing required slice, network's IP
> layer may request help from the underlying OTN, but this help should not be
> understood IMHO as OTN slicing (which would be the case, for example, if IP
> layer was attempting to map the required p2mp tree onto a p2mp connection
> established in OTN). Rather, IP, when seeing that it does not have enough
> resources in IP layer to satisfy the request, may ask from the OTN (and not
> just one OTN, because IP may span multiple independent OTN networks and not
> just OTNs, but transport networks of different types, including not
> involving OTN layer at all, but other transports such as FlexE, microwave,
> etc.) to enrich the IP topology with additional IP links supported by the
> underlying transport layer tunnels. Such additions are not OTN (or other
> transport) slices, rather, they are additional NRPs (Network Resource
> Partitions) as Pavan's, Tarek's and Co. ns-packet-slicing draft correctly
> defines.
>
> On Mon, Mar 7, 2022 at 10:24 AM, Igor Bryskin
> What makes you think that what we have been discussing so far goes beyond
> 5G needs? Specifically,  which exactly connectivity types, SLOs, SLEs, etc.
> discussed so far will not be required by 5G?
>
> what does it mean to guarantee SLO or SLE? 5G has a very clear definition
> of that.
>
-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: Aihua Guo <[email-masked]>
Date: Mon, 7 Mar 2022 14:44:28 -0500

Hi Igor, all,

To say network slicing is only for 5G or traffic is only IP, is a bit too
narrow in scope, IMO.

- There are use cases for non-IP network, such as OTN, to carry both IP and
non-IP traffic from end user to the cloud or between DC and DC.
- There are use cases for non-IP traffic, such as 4k/8k video to be carried
end to end on circuit-emulated IP networks or circuit-native networks such
as OTN and DWDM.
- There are even emerging use cases for optical satellite communications
where the network links between LEO/GEO satellites, space station and the
ground are all optical. Such networks can carry IP or non-IP data. This
scenario is actively being discussed in this week’s OFC conference.

In all the above use cases, it can be envisioned that there is a need for a
“consumer” who needs services from operators of these networks, to ask for
some kind of service as a group of network resources with specific level of
quality.

Imagine if I am someone who owns an OTN network or an optical satellite
network, and I provide slices as services to which consumer who needs them
and is willing to pay.

We understand that networking of IP, optical, etc. are all in the scope for
IETF and TEAS. If the framework for network slicing is sufficiently
generic, as it should, then why we cannot apply the same terminology
towards those use cases, and construct it as a “slice”? Why we need to self
restrict the framework to only 5G or IP if we can make it more generic?

Yours,
Aihua

On Mon, Mar 7, 2022 at 10:19 AM Igor Bryskin <i_bryskin=
[email-masked]> wrote:

> 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
>
> On Mon, Mar 7, 2022 at 12:01 PM, Daniele Ceccarelli
> <daniele.ceccarelli=[email-masked]> wrote:

---

From: Igor Bryskin <[email-masked]>
Date: Mon, 7 Mar 2022 20:51:31 +0000 (UTC)

Hi Gyan,
I am not a 3gpp person, but if I was  I'd say this:
If enhanced VPN does not go beyond 5G requirements, then it does not matter much one way or the other, otherwise, this is a distraction as far as 5G is concerned. Whatever waited for 20 years can surely wait for another couple of years while enjoying for free the results of this incredible energy generated entirely by 5G.
Cheers,Igor

  On Mon, Mar 7, 2022 at 1:56 PM, Gyan Mishra<[email-masked]> wrote:   _______________________________________________
Teas mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/teas

---

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,

Cheers,
Igor

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

---

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

---

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: Igor Bryskin <[email-masked]>
Date: Wed, 9 Mar 2022 13:37:19 +0000 (UTC)

Daniele,
I agree with you. This was my exact argument all along. We don't want to confuse supporting slicing with performing/ realizing  slicing.
I am hoping to hear from the framework authors. 
My additional concern is WRT the top- down approach, which, as Adrian and Gyan on many occasions correctly described as essential to the network slicing.
Our experience tells us that it is notoriously complex to directly involve transport layers in top down network control, especially when top is wider than bottom. For example, we didn't go very far with top down two layer traffic engineering even in OTN/Och networks, arguably the most natural environment for such an approach. The main reason for that is that it proved to be impractical ( to say the least) to reconfigure lower layer based solely on request in a higher layer. 
Cheers,Igor

  On Mon, Mar 7, 2022 at 1:03 PM, Igor Bryskin<[email-masked]> wrote:   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

---

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

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

---

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

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

*Gyan Mishra*

*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