Subject: [Teas] Network Slicing design team definitions- transport slice

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Tue, 1 Sep 2020 14:31:26 +0000

Hi,
(speaking as an individual)

Picking up on Jari's comment "sometimes people want to use labels that are a bit more imprecise, but I think we should strive to avoid such labels as much as we can", can you give more background on the choice of the term "transport slice"?

I noted while you have text on the use of "transport" by 3GPP as specifying a very specific sub-network in the radio network (which excludes the handoff to the rest of the network), you referenced RFC5921 (MPLS-TP) for the term "transport".

There was a long thread of mail on ACTN, RFC8453, to move away from the term "transport" to "TE networks" which was agreed to be more specific/appropriate for TEAS. Considering IETF is already using the term "network slicing" (including TEAS RFC8453) and 3GPP use of the term, I don't understand the use of "transport" in this document.

Considering IETF already uses the term "network slice" and 3GPP uses the term (and all the industry SDOs), I am concerned we will be confusing the industry, especially as "transport" is an imprecise term for TEAS work. Is this work a subset and scoped only to the 3GPP "transport" cloud (and implied use of MPLS-TP)? Or is it planned to be generic (for all TE networks)?

Deborah
(speaking as individual)

---

From: John E Drake <[email-masked]>
Date: Tue, 1 Sep 2020 14:41:58 +0000

Deborah,

I completely agree with you - we should be using the term 'network slice'.

Yours Irrespectively,

John

Juniper Business Use Only
From: Teas <[email-masked]> On Behalf Of BRUNGARD, DEBORAH A
Sent: Tuesday, September 1, 2020 10:31 AM
To: TEAS WG <[email-masked]>
Subject: [Teas] Network Slicing design team definitions- transport slice

[External Email. Be cautious of content]

Hi,

Deborah
(speaking as individual)

---

From: Young Lee <[email-masked]>
Date: Tue, 1 Sep 2020 23:56:49 +0900

Hi Deborah,

I also am wondering where ' transport slicing' came from. 3GPP uses network
slicing in the following three subnets: RAN, CN, and TN; and accordingly it
uses RAN slicng, CN slicing  and TN slicing.

There is always prefix "Network" is associated with slicing whether it is
RAN, CN, or TN.

As you pointed out, when RFC 8453 was developed in TEAS WG, we originally
used the term Transport Network Slicing, but later this term was replaced
with Traffic Engineered (TE) Network slicing.

Transport slicing is a bit orphanish. It should be either TE network
slicing or Transport network slicing. In TEAS WG, TE network slicing might
be more consistent with RFC 8453. Just for your reference, the following
terminology has been defined in RFC 8453:

TE Network Slicing:  In the context of ACTN, a TE network slice is a
      collection of resources that is used to establish a logically
      dedicated virtual network over one or more TE networks.  TE
      network slicing allows a network operator to provide dedicated
      virtual networks for applications/customers over a common network
      infrastructure.  The logically dedicated resources are a part of
      the larger common network infrastructures that are shared among
      various TE network slice instances, which are the end-to-end
      realization of TE network slicing, consisting of the combination
      of physically or logically dedicated resources.

Thanks.
Young

2020년 9월 1일 (화) 오후 11:31, BRUNGARD, DEBORAH A <[email-masked]>님이 작성:

> Picking up on Jari’s comment “sometimes people want to use labels that are
> a bit more imprecise, but I think we should strive to avoid such labels as
> much as we can”, can you give more background on the choice of the term
> “transport slice”?
>
>
>
> I noted while you have text on the use of “transport” by 3GPP as
> specifying a very specific sub-network in the radio network (which excludes
> the handoff to the rest of the network), you referenced RFC5921 (MPLS-TP)
> for the term “transport”.
>
>
>
> There was a long thread of mail on ACTN, RFC8453, to move away from the
> term “transport” to “TE networks” which was agreed to be more
> specific/appropriate for TEAS. Considering IETF is already using the term
> “network slicing” (including TEAS RFC8453) and 3GPP use of the term, I
> don’t understand the use of “transport” in this document.
>
>
>
> Considering IETF already uses the term “network slice” and 3GPP uses the
> term (and all the industry SDOs), I am concerned we will be confusing the
> industry, especially as “transport” is an imprecise term for TEAS work. Is
> this work a subset and scoped only to the 3GPP “transport” cloud (and
> implied use of MPLS-TP)? Or is it planned to be generic (for all TE
> networks)?
>
>
>
> Deborah
>
> (speaking as individual)
> _______________________________________________
> Teas mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teas
>

---

From: Kiran Makhijani <[email-masked]>
Date: Tue, 1 Sep 2020 15:35:03 +0000

Hi Deborah,
It was a deliberate effort to avoid using term network slice - which is a broader concept of "End-to-end network slice" and everything is not IETF specific. By use of term transport, we are able to  (quite precisely) scope our work in the context of IP/MPLS technologies - things IETF concern with. Another advantage is clarity from the network slice concept in 3GPP which has already been defined and described in a particular way. I will find it confusing if we had to always explain that 3gpp-network slices are different than ietf-network slices. Because they are going to be different in functionality.

Transport slices capture only the connectivity specific details for things we refer to as transport networks. So far it has aligned will with ACTN, enhance VPN and other TE related work. We will not know how to specify, mange or onboard a RAN, Wireless or a vertical-centric functionality, so there is no point in making assumptions about them in our design and terminology.

-Kiran

From: Teas <[email-masked]> On Behalf Of BRUNGARD, DEBORAH A
Sent: Tuesday, September 1, 2020 7:31 AM
To: TEAS WG <[email-masked]>
Subject: [Teas] Network Slicing design team definitions- transport slice

Hi,

Deborah
(speaking as individual)

---

From: John E Drake <[email-masked]>
Date: Tue, 1 Sep 2020 15:59:01 +0000

Hi,

Comments inline.

Yours Irrespectively,

John

Juniper Business Use Only
From: Teas <[email-masked]> On Behalf Of Kiran Makhijani
Sent: Tuesday, September 1, 2020 11:35 AM
To: BRUNGARD, DEBORAH A <[email-masked]>; TEAS WG <[email-masked]>
Subject: Re: [Teas] Network Slicing design team definitions- transport slice

Hi Deborah,
It was a deliberate effort to avoid using term network slice - which is a broader concept of "End-to-end network slice" and everything is not IETF specific. By use of term transport, we are able to  (quite precisely) scope our work in the context of IP/MPLS technologies - things IETF concern with.

[JD]   Since, as has been amply demonstrated on this mailing list for an extended period, there is massive confusion about the term 'transport slice' and since all of the other work in the IETF on this topic uses the term 'network slice', I find this a rather dubious assertion.

Another advantage is clarity from the network slice concept in 3GPP which has already been defined and described in a particular way. I will find it confusing if we had to always explain that 3gpp-network slices are different than ietf-network slices. Because they are going to be different in functionality.

[JD]  Really?  That's not the impression I got from Deborah, who seems quite familiar with industry-wide activity on this topic.

Transport slices capture only the connectivity specific details for things we refer to as transport networks. So far it has aligned will with ACTN, enhance VPN and other TE related work.

[JD]  All of which use a different and reasonably well-aligned terminology.

We will not know how to specify, mange or onboard a RAN, Wireless or a vertical-centric functionality, so there is no point in making assumptions about them in our design and terminology.

-Kiran

From: Teas <[email-masked]<mailto:[email-masked]>> On Behalf Of BRUNGARD, DEBORAH A
Sent: Tuesday, September 1, 2020 7:31 AM
To: TEAS WG <[email-masked]<mailto:[email-masked]>>
Subject: [Teas] Network Slicing design team definitions- transport slice

Hi,

Deborah
(speaking as individual)

---

From: "Rokui, Reza (Nokia - CA/Ottawa)" <[email-masked]>
Date: Tue, 1 Sep 2020 18:17:04 +0000

All,

Please note that 3GPP does not use the term “RAN Slice” or “Core slice”. Instead they use term “Slice Subnet”.
Please refer to the following 3GPP documents for example for more info:

  *   TS 28.531
  *   TR 28.801

Also see the following (taken from http://www.3gpp.org/NEWS-EVENTS/3GPP-NEWS/1951-SA5_5G).
The term NSI is for Network Slice instance and term NSSI is for Network Slice Subnet instance. As the picture shows, 3GPP does not differentiate between RAN and Core, all are called NSSI
The draft’s co-authors did not use the term “subnet” because at IETF this term (i.e. IP Subnet) has very clear meaning and using it in context of network slicing is confusing.

Also since the work at IETF is not just for 5G, we use the term “Transport slice”. If the use case is 5G, we also used RAN and Core Slices instead of NSSI to remove any confusion.

From: Teas <[email-masked]> on behalf of Young Lee <[email-masked]>
Date: Tuesday, September 1, 2020 at 10:56 AM
To: "BRUNGARD, DEBORAH A" <[email-masked]>
Cc: TEAS WG <[email-masked]>
Subject: Re: [Teas] Network Slicing design team definitions- transport slice

Hi Deborah,

I also am wondering where ' transport slicing' came from. 3GPP uses network slicing in the following three subnets: RAN, CN, and TN; and accordingly it uses RAN slicng, CN slicing  and TN slicing.

There is always prefix "Network" is associated with slicing whether it is RAN, CN, or TN.

As you pointed out, when RFC 8453 was developed in TEAS WG, we originally used the term Transport Network Slicing, but later this term was replaced with Traffic Engineered (TE) Network slicing.

Transport slicing is a bit orphanish. It should be either TE network slicing or Transport network slicing. In TEAS WG, TE network slicing might be more consistent with RFC 8453. Just for your reference, the following terminology has been defined in RFC 8453:

Thanks.
Young

2020년 9월 1일 (화) 오후 11:31, BRUNGARD, DEBORAH A <[email-masked]<mailto:[email-masked]>>님이 작성:
Hi,
(speaking as an individual)

Picking up on Jari’s comment “sometimes people want to use labels that are a bit more imprecise, but I think we should strive to avoid such labels as much as we can”, can you give more background on the choice of the term “transport slice”?

I noted while you have text on the use of “transport” by 3GPP as specifying a very specific sub-network in the radio network (which excludes the handoff to the rest of the network), you referenced RFC5921 (MPLS-TP) for the term “transport”.

There was a long thread of mail on ACTN, RFC8453, to move away from the term “transport” to “TE networks” which was agreed to be more specific/appropriate for TEAS. Considering IETF is already using the term “network slicing” (including TEAS RFC8453) and 3GPP use of the term, I don’t understand the use of “transport” in this document.

Considering IETF already uses the term “network slice” and 3GPP uses the term (and all the industry SDOs), I am concerned we will be confusing the industry, especially as “transport” is an imprecise term for TEAS work. Is this work a subset and scoped only to the 3GPP “transport” cloud (and implied use of MPLS-TP)? Or is it planned to be generic (for all TE networks)?

Deborah
(speaking as individual)
_______________________________________________
Teas mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/teas

---

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Tue, 1 Sep 2020 19:20:35 +0000

Hi,
(individual)

I’m still very confused by introducing the new term “transport” for IETF work on TE. As Young noted, it will be confused with the archaic term transport for many and it’s a misuse of 3GPP terms if it is not limited to 3GPP’s transport. Please look at the discussion thread on ACTN.

Ccamp and RAW cover wireless technologies so TEAS work is not limited to 3GPP “transport”. This work should be generic - a base - for other IETF work.

Before defining yet another term, why is the term Network Slice or TE network slice not acceptable? TE network slice will distinguish this work is for TE domains (TEAS charter work), network slice will align with IETF’s terms used in other groups. I don’t think TE transport slice is acceptable either - when we already have existing terminology that is concise.

I think you are confusing with the technology - especially if you are introducing new terms for all parts of the network - RAN slices, Core slices, Transport slice - TEAS work has never been constrained by the technology domain. “Network” is the network, no matter the division. There’s no need for all these terms.

Deborah
(Individual)

Sent from my iPhone

On Sep 1, 2020, at 2:17 PM, Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]> wrote:

All,

  *   TS 28.531
  *   TR 28.801

Also see the following (taken from 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=9ijmMtGVBggFatq3IfGWDVh1iMG4UJB0uI4dafgi_Aw&s=1SLoaA3fRyNItAXx5nrYuHbWzRXhSUL_n5JpSvcB3sI&e=>).
The term NSI is for Network Slice instance and term NSSI is for Network Slice Subnet instance. As the picture shows, 3GPP does not differentiate between RAN and Core, all are called NSSI
The draft’s co-authors did not use the term “subnet” because at IETF this term (i.e. IP Subnet) has very clear meaning and using it in context of network slicing is confusing.

Hi Deborah,

Thanks.
Young

Deborah
(speaking as individual)
_______________________________________________
Teas mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/teas<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_teas&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=9ijmMtGVBggFatq3IfGWDVh1iMG4UJB0uI4dafgi_Aw&s=LvYkDPlAn-K0sjB9D2KX_ocsYQqekQuDux4QILJryE0&e=>

---

From: Daniele Ceccarelli <[email-masked]>
Date: Wed, 2 Sep 2020 08:39:22 +0000

Hi Deborah,

I’m not 100% happy with the term either but I think a new one is needed.
Network Slice or TE network slice are IMO not good enough to state the RAN and Core are NOT included. Using 3GPP terms both Network Slice or TE network slice makes me think of the NSI, while what we need to define here is the NSSI for the transport part only.

If we call it Network slice we risk to be forced to speak of an IETF Network Slice which will be different from a 3GPP Network Slice…not nice.

Transport slice could potentially have issues with Layer 4 slice. I know very little of Layer 4 to understand if a L4 slice exists or will ever exist, but it’s something we can check.

Daniele

From: Teas <[email-masked]> On Behalf Of BRUNGARD, DEBORAH A
Sent: den 1 september 2020 21:21
To: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>
Cc: TEAS WG <[email-masked]>
Subject: Re: [Teas] Network Slicing design team definitions- transport slice

Hi,
(individual)

Deborah
(Individual)
Sent from my iPhone

On Sep 1, 2020, at 2:17 PM, Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>> wrote:

All,

  *   TS 28.531
  *   TR 28.801

From: Teas <[email-masked]<mailto:[email-masked]>> on behalf of Young Lee <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, September 1, 2020 at 10:56 AM
To: "BRUNGARD, DEBORAH A" <[email-masked]<mailto:[email-masked]>>
Cc: TEAS WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Teas] Network Slicing design team definitions- transport slice

Hi Deborah,

Thanks.
Young

Deborah
(speaking as individual)

---

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Wed, 2 Sep 2020 09:20:10 +0000

Hi all,

I fully share Daniele’s view on this. “Transport slice” (or even “Transport network slice”, as was also considered during DT discussions) provides a valid understanding of what is the subject, not only for 3GPP services but for any other service that could need of slices in the transport network (i.e., using IP, MPLS, MW, optics, etc).

Best regards

Luis

De: Teas <[email-masked]> En nombre de Daniele Ceccarelli
Enviado el: miércoles, 2 de septiembre de 2020 10:39
Para: BRUNGARD, DEBORAH A <[email-masked]>; Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>
CC: TEAS WG <[email-masked]>
Asunto: Re: [Teas] Network Slicing design team definitions- transport slice

Hi Deborah,

Daniele

To: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>>

Hi,
(individual)

Deborah
(Individual)
Sent from my iPhone

All,

  *   TS 28.531
  *   TR 28.801

Hi Deborah,

Thanks.
Young

Deborah
(speaking as individual)

________________________________

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: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Wed, 2 Sep 2020 13:29:46 +0000

Hi all,
(as individual)

I don’t see differentiating this work from the rest of the industry use of network slice as a valid justification and only will prevent IETF’s work from being visible. We will be so hung up in explaining our term vs. solution.

This work in TEAS needs to be generic for providing an integrated solution E2E for a network. You may not be aware, TEAS needs to provide the platform for detnet (TSN integration with network) and raw (satellite and radio). No one in IETF uses “transport”.

I understand the DT wanted to scope the work for defining but the choice of a name is not just for a DT or wg but to allow for industry visibility. As this is now time for adopting, just as for ACTN, we need to align with other work.

Sent from my iPhone

On Sep 2, 2020, at 5:20 AM, LUIS MIGUEL CONTRERAS MURILLO <[email-masked]> wrote:

Hi all,

Best regards

Luis

Hi Deborah,

Daniele

Hi,
(individual)

Deborah
(Individual)
Sent from my iPhone

All,

  *   TS 28.531
  *   TR 28.801

Hi Deborah,

Thanks.
Young

Deborah
(speaking as individual)

---

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Wed, 2 Sep 2020 13:46:00 +0000

Hi Daniele,
(as individual)

Why are you excluding RAN? RAW is already doing IP solutions, SG15 has RAN transport solutions for IP. IP is already in the RAN.

This is exactly why we can not use the term transport.

This reminds me of the early days of GMPLS when we defined a network solution and other Forum were segmenting the network with different interface names preventing an integrated network.

Already, network slice is the term used by all the SDOs for their solution. They have no problem with the term. It’s the definition for their technology that differentiates, not the term itself.

Deborah
(individual)

Sent from my iPhone

On Sep 2, 2020, at 4:39 AM, Daniele Ceccarelli <[email-masked]> wrote:

Hi Deborah,

Daniele

Hi,
(individual)

Deborah
(Individual)
Sent from my iPhone

All,

  *   TS 28.531
  *   TR 28.801

Hi Deborah,

Thanks.
Young

Deborah
(speaking as individual)