Subject: [Teas] Why term transport slice? WG adoption - draft-nsdt-teas-transport-slice-definition

From: "Rokui, Reza (Nokia - CA/Ottawa)" <[email-masked]>
Date: Fri, 4 Sep 2020 14:16:28 +0000

All,

Thanks for all feedbacks.

Let’s step back and address these questions: How and why the authors’ of the draft chose the term “Transport Slice”?

Before formation of the TEAS WG NSDT, there were lots of discussions and drafts to address the role of IETF for network slicing. Those discussion and drafts tried to address the network slicing  from different perspectives but in most cases they had one thing in common, they started by discussion the network slicing but at the end they really meant the Transports portion of the network slice. In other words, although the name of the draft and discussion was network slicing, but they just talked about Transport portion.  In other hand, the term network slice and Transport portion of a network slice were used interchangeably.

After creation of the NSDT, we collectively thoughts that the first order of business is to clarify this. So, the “draft definition” started. The following are the reasons:

Reason 1)
The first reason for this draft is to make very clear distinction between a network slice (defined for example by 3GPP) and transport portion of a network slice.
In our opinion it is essential to make a clear distinction between network slice and transport portion of a network slice. They are NOT the same since a network slice contain the transport portion.
The picture below was outcome of that discussion. In summary, a network slice is an end-to-end context and depends on the used case (i.e 5G, DCI, etc), it might contain a few other components (i.e. RAN, Transport, Core etc.)

Reason 2)
We just established the fact that an end-to-end network slice is different from transport portion of the network slice. The next question is that what the definition of the Transport portion of a network slice is.
This is fully discussed in draft but in summary the transport portion of a network slice describes the CONNECTIVITY between various endpoints. Our definition is aligned with MEF and 3GPP.

  *   MEF uses the same definition for Transport portion of the network slice”. See Section 5.3 of following white paper
     *   https://wiki.mef.net/display/CESG/Slicing+for+Shared+5G+Fronthaul+and+Backhaul+-+White+Paper

  *   This is aligned with 3GPP. See Figure 4.9.3.1 of TR 28.801 and  http://www.3gpp.org/NEWS-EVENTS/3GPP-NEWS/1951-SA5_5G

According to the picture below,  the reference of transport portion of a network slice  is referred by “Transport network supporting connectivity’

[[email-masked]]

Reason 3)
The next question is that which term shall be used for ‘Transport portion of an end-to-end network slice”?

  *   MEF uses the term “Transport Slice”. See Figure 17 of following white paper
     *   https://wiki.mef.net/display/CESG/Slicing+for+Shared+5G+Fronthaul+and+Backhaul+-+White+Paper

  *   3GPP: See Figure 4.9.3.1 of TR 28.801 and  http://www.3gpp.org/NEWS-EVENTS/3GPP-NEWS/1951-SA5_5G

They do not directly address the transport portion of a network slice. They do not have a term for this. They mainly address the 5G RAN and 5G Core. As shown in the picture above, the reference of transport is phrase “Transport network supporting connectivity”.

  *   From IETF point of view, these are potential choices for Transport portion of a network slice:

  *   Network slice: This for sure is NO. Reason 1) clearly shows that we shall not use term “Network slice” for transport portion. This is not correct.
  *   Use 3GPP phrase: “Transport network supporting connectivity”
  *   Use the phrase “Transport portion of the Network Slice”
  *   Use term “Transport Network Slice”
  *   Use term “Transport Slice”
  *   Adrian, Igor, Deborah and others, is there any other suggestion? If so, please add

From the above choices, the draft authors uses the term “Transport Slice” but not the “Transport Network Slice” to make sure we implicitly stating that Network Slice and Transport part are different.
Having said that, authors are open to suggestion. Please suggest your term.

Reza

---

From: John E Drake <[email-masked]>
Date: Fri, 4 Sep 2020 15:14:49 +0000

Hi,

'Network slice'.  As Adrian points out, this is the term that has been used in the IETF for quite some;  it is used in RFCs 8453, 8568, and 8578, as well as the preponderance of I-Ds on this topic.  Even if another term was correct, and I don't think that, trying to use a term other than 'network slice' will continue to cause tremendous confusion.  I.e., changing terms is akin to closing the barn door after the horse has bolted.

As I noted yesterday, and throughout the *Network Slicing* design team meetings, I think it is up to an application that uses IETF network slices as components to indicate where in its design these IETF network slices fit.  I.e., IETF network slices are being designed for use by a multiplicity of applications and trying to make our terminology congruent with this one application is problematic.

Yours Irrespectively,

John

Juniper Business Use Only
From: Teas <[email-masked]> On Behalf Of Rokui, Reza (Nokia - CA/Ottawa)
Sent: Friday, September 4, 2020 10:16 AM
To: Kiran Makhijani <[email-masked]>; [email-masked]; 'Eric Gray' <[email-masked]>; 'Igor Bryskin' <i_bryskin=[email-masked]>; 'TEAS WG Chairs' <[email-masked]>; [email-masked] <[email-masked]>; 'TEAS WG' <[email-masked]>; 'BRUNGARD, DEBORAH A' <[email-masked]>
Cc: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>
Subject: [Teas] Why term transport slice? WG adoption - draft-nsdt-teas-transport-slice-definition

[External Email. Be cautious of content]

All,

Let's step back and address these questions: How and why the authors' of the draft chose the term "Transport Slice"?

After creation of the NSDT, we collectively thoughts that the first order of business is to clarify this. So, the "draft definition" started. The following are the reasons:

Reason 1)

Reason 2)

  *   MEF uses the same definition for Transport portion of the network slice". See Section 5.3 of following white paper

     *   https://wiki.mef.net/display/CESG/Slicing+for+Shared+5G+Fronthaul+and+Backhaul+-+White+Paper<https://urldefense.com/v3/__https:/wiki.mef.net/display/CESG/Slicing*for*Shared*5G*Fronthaul*and*Backhaul*-*White*Paper__;KysrKysrKysr!!NEt6yMaO-gk!RwBHv_fQ5XdrftEX2118w7OUiQg2mu-eHcRobC4KGZ-EPaqW2EcKPWfQ_6Dp7hs$>

  *   This is aligned with 3GPP. See Figure 4.9.3.1 of TR 28.801 and  http://www.3gpp.org/NEWS-EVENTS/3GPP-NEWS/1951-SA5_5G<https://urldefense.com/v3/__http:/www.3gpp.org/NEWS-EVENTS/3GPP-NEWS/1951-SA5_5G__;!!NEt6yMaO-gk!RwBHv_fQ5XdrftEX2118w7OUiQg2mu-eHcRobC4KGZ-EPaqW2EcKPWfQECxLoTI$>

According to the picture below,  the reference of transport portion of a network slice  is referred by "Transport network supporting connectivity'

Reason 3)
The next question is that which term shall be used for 'Transport portion of an end-to-end network slice"?

  *   MEF uses the term "Transport Slice". See Figure 17 of following white paper

     *   https://wiki.mef.net/display/CESG/Slicing+for+Shared+5G+Fronthaul+and+Backhaul+-+White+Paper<https://urldefense.com/v3/__https:/wiki.mef.net/display/CESG/Slicing*for*Shared*5G*Fronthaul*and*Backhaul*-*White*Paper__;KysrKysrKysr!!NEt6yMaO-gk!RwBHv_fQ5XdrftEX2118w7OUiQg2mu-eHcRobC4KGZ-EPaqW2EcKPWfQ_6Dp7hs$>

  *   3GPP: See Figure 4.9.3.1 of TR 28.801 and  http://www.3gpp.org/NEWS-EVENTS/3GPP-NEWS/1951-SA5_5G<https://urldefense.com/v3/__http:/www.3gpp.org/NEWS-EVENTS/3GPP-NEWS/1951-SA5_5G__;!!NEt6yMaO-gk!RwBHv_fQ5XdrftEX2118w7OUiQg2mu-eHcRobC4KGZ-EPaqW2EcKPWfQECxLoTI$>

They do not directly address the transport portion of a network slice. They do not have a term for this. They mainly address the 5G RAN and 5G Core. As shown in the picture above, the reference of transport is phrase "Transport network supporting connectivity".

  *   Network slice: This for sure is NO. Reason 1) clearly shows that we shall not use term "Network slice" for transport portion. This is not correct.
  *   Use 3GPP phrase: "Transport network supporting connectivity"
  *   Use the phrase "Transport portion of the Network Slice"
  *   Use term "Transport Network Slice"
  *   Use term "Transport Slice"
  *   Adrian, Igor, Deborah and others, is there any other suggestion? If so, please add

>From the above choices, the draft authors uses the term "Transport Slice" but not the "Transport Network Slice" to make sure we implicitly stating that Network Slice and Transport part are different.

Reza

---

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Fri, 4 Sep 2020 15:46:51 +0000

Hi Reza,
(as AD)

Much thanks for your detailed explanation.

I think I’m beginning to see the confusion - my confusion was as Adrian noted - not with the document itself - it is a nicely written document - but what does this have to do with TEAS work? If point 1 with Figure 1 is your basis of justification for “transport”, with a segmented view of the network, while it may be correct from a technology view, it is not the basis of TEAS work. There are many RFCs, especially the ASON work (before TEAS - in CCAMP) will show a different view of the network. Adrian tried to summarize. Especially when proprietary domains are present.

TEAS is responsible for TE architectures with generic applicability - I’ve seen in this thread the desire by some of the authors to include non-TE. I understand the need - but that’s not TEAS. As Adrian noted - is TEAS the proper home?

Re-reading this definition document, I realize TE is not even mentioned except to say this work is different from a TE link and so needs to be defined differently. On this reading, I see the key element is the transport slice controller NBI.

Maybe this author team is not familiar with ccamp, ccamp is already defining a Transport (yes, “Transport”:-)) NBI? And Client- service models. A 3GPP transport NBI can either be done as an applicability or a PS document as part of their work. In ccamp, “transport” slice will not be confusing.

I think it was great for the DT to start sorting out the gap for 3GPP transport work. I’ll talk with the chairs to sort out the best home. While sorting out, please continue discussing and progressing the document. There’s lots of overlap among TEAS and CCAMP participants on the TEAS list.

Deborah

Sent from my iPhone

On Sep 4, 2020, at 10:16 AM, Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]> wrote:

All,

Reason 1)

Reason 2)

  *   MEF uses the same definition for Transport portion of the network slice”. See Section 5.3 of following white paper
     *   https://wiki.mef.net/display/CESG/Slicing+for+Shared+5G+Fronthaul+and+Backhaul+-+White+Paper<https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.mef.net_display_CESG_Slicing-2Bfor-2BShared-2B5G-2BFronthaul-2Band-2BBackhaul-2B-2D-2BWhite-2BPaper&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=W4iKXLRn0c02KfMb6XuMzOUPI3bVoc8fMH1OTJcjqgg&s=V0cMMN7woyDsVMTdz_QamIGXjKW8FEqDtZrkpFk8D5M&e=>

  *   This is aligned with 3GPP. See Figure 4.9.3.1 of TR 28.801 and  http://www.3gpp.org/NEWS-EVENTS/3GPP-NEWS/1951-SA5_5G<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.3gpp.org_NEWS-2DEVENTS_3GPP-2DNEWS_1951-2DSA5-5F5G&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=W4iKXLRn0c02KfMb6XuMzOUPI3bVoc8fMH1OTJcjqgg&s=tROrnxxHAgZdPFGiZ62rgSO_iw1Nb82TkIzKwWZkVUY&e=>

Reason 3)

  *   MEF uses the term “Transport Slice”. See Figure 17 of following white paper
     *   https://wiki.mef.net/display/CESG/Slicing+for+Shared+5G+Fronthaul+and+Backhaul+-+White+Paper<https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.mef.net_display_CESG_Slicing-2Bfor-2BShared-2B5G-2BFronthaul-2Band-2BBackhaul-2B-2D-2BWhite-2BPaper&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=W4iKXLRn0c02KfMb6XuMzOUPI3bVoc8fMH1OTJcjqgg&s=V0cMMN7woyDsVMTdz_QamIGXjKW8FEqDtZrkpFk8D5M&e=>

  *   3GPP: See Figure 4.9.3.1 of TR 28.801 and  http://www.3gpp.org/NEWS-EVENTS/3GPP-NEWS/1951-SA5_5G<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.3gpp.org_NEWS-2DEVENTS_3GPP-2DNEWS_1951-2DSA5-5F5G&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=W4iKXLRn0c02KfMb6XuMzOUPI3bVoc8fMH1OTJcjqgg&s=tROrnxxHAgZdPFGiZ62rgSO_iw1Nb82TkIzKwWZkVUY&e=>

Reza

---

From: "Rokui, Reza (Nokia - CA/Ottawa)" <[email-masked]>
Date: Fri, 4 Sep 2020 18:16:09 +0000

Hi Deborah,

>>>>>>> but what does this have to do with TEAS work? If point 1 with Figure 1 is your basis of justification for “transport”, with a segmented view of the network, while it may be correct from a technology view, it is not the basis of TEAS work

One important aspect that I forgot to add to my previous email will hopefully answer your valid question on how transport slice work relates to ACTN.
Each “Transport Slice” (or any other name adopted later) has two characteristics:

  *   Transport slice definition: which as described in my previous email is a set of connectivity among endpoints to satisfy specific SLA/SLO. This is network and technology-agnostics.
  *   Transport slice realization: Describe how the transport slice is implemented in the network. This is technology dependent.

For example suppose you have a transport slice defined as two connections between EP1, EP2 with SLO1. If your network is IP/MPLS with TE enabled, the operator can realize this transport slice using any IETF Service/Paths/Tunnels models (including ACTN).
However, if the operator’s network for this transport slice is a PON network, the realization will be complexly different. However, in both cases, the transport slice definition remains exactly the same but the realization changes.
The mapping between technology-agnostics and technology-specific is done between Transport Slice Controller (TSC) NBI and SBI (See picture below).

In summary to answer your question, a transport slice can be realized by different technologies. One of them can be ACTN as shown in following figure taken from transport slice framework draft (https://tools.ietf.org/html/draft-nsdt-teas-ns-framework-02). This topic was discussed at NSDT in length. Dhruv was involved in this discission.
In other words, the transport slice work done at NSDT will complement IETF ACTN work.

Reza

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Friday, September 4, 2020 at 11:46 AM
To: Reza Rokui <[email-masked]>
Cc: Kiran Makhijani <[email-masked]>, "[email-masked]" <[email-masked]>, Eric Gray <[email-masked]>, Igor Bryskin <i_bryskin=[email-masked]>, TEAS WG Chairs <[email-masked]>, Vishnu Pavan Beeram <[email-masked]>, TEAS WG <[email-masked]>
Subject: Re: Why term transport slice? [Teas] WG adoption - draft-nsdt-teas-transport-slice-definition

Hi Reza,
(as AD)

Deborah

Sent from my iPhone

Reason 1)

Reason 2)

Reason 3)

Reza

---

From: Young Lee <[email-masked]>
Date: Sat, 5 Sep 2020 13:35:17 +0900

Hi,

I agree with John. This is a good point. There are a mutiplicity of
"customers/consumers" that would like to consume the "services" IETF/TEAS
provides, and 3GPP is one of the customers that may be interested in
fulfiling its TN subnet requirements for eMBB or uRLLC network slice types.

But there are other customers that TEAS ACTN supports among which are L1VPN
for DCI, IP service providers that need a leased line between two end
points, etc, let alone L2/3 VPN customers that need TE networks, and
enhanced VPN.

TEAS ACTN effort has been to fulfill the common requirements coming from a
plethora of diverse customers.

What about non-TE? As Igor nicely put in another email thread, ACTN VN/ TE
Yang models can still be used as they provide all necessary basic
components (non-TE specific) such as end points, service policies, sharing
properties, etc. All components in YANG models can be made optional so all
TE components can be skipped if there is a need for that.

Regards,
Young

2020년 9월 5일 (토) 오전 12:15, John E Drake <jdrake=[email-masked]>님이
작성:

> Hi,
>
>
>
> ‘Network slice’.  As Adrian points out, this is the term that has been
> used in the IETF for quite some;  it is used in RFCs 8453, 8568, and 8578,
> as well as the preponderance of I-Ds on this topic.  Even if another term
> was correct, and I don’t think that, trying to use a term other than
> ‘network slice’ will continue to cause tremendous confusion.  I.e.,
> changing terms is akin to closing the barn door after the horse has bolted.
>
>
>
> As I noted yesterday, and throughout the **Network Slicing** design team
> meetings, I think it is up to an application that uses IETF network slices
> as components to indicate where in its design these IETF network slices
> fit.  I.e., IETF network slices are being designed for use by a
> multiplicity of applications and trying to make our terminology congruent
> with this one application is problematic.
>
>
>
> Yours Irrespectively,
>
>
>
> John
>
>
>
>
>
> *From:* Teas <[email-masked]> *On Behalf Of * Rokui, Reza (Nokia -
> CA/Ottawa)
> *Sent:* Friday, September 4, 2020 10:16 AM
> *To:* Kiran Makhijani <[email-masked]>; [email-masked]; 'Eric
> Gray' <[email-masked]>; 'Igor Bryskin' <i_bryskin=
> [email-masked]>; 'TEAS WG Chairs' <[email-masked]>;
> [email-masked] <[email-masked]>; 'TEAS WG' <
> [email-masked]>; 'BRUNGARD, DEBORAH A' <[email-masked]>
> *Cc:* Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>
> *Subject:* [Teas] Why term transport slice? WG adoption -
> draft-nsdt-teas-transport-slice-definition
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> All,
>
>
>
> Let’s step back and address these questions: *How and why the authors’ of
> the draft chose the term “Transport Slice”?*
>
>
>
> Before formation of the TEAS WG NSDT, there were lots of discussions and
> drafts to address the role of IETF for network slicing. Those discussion
> and drafts tried to address the network slicing  from different
> perspectives but in most cases they had one thing in common, they started
> by discussion the network slicing but at the end they really meant the
> Transports portion of the network slice. In other words, although the name
> of the draft and discussion was network slicing, but they just talked about
> Transport portion.  In other hand, the term network slice and Transport
> portion of a network slice were used interchangeably.
>
>
>
> After creation of the NSDT, we collectively thoughts that the first order
> of business is to clarify this. So, the “draft definition” started. The
> following are the reasons:
>
>
>
> Reason 1)
>
> The first reason for this draft is to make very clear distinction between
> a network slice (defined for example by 3GPP) and transport portion of a
> network slice.
>
> In our opinion it is essential to make a clear distinction between *network
> slice* and *transport portion of a network slice*. They are NOT the same
> since a network slice contain the transport portion.
>
> The picture below was outcome of that discussion. In summary, a network
> slice is an end-to-end context and depends on the used case (i.e 5G, DCI,
> etc), it might contain a few other components (i.e. RAN, Transport, Core
> etc.)
>
>
>
>
>
> Reason 2)
>
> We just established the fact that an end-to-end network slice is different
> from transport portion of the network slice. The next question is that what
> the definition of the Transport portion of a network slice is.
>
> This is fully discussed in draft but in summary the transport portion of a
> network slice describes the CONNECTIVITY between various endpoints. Our
> definition is aligned with MEF and 3GPP.
>
>    - MEF uses the same definition for Transport portion of the network
>    slice”. See Section 5.3 of following white paper
>
>
>    -
>       https://wiki.mef.net/display/CESG/Slicing+for+Shared+5G+Fronthaul+and+Backhaul+-+White+Paper
>       <https://urldefense.com/v3/__https:/wiki.mef.net/display/CESG/Slicing*for*Shared*5G*Fronthaul*and*Backhaul*-*White*Paper__;KysrKysrKysr!!NEt6yMaO-gk!RwBHv_fQ5XdrftEX2118w7OUiQg2mu-eHcRobC4KGZ-EPaqW2EcKPWfQ_6Dp7hs$>
>
>
>
>    - This is aligned with 3GPP. See Figure 4.9.3.1 of TR 28.801 and
>    http://www.3gpp.org/NEWS-EVENTS/3GPP-NEWS/1951-SA5_5G
>    <https://urldefense.com/v3/__http:/www.3gpp.org/NEWS-EVENTS/3GPP-NEWS/1951-SA5_5G__;!!NEt6yMaO-gk!RwBHv_fQ5XdrftEX2118w7OUiQg2mu-eHcRobC4KGZ-EPaqW2EcKPWfQECxLoTI$>
>
> According to the picture below,  the reference of transport portion of a
> network slice  is referred by “Transport network supporting connectivity’
>
>
>
>
>
>
> Reason 3)
>
>    - MEF uses the term “Transport Slice”. See Figure 17 of following
>    white paper
>
>
>    -
>       https://wiki.mef.net/display/CESG/Slicing+for+Shared+5G+Fronthaul+and+Backhaul+-+White+Paper
>       <https://urldefense.com/v3/__https:/wiki.mef.net/display/CESG/Slicing*for*Shared*5G*Fronthaul*and*Backhaul*-*White*Paper__;KysrKysrKysr!!NEt6yMaO-gk!RwBHv_fQ5XdrftEX2118w7OUiQg2mu-eHcRobC4KGZ-EPaqW2EcKPWfQ_6Dp7hs$>
>
>
>
>    - 3GPP: See Figure 4.9.3.1 of TR 28.801 and
>    http://www.3gpp.org/NEWS-EVENTS/3GPP-NEWS/1951-SA5_5G
>    <https://urldefense.com/v3/__http:/www.3gpp.org/NEWS-EVENTS/3GPP-NEWS/1951-SA5_5G__;!!NEt6yMaO-gk!RwBHv_fQ5XdrftEX2118w7OUiQg2mu-eHcRobC4KGZ-EPaqW2EcKPWfQECxLoTI$>
>
> They do not directly address the transport portion of a network slice.
> They do not have a term for this. They mainly address the 5G RAN and 5G
> Core. As shown in the picture above, the reference of transport is phrase
> “Transport network supporting connectivity”.
>
>
>
>    - >From IETF point of view, these are potential choices for Transport
>    portion of a network slice:
>
>
>    - Network slice: This for sure is NO. Reason 1) clearly shows that we
>    shall not use term “Network slice” for transport portion. This is not
>    correct.
>    - Use 3GPP phrase: “Transport network supporting connectivity”
>    - Use the phrase “Transport portion of the Network Slice”
>    - Use term “Transport Network Slice”
>    - Use term “Transport Slice”
>    - Adrian, Igor, Deborah and others, is there any other suggestion? If
>    so, please add
>
>
>
> From the above choices, the draft authors uses the term “Transport Slice”
> but not the “Transport Network Slice” to make sure we implicitly stating
> that Network Slice and Transport part are different.
>
> *Reza *
> _______________________________________________
> Teas mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teas
>

---

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Sat, 5 Sep 2020 16:59:57 +0000

Hi Young,

The starting point of the work has been to consider the (Transport) Slice Controller being technology agnostic. Using TE-related or whatever other mechanisms is part of the realization of the slice, so considered as an activity to be carried out later in the DT and or the WG when mapping the slice concept to different IETF related technologies (that could have host in TEAS or any other WG).

The customer/consumer perspective will probably don’t care about if the slice is provisioned through TE mechanisms. The customer is simply not aware of that because will not specify it (only SLOs and other characteristics that can be attributes of the desired slice).

It is true that multiple services could request slices. Note the work in progress in draft-contreras-teas-slice-nbi for this.

Respect to the point of the versatility of TE models to handle non-TE demands, I see it as a point in favor of not limiting the approach taken in the work done till now. I mean, precisely because of that versatility, the work done is valid and more comprehensive than just reducing the scope to TE, since TE is part of it.

Best regards

Luis

De: Teas <[email-masked]> En nombre de Young Lee
Enviado el: sábado, 5 de septiembre de 2020 6:35
Para: John E Drake <jdrake=[email-masked]>
CC: BRUNGARD, DEBORAH A <[email-masked]>; Kiran Makhijani <[email-masked]>; TEAS WG Chairs <[email-masked]>; TEAS WG <[email-masked]>; Eric Gray <[email-masked]>; Igor Bryskin <i_bryskin=[email-masked]>; [email-masked] <[email-masked]>; [email-masked]; Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>
Asunto: Re: [Teas] Why term transport slice? WG adoption - draft-nsdt-teas-transport-slice-definition

Hi,

I agree with John. This is a good point. There are a mutiplicity of "customers/consumers" that would like to consume the "services" IETF/TEAS provides, and 3GPP is one of the customers that may be interested in fulfiling its TN subnet requirements for eMBB or uRLLC network slice types.

But there are other customers that TEAS ACTN supports among which are L1VPN for DCI, IP service providers that need a leased line between two end points, etc, let alone L2/3 VPN customers that need TE networks, and enhanced VPN.

TEAS ACTN effort has been to fulfill the common requirements coming from a plethora of diverse customers.

What about non-TE? As Igor nicely put in another email thread, ACTN VN/ TE Yang models can still be used as they provide all necessary basic components (non-TE specific) such as end points, service policies, sharing properties, etc. All components in YANG models can be made optional so all TE components can be skipped if there is a need for that.

Regards,
Young

2020년 9월 5일 (토) 오전 12:15, John E Drake <jdrake=[email-masked]<mailto:[email-masked]>>님이 작성:
Hi,

‘Network slice’.  As Adrian points out, this is the term that has been used in the IETF for quite some;  it is used in RFCs 8453, 8568, and 8578, as well as the preponderance of I-Ds on this topic.  Even if another term was correct, and I don’t think that, trying to use a term other than ‘network slice’ will continue to cause tremendous confusion.  I.e., changing terms is akin to closing the barn door after the horse has bolted.

Yours Irrespectively,

John

Juniper Business Use Only
From: Teas <[email-masked]<mailto:[email-masked]>> On Behalf Of Rokui, Reza (Nokia - CA/Ottawa)
Sent: Friday, September 4, 2020 10:16 AM
To: Kiran Makhijani <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; 'Eric Gray' <[email-masked]<mailto:[email-masked]>>; 'Igor Bryskin' <i_bryskin=[email-masked]<mailto:[email-masked]>>; 'TEAS WG Chairs' <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; 'TEAS WG' <[email-masked]<mailto:[email-masked]>>; 'BRUNGARD, DEBORAH A' <[email-masked]<mailto:[email-masked]>>
Cc: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>>
Subject: [Teas] Why term transport slice? WG adoption - draft-nsdt-teas-transport-slice-definition

All,

Reason 1)

Reason 2)

Reason 3)

  *   >From IETF point of view, these are potential choices for Transport portion of a network slice:

Reza

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

________________________________

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 privileged and confidential 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: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Sun, 6 Sep 2020 09:51:43 +0000

Hi all,

I think is important this clarification from Reza with respect to considering both the transport slice definition and its realization. TE-based solutions (and whatever other) are part of the second, but all have as common root the definition.

Best regards

Luis

De: Teas <[email-masked]> En nombre de Rokui, Reza (Nokia - CA/Ottawa)
Enviado el: viernes, 4 de septiembre de 2020 20:16
Para: BRUNGARD, DEBORAH A <[email-masked]>; Kiran Makhijani <[email-masked]>; [email-masked]; Eric Gray <[email-masked]>; Igor Bryskin <i_bryskin=[email-masked]>; TEAS WG Chairs <[email-masked]>; Vishnu Pavan Beeram <[email-masked]>; TEAS WG <[email-masked]>; Dhruv Dhody <[email-masked]>
CC: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>
Asunto: Re: [Teas] Why term transport slice? WG adoption - draft-nsdt-teas-transport-slice-definition

Hi Deborah,

One important aspect that I forgot to add to my previous email will hopefully answer your valid question on how transport slice work relates to ACTN.
Each “Transport Slice” (or any other name adopted later) has two characteristics:
-          Transport slice definition: which as described in my previous email is a set of connectivity among endpoints to satisfy specific SLA/SLO. This is network and technology-agnostics.
-          Transport slice realization: Describe how the transport slice is implemented in the network. This is technology dependent.

Reza

From: "BRUNGARD, DEBORAH A" <[email-masked]<mailto:[email-masked]>>
Date: Friday, September 4, 2020 at 11:46 AM
To: Reza Rokui <[email-masked]<mailto:[email-masked]>>
Cc: Kiran Makhijani <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Eric Gray <[email-masked]<mailto:[email-masked]>>, Igor Bryskin <i_bryskin=[email-masked]<mailto:i_bryskin=[email-masked]>>, TEAS WG Chairs <[email-masked]<mailto:[email-masked]>>, Vishnu Pavan Beeram <[email-masked]<mailto:[email-masked]>>, TEAS WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: Why term transport slice? [Teas] WG adoption - draft-nsdt-teas-transport-slice-definition

Hi Reza,
(as AD)

Deborah

Sent from my iPhone

On Sep 4, 2020, at 10:16 AM, Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>> wrote:
All,

Reason 1)

Reason 2)
We just established the fact that an end-to-end network slice is different from transport portion of the network slice. The next question is that what the definition of the Transport portion of a network slice is.
This is fully discussed in draft but in summary the transport portion of a network slice describes the CONNECTIVITY between various endpoints. Our definition is aligned with MEF and 3GPP.
-          MEF uses the same definition for Transport portion of the network slice”. See Section 5.3 of following white paper
o   https://wiki.mef.net/display/CESG/Slicing+for+Shared+5G+Fronthaul+and+Backhaul+-+White+Paper<https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.mef.net_display_CESG_Slicing-2Bfor-2BShared-2B5G-2BFronthaul-2Band-2BBackhaul-2B-2D-2BWhite-2BPaper&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=W4iKXLRn0c02KfMb6XuMzOUPI3bVoc8fMH1OTJcjqgg&s=V0cMMN7woyDsVMTdz_QamIGXjKW8FEqDtZrkpFk8D5M&e=>

-          This is aligned with 3GPP. See Figure 4.9.3.1 of TR 28.801 and  http://www.3gpp.org/NEWS-EVENTS/3GPP-NEWS/1951-SA5_5G<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.3gpp.org_NEWS-2DEVENTS_3GPP-2DNEWS_1951-2DSA5-5F5G&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=W4iKXLRn0c02KfMb6XuMzOUPI3bVoc8fMH1OTJcjqgg&s=tROrnxxHAgZdPFGiZ62rgSO_iw1Nb82TkIzKwWZkVUY&e=>

Reason 3)

-          MEF uses the term “Transport Slice”. See Figure 17 of following white paper
o   https://wiki.mef.net/display/CESG/Slicing+for+Shared+5G+Fronthaul+and+Backhaul+-+White+Paper<https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.mef.net_display_CESG_Slicing-2Bfor-2BShared-2B5G-2BFronthaul-2Band-2BBackhaul-2B-2D-2BWhite-2BPaper&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=W4iKXLRn0c02KfMb6XuMzOUPI3bVoc8fMH1OTJcjqgg&s=V0cMMN7woyDsVMTdz_QamIGXjKW8FEqDtZrkpFk8D5M&e=>

-          3GPP: See Figure 4.9.3.1 of TR 28.801 and  http://www.3gpp.org/NEWS-EVENTS/3GPP-NEWS/1951-SA5_5G<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.3gpp.org_NEWS-2DEVENTS_3GPP-2DNEWS_1951-2DSA5-5F5G&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=W4iKXLRn0c02KfMb6XuMzOUPI3bVoc8fMH1OTJcjqgg&s=tROrnxxHAgZdPFGiZ62rgSO_iw1Nb82TkIzKwWZkVUY&e=>

-          From IETF point of view, these are potential choices for Transport portion of a network slice:
o   Network slice: This for sure is NO. Reason 1) clearly shows that we shall not use term “Network slice” for transport portion. This is not correct.
o   Use 3GPP phrase: “Transport network supporting connectivity”
o   Use the phrase “Transport portion of the Network Slice”
o   Use term “Transport Network Slice”
o   Use term “Transport Slice”
o   Adrian, Igor, Deborah and others, is there any other suggestion? If so, please add

Reza