Subject: [Teas] Various terms for transport portion of a network slicing

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

Hi Lou, Pavan, Deborah and all,

As per TEAS WG chairs request during the last week’s meeting on network slicing, the co-authors of the definition draft had a few meeting and compiled all the potential terms with their pros and cons in the following table.
We feel that we captured all the terms suggested by TEAS and NSDT members in mailing lists and during the various meetings. Please let us know if any terms is missing.

In summary, the co-authors of the draft believe the term “IETF Network Slice” is a golden middle where IETF provides the exact context of any Network slice.

Cheers,
Reza (on behalf of all co-authors)

Various options for transport connectivity term from IETF point of view (without any specific order)

Term
Suggested by
Pros
Cons
1
IETF Network Slice
TEAS chairs
o It clearly elaborates the scope of technologies addressed with in the IETF leveraging the industry-wide term 'network slice.
o It is golden middle, where “IETF” provides the exact context to “Network Slice”
o Acceptable to TEAS WG chairs
o Acceptable to draft co-authors
labeling a piece of work with SDO name is not a good idea and IETF has always worked towards wider use, generic solutions, so the name may be restrictive.
2
Transport Slice
Draft Authors and NSDT
o ‘Transport network’ is an abstraction of connectivity between the (network) end-points which is technology agnostic.  Well covered by RFC5921.

o Aligned with other SDO (i.e. MEF)
See Figure 17 of following white paper
https://wiki.mef.net/display/CESG/Slicing+for+Shared+5G+Fronthaul+and+Backhaul+-+White+Paper
As per recent WG adoption poll, it is not accepted
3
Transport network slice
Draft Authors and some IETF members
‘Transport network’ is an abstraction of connectivity between the (network)end-points which is technology agnostic.  Well covered by RFC5921.
As per recent WG adoption poll, it is not accepted
4
Connectivity Slice
Draft Authors
o Since the transport slice is a set of distinct connections, term "Connectivity Slice" is selected

o Aligned with other SDO (i.e. 3GPP)
See Figure 4.9.3.1 of TR 28.801 and  http://www.3gpp.org/NEWS-EVENTS/3GPP-NEWS/1951-SA5_5G
As per TEAS WG chair, connectivity has different meaning at IETF
5
Connectivity Network Slice
Luis
The term Network becomes now narrow downed to the reference to connectivity, which is subject of IETF
As per TEAS WG chair, connectivity has different meaning at IETF
6
Connection Slice
Luis
o The term associates the concept of slice to the connection enabling the data transmission among end-points participating of a communication
o Note – here we could then follow a similar approach to how the VPNs are classified as L2 or L3; I mean L3/L2/(L1?) Connection Slice; if we classify the Connection Slices in that manner, such classification of the Connection Slice types will also help to describe recursiveness or hierarchical (multi-layer) slicing
o A connection can be established at different levels, including protocols above Layer 3
o Connection slice can make the people understand that there is a single connection represent a slice (i.e., 1:1) while actually could not be the case (i.e., 1 slice being formed by N connections)
7
Slice Network
Stewart
Stewart is coming with some background that a slice is combination of storage, compute and communications (or network). Slice network means an existing network is sliced to serve a particular user-case.
According to Lou, it has entirely different meaning.
8
Virtual Slice Network (VSN)
Luis
o Variant on top of Stewart’s suggestion to link with the evolution of the concept of legacy VPNs
o The term reminds the idea of logical network per customer focusing on connectivity
o As before, it could be possible to follow a similar approach to how the VPNs are classified as L2 or L3; I mean L3/L2/(L1?) VSN; also here, such classification of the VSNs can also help to describe recursiveness or hierarchical (multi-layer) slicing in transport
o There is no specific reference to transport or connectivity, apart of the generic idea of network (which we now is also an overloaded term)
o Differently from a VPN, which basically is a single instance including a number of locations, a VSN could refer to a set of individual VSNs (e.g., one per network segment). So can be probably confusing. Thus probably it would be needed to add additional terms such as sub-VSN, or VSN-segment, VSN-part, VSN-sub-slice, or alike
9
TE Network slice
Some TEAS members
Aligns with same  rationale used for naming ACTN.
Since not all transport networks are TE enabled, the realization of connectivity might be in a non-TE network. So, this term seems not appropriate
10
Carrier network slice
Webex/Stewart
In a generic use of term 'carrier' a carrier slice network carries use-case specific network traffic.
it may be confusing because it is associated with the infrastructure of telecommunication service providers, i.e., FNO/MNO. Recently, some network operators  deploy COTS servers in their infrastructure for MEC usages, and some readers may expect control of compute and storage  resources is in scope
11
Network slice
Some IETF members
An adoption of industry-wide term. While each SDO may look at it differently based on its own set of capabilities, for an end user it is a network slice in a specific technology domain.
o Since multiple connections are part of a single "Network Slice", it is not a good idea to call each of these connections "Network slice".
o There is a lack of 'harmonized' definition of network slice. For end customers, message may be confusing on which SDO they should ask for what part. It may lead to duplication of orchestration or APIs, depending upon who is controlling end to end network slice  - is it 3GPP operator, MVNO, ISP, service-integrator, OTT etc...
12
Data transmission network slice (DTNS)
Shunsuke
Since the transport slice is a set of distinct connections, providing the data transmission, this term might be suitable.

13
Transmission Network  Slice
Reza
Since the transport slice provides the data transmission across transport network, this term might be suitable.

14
Transmission Slice
Reza
Same as "Transmission Network Slice"

---

From: Eric Gray <[email-masked]>
Date: Tue, 29 Sep 2020 15:10:05 -0400

Reza,

	Not exactly sure what your mail is concluding.

	Is a “golden middle” the same as an acceptable compromise?  If so, it sounds like we’re saying that we find this term acceptable.

	That would be a good thing.

—
Eric

> On Sep 29, 2020, at 2:41 PM, Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]> wrote:
> 
> https://wiki.mef.net/display/CESG/Slicing+for+Shared+5G+Fronthaul+and+Backhaul+-+White+Paper <https://wiki.mef.net/display/CESG/Slicing+for+Shared+5G+Fronthaul+and+Backhaul+-+White+Paper>	
> See Figure 4.9.3.1 of TR 28.801 and  http://www.3gpp.org/NEWS-EVENTS/3GPP-NEWS/1951-SA5_5G <http://www.3gpp.org/NEWS-EVENTS/3GPP-NEWS/1951-SA5_5G>	
> _______________________________________________
> Teas mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/teas <https://www.ietf.org/mailman/listinfo/teas>

---

From: "Rokui, Reza (Nokia - CA/Ottawa)" <[email-masked]>
Date: Tue, 29 Sep 2020 19:27:50 +0000

Eric and all,

Yes. The term “IETF Network Slice” is acceptable to co-authors.

Reza

From: Eric Gray <[email-masked]>
Date: Tuesday, September 29, 2020 at 3:10 PM
To: Reza Rokui <[email-masked]>
Cc: Lou Berger <[email-masked]>, TEAS WG <[email-masked]>, Vishnu Pavan Beeram <[email-masked]>, "BRUNGARD, DEBORAH A" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Teas] Various terms for transport portion of a network slicing

Reza,

—
Eric

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

Cheers,

Term
Suggested by
Pros
Cons
1
IETF Network Slice
TEAS chairs

13

14
Transmission Slice
Reza

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

---

From: Eric Gray <[email-masked]>
Date: Tue, 29 Sep 2020 15:41:34 -0400

Reza,

	Great!!

	So this makes the TSC become an “IETF Network Slice controller” - or “IETF NSC” and we should be able to just call that a network slice controller (for brevity) in our documents, once we have stated the intention to do so.

	In terms of applicability, a 3GPP “transport network slice” consumer would be an “IETF network slice” consumer, unambiguously, when using a service model or NBI defined for that purpose by the IETF.

	It remains unclear if there would need to be a different matching of names for other applications of an IETF network slice, but that would be an issue to be resolved by whoever wishes to describe applicability of IETF network slices for that (or those) other application(s).  

	Are there other trickle down name changes to be made?

—
Eric

> On Sep 29, 2020, at 3:27 PM, Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]> wrote:
> 
> Eric and all,
>  
> From: Eric Gray <[email-masked] <mailto:[email-masked]>>
> To: Reza Rokui <[email-masked] <mailto:[email-masked]>>
> Cc: Lou Berger <[email-masked] <mailto:[email-masked]>>, TEAS WG <[email-masked] <mailto:[email-masked]>>, Vishnu Pavan Beeram <[email-masked] <mailto:[email-masked]>>, "BRUNGARD, DEBORAH A" <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
>> On Sep 29, 2020, at 2:41 PM, Rokui, Reza (Nokia - CA/Ottawa) <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Kiran Makhijani <[email-masked]>
Date: Tue, 29 Sep 2020 19:51:44 +0000

Hi Eric,

In terms of applicability, a 3GPP “transport network slice” consumer would be an “IETF network slice” consumer, unambiguously, when using a service model or NBI defined for that purpose by the IETF.
^^^^
I wonder if this separation is necessary. Don’t consumers sit at a higher level, may ask for RAN-, IETF- or any other network slices? Similarly, IETF-consumer may ask for other slices as well…
-Kiran

From: Teas-ns-dt <[email-masked]> On Behalf Of Eric Gray
Sent: Tuesday, September 29, 2020 12:42 PM
To: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>
Cc: Lou Berger <[email-masked]>; BRUNGARD, DEBORAH A <[email-masked]>; Vishnu Pavan Beeram <[email-masked]>; TEAS WG <[email-masked]>; [email-masked]
Subject: Re: [Teas-ns-dt] [Teas] Various terms for transport portion of a network slicing

Reza,

             Great!!

—
Eric

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

Eric and all,

Reza

From: Eric Gray <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, September 29, 2020 at 3:10 PM
To: Reza Rokui <[email-masked]<mailto:[email-masked]>>
Cc: Lou Berger <[email-masked]<mailto:[email-masked]>>, TEAS WG <[email-masked]<mailto:[email-masked]>>, Vishnu Pavan Beeram <[email-masked]<mailto:[email-masked]>>, "BRUNGARD, DEBORAH A" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Teas] Various terms for transport portion of a network slicing

Reza,

—
Eric

Cheers,

Term
Suggested by
Pros
Cons
1
IETF Network Slice
TEAS chairs

https://wiki.mef.net/display/CESG/Slicing+for+Shared+5G+Fronthaul+and+Backhaul+-+White+Paper<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.mef.net%2Fdisplay%2FCESG%2FSlicing%2Bfor%2BShared%2B5G%2BFronthaul%2Band%2BBackhaul%2B-%2BWhite%2BPaper&data=02%7C01%7Ckiranm%40futurewei.com%7Cab4fd61ace6b46c2d09d08d864afb631%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637370053140079501&sdata=nvBM5segjpgg29iiPjjOgqe6lvRwjHEgycYfwxoKgoo%3D&reserved=0>

See Figure 4.9.3.1 of TR 28.801 and  http://www.3gpp.org/NEWS-EVENTS/3GPP-NEWS/1951-SA5_5G<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.3gpp.org%2FNEWS-EVENTS%2F3GPP-NEWS%2F1951-SA5_5G&data=02%7C01%7Ckiranm%40futurewei.com%7Cab4fd61ace6b46c2d09d08d864afb631%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637370053140089498&sdata=qVnezK0RhH%2BlAQlWrT3Or2%2BEzz8yZU9IuzQ7MkZtC3M%3D&reserved=0>

13

14
Transmission Slice
Reza

_______________________________________________
Teas mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/teas<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteas&data=02%7C01%7Ckiranm%40futurewei.com%7Cab4fd61ace6b46c2d09d08d864afb631%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637370053140089498&sdata=XUvdS67hdORI1INkcIolgIExH8%2FeEdm%2BJ5u0xXmy3Y8%3D&reserved=0>

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 29 Sep 2020 22:21:29 +0100

I think this is good progress, Reza. Thanks for working on it and reporting it.

I could live with “IETF Network Slice”.

In your table for the entry on “Network Slice” you say:

> Since multiple connections are part of a single "Network Slice", it is not a good 

> idea to call each of these connections "Network slice".

I find this text to be very important because I think it underpins very much of the confusion in the discussions. For my part, I don’t want to apply a name to any single “connection” but want a term that describes the partitioning of underlay network resources for use by one or more overlay connections.

Cheers,

Adrian

From: Teas <[email-masked]> On Behalf Of Rokui, Reza (Nokia - CA/Ottawa)
Sent: 29 September 2020 19:42
To: Lou Berger <[email-masked]>; TEAS WG <[email-masked]>; Vishnu Pavan Beeram <[email-masked]>; BRUNGARD, DEBORAH A <[email-masked]>; [email-masked]
Cc: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>
Subject: [Teas] Various terms for transport portion of a network slicing

Cheers,

 

Term

Suggested by 

Pros

Cons

1

IETF Network Slice

TEAS chairs

2

Transport Slice

Draft Authors and NSDT

3

Transport network slice

4

Connectivity Slice

Draft Authors

5

Luis

6

Connection Slice

Luis

7

Slice Network

Stewart 

8

Luis

9

TE Network slice 

Some TEAS members

10

Carrier network slice

Webex/Stewart

11

Network slice

Some IETF members

12

Shunsuke 

13

Reza

14

Transmission Slice

Reza

---

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Tue, 29 Sep 2020 21:40:33 +0000

+1
Thanks Reza and team- appreciate the discussion descriptions-
Deborah
(AD hat off)

From: Adrian Farrel <[email-masked]>
Sent: Tuesday, September 29, 2020 5:21 PM
To: 'Rokui, Reza (Nokia - CA/Ottawa)' <[email-masked]>; 'Lou Berger' <[email-masked]>; 'TEAS WG' <[email-masked]>; 'Vishnu Pavan Beeram' <[email-masked]>; BRUNGARD, DEBORAH A <[email-masked]>; [email-masked]
Subject: RE: [Teas] Various terms for transport portion of a network slicing

Cheers,
Adrian

From: Teas <[email-masked]<mailto:[email-masked]>> On Behalf Of Rokui, Reza (Nokia - CA/Ottawa)
Sent: 29 September 2020 19:42
To: Lou Berger <[email-masked]<mailto:[email-masked]>>; TEAS WG <[email-masked]<mailto:[email-masked]>>; Vishnu Pavan Beeram <[email-masked]<mailto:[email-masked]>>; BRUNGARD, DEBORAH A <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>>
Subject: [Teas] Various terms for transport portion of a network slicing

Cheers,

Term

Suggested by

Pros

Cons

1

IETF Network Slice

TEAS chairs

2

Transport Slice

Draft Authors and NSDT

o Aligned with other SDO (i.e. MEF)
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!!BhdT!xkWVyawY8_H74n6iJo601PuCKa5OVNPiN_CUfnp-n_H6_xhi1VA841tL6nFMeE8$>

3

Transport network slice

4

Connectivity Slice

Draft Authors

o Aligned with other SDO (i.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.com/v3/__http:/www.3gpp.org/NEWS-EVENTS/3GPP-NEWS/1951-SA5_5G__;!!BhdT!xkWVyawY8_H74n6iJo601PuCKa5OVNPiN_CUfnp-n_H6_xhi1VA841tLYxsLl0s$>

5

Luis

6

Connection Slice

Luis

7

Slice Network

Stewart

8

Luis

9

TE Network slice

Some TEAS members

10

Carrier network slice

Webex/Stewart

11

Network slice

Some IETF members

12

Shunsuke

13

Reza

14

Transmission Slice

Reza

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Wed, 30 Sep 2020 01:56:59 +0000

Hi Reza and folks,

Thanks for the discussion and comparison. I can live with “IETF network slice” as well.

My feeling with “connectivity (network) slice” is that connectivity is just one basic attribute of a network slice we discussed in IETF, which may not fully reflect the characteristics of network slice.

And as Adrian mentioned,  in the description of the Cons of term “network slice” in the table,  It indicates that making connection and network slice interchangeable would be confusing.

Best regards,
Jie

From: Teas-ns-dt [mailto:[email-masked]] On Behalf Of Rokui, Reza (Nokia - CA/Ottawa)
Sent: Wednesday, September 30, 2020 2:42 AM
To: Lou Berger <[email-masked]>; TEAS WG <[email-masked]>; Vishnu Pavan Beeram <[email-masked]>; BRUNGARD, DEBORAH A <[email-masked]>; [email-masked]
Cc: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>
Subject: [Teas-ns-dt] Various terms for transport portion of a network slicing

Cheers,

Term

Suggested by

Pros

Cons

1

IETF Network Slice

TEAS chairs

2

Transport Slice

Draft Authors and NSDT

3

Transport network slice

4

Connectivity Slice

Draft Authors

5

Luis

6

Connection Slice

Luis

7

Slice Network

Stewart

8

Luis

9

TE Network slice

Some TEAS members

10

Carrier network slice

Webex/Stewart

11

Network slice

Some IETF members

12

Shunsuke

13

Reza

14

Transmission Slice

Reza

---

From: Eric Gray <[email-masked]>
Date: Wed, 30 Sep 2020 09:33:02 -0400

Hi Kiran.

I am not sure what your “caret arrows” were meant to point to, but - assuming you refer to entire sentence - I am also not sure what “separation” you are referring to.

As has been discussed at length, for the 3GPP use-case/application, the 3GPP view is that what they are asking for is essentially a “transport network slice” and IETF applicability is useful in providing clarification of how applications would use what the IETF has defined.

It may be the case that people in this discussion feel this is obvious, but it is nevertheless usually a good idea to write this sort of thing down for the benefit of people who did not have the privilege of participating in this discussion…

—
Eric

> On Sep 29, 2020, at 3:51 PM, Kiran Makhijani <[email-masked]> wrote:
> 
> Hi Eric, 
>  
> On Sep 29, 2020, at 3:27 PM, Rokui, Reza (Nokia - CA/Ottawa) <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Eric and all,
>  
> https://wiki.mef.net/display/CESG/Slicing+for+Shared+5G+Fronthaul+and+Backhaul+-+White+Paper <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.mef.net%2Fdisplay%2FCESG%2FSlicing%2Bfor%2BShared%2B5G%2BFronthaul%2Band%2BBackhaul%2B-%2BWhite%2BPaper&data=02%7C01%7Ckiranm%40futurewei.com%7Cab4fd61ace6b46c2d09d08d864afb631%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637370053140079501&sdata=nvBM5segjpgg29iiPjjOgqe6lvRwjHEgycYfwxoKgoo%3D&reserved=0>	
> See Figure 4.9.3.1 of TR 28.801 and  http://www.3gpp.org/NEWS-EVENTS/3GPP-NEWS/1951-SA5_5G <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.3gpp.org%2FNEWS-EVENTS%2F3GPP-NEWS%2F1951-SA5_5G&data=02%7C01%7Ckiranm%40futurewei.com%7Cab4fd61ace6b46c2d09d08d864afb631%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637370053140089498&sdata=qVnezK0RhH%2BlAQlWrT3Or2%2BEzz8yZU9IuzQ7MkZtC3M%3D&reserved=0>	
> https://www.ietf.org/mailman/listinfo/teas <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteas&data=02%7C01%7Ckiranm%40futurewei.com%7Cab4fd61ace6b46c2d09d08d864afb631%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637370053140089498&sdata=XUvdS67hdORI1INkcIolgIExH8%2FeEdm%2BJ5u0xXmy3Y8%3D&reserved=0>

---

From: Kiran Makhijani <[email-masked]>
Date: Thu, 1 Oct 2020 03:05:39 +0000

Hi Eric,
Yes, I was just thinking out loud about that sentence. You are absolutely right that when we talk about 3GPP applicability it is necessary to provide clarification that their transport network slice is our IETF network slice.  However there are other use cases too.

With separation I meant to ask that in applicability, does the consumer change? – it doesn’t as you said “a 3GPP “transport network slice” consumer would be an “IETF network slice” consumer”. So it may not be really needed to describe this part (unless we are super keen on showing 1:1 mapping).

If I remember correctly, in definitions draft we wanted to make it clear that the consumer is not an endpoint or a user but some management or orchestration entity, therefore, we chose the term transport slice consumer. It was easy to say but calling something IETF NS consumer is bit awkward.
Therefore, I am also asking ourselves should we call it “network slice consumer” or “IETF-network slice  consumer”?
-Kiran

From: Eric Gray <[email-masked]>
Date: Wednesday, September 30, 2020 at 6:33 AM
To: Kiran Makhijani <[email-masked]>
Cc: "Rokui, Reza (Nokia - CA/Ottawa)" <[email-masked]>, Lou Berger <[email-masked]>, "BRUNGARD, DEBORAH A" <[email-masked]>, Vishnu Pavan Beeram <[email-masked]>, TEAS WG <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Teas-ns-dt] [Teas] Various terms for transport portion of a network slicing

Hi Kiran.

—
Eric

On Sep 29, 2020, at 3:51 PM, Kiran Makhijani <[email-masked]<mailto:[email-masked]>> wrote:

Hi Eric,

From: Teas-ns-dt <[email-masked]<mailto:[email-masked]>> On Behalf Of Eric Gray
Sent: Tuesday, September 29, 2020 12:42 PM
To: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>>
Cc: Lou Berger <[email-masked]<mailto:[email-masked]>>; BRUNGARD, DEBORAH A <[email-masked]<mailto:[email-masked]>>; Vishnu Pavan Beeram <[email-masked]<mailto:[email-masked]>>; TEAS WG <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Teas-ns-dt] [Teas] Various terms for transport portion of a network slicing

Reza,

             Great!!

—
Eric

Eric and all,

Reza

Reza,

—
Eric

Cheers,

Term
Suggested by
Pros
Cons
1
IETF Network Slice
TEAS chairs

https://wiki.mef.net/display/CESG/Slicing+for+Shared+5G+Fronthaul+and+Backhaul+-+White+Paper<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.mef.net%2Fdisplay%2FCESG%2FSlicing%2Bfor%2BShared%2B5G%2BFronthaul%2Band%2BBackhaul%2B-%2BWhite%2BPaper&data=02%7C01%7Ckiranm%40futurewei.com%7Cb84fbfd46b7c4497b14008d865455d3e%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637370695891396752&sdata=cSqLneOEExIJWuSm0im%2FzIekZUwLU1w8r6Rx0dHDD3Y%3D&reserved=0>

See Figure 4.9.3.1 of TR 28.801 and  http://www.3gpp.org/NEWS-EVENTS/3GPP-NEWS/1951-SA5_5G<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.3gpp.org%2FNEWS-EVENTS%2F3GPP-NEWS%2F1951-SA5_5G&data=02%7C01%7Ckiranm%40futurewei.com%7Cb84fbfd46b7c4497b14008d865455d3e%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637370695891406708&sdata=k2RgFwwBd4MX0l0EoR0ChGX%2BEoBxY5AosNW9KvpAqx4%3D&reserved=0>

13

14
Transmission Slice
Reza

_______________________________________________
Teas mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/teas<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteas&data=02%7C01%7Ckiranm%40futurewei.com%7Cb84fbfd46b7c4497b14008d865455d3e%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637370695891406708&sdata=xKy1kNb68CAkbqPr%2BEZFglbGtkWTryZ05icbYYVPhEI%3D&reserved=0>