Subject: [Teas] Response of IETF Network slice coauthors to TEAS mailing list

From: "Rokui, Reza (Nokia - CA/Ottawa)" <[email-masked]>
Date: Thu, 4 Mar 2021 13:59:37 +0000

Hello all,

During the last couple of weeks, there were lots of good discussions on the mailing list regarding the various aspects of the IETF network slice
including the endpoints, mapping and use-cases. Thanks for all the comments and feedback. Based on these discussions, the co-authors of
the definition draft had a few meetings and compiled the following to capture the comments and suggestions of the WG.

IETF network slice as a Service
The co-authors agree with the mailing list suggestion to treat the IETF network slice as  a service.
In summary, an IETF Network Slice Service contains multiple endpoints (see discussion below for endpoint), multiple connections and multiple SLOs.
This is aligned with the mailing list. In consequence we propose to add “Service” to the text  in the draft defining what an IETF network slice is.

IETF network slice endpoints
From the discussions on the mailing list, there was an opinion in the WG to use the term ‘CE/PE’ terminology instead of IETF network slice endpoint (NSE).
Echoing the WG preference, we would adopt CE/PE terminology.
However, we would need to define another term to refer to the boundary between CE and PE
which is necessary for other works such as NBI data modeling and framework (to-be-decided). A term such as access point (AP, NS-AP or ??? ) could be a possible choice for NSE.
(see proposed in https://mailarchive.ietf.org/arch/msg/teas/TZDKLptFTkc6ZBH4x0ZhOrWhfEE/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fteas%2FTZDKLptFTkc6ZBH4x0ZhOrWhfEE%2F&data=04%7C01%7Ckiranm%40futurewei.com%7Cadd48f93578c42dac9f808d8de71566a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637503925662717859%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=g3j%2F0bOXoCdjWax9aZvIdpJkzeA82qF0m56UQNHYWC4%3D&reserved=0>)

Since the main objective is to use common IETF terminology, we summarized other options received from mailing list in the table below.
The authors are grateful for the working group discussion and look forward to following the WG guidance.
The draft author's proposal is to use a term such as  AP, NS-AP or a similar term.

Potential terms for endpoint suggested by mailing list (without any specific order)

Term
Suggested by
Pros

Cons
1
AP (access point)
Adrian and others in mailing list
o aligned with RFC 8453
o  AP is a logical identifier shared between customer and operator
  Not discussed by the list.
2
NS-AP (IETF Network Slice Access point)
Draft Authors
o Similar to AP case, aligned with RFC 8453
o it shows that it belongs to IETF network slice specification (in a similar way as it is done in RFC8453 when referring to VNAP)
o It conveys the meaning without limiting it to specific technology or network type
Not considered in discussions.
3
IETF network slice endpoints (NSE)
original term used in draft
o It provides an independent way of expressing slice endpoint
o Not preferred by TEAS mailing list because it is not consistent with the general usage in IETF. o RFC 3985 uses endpoints for connectivity (tunnels, links, etc). This limits the definition of network slices.
4
Attachment Circuit (AC)
mailing list
o RFC 3985
Since the endpoint on IETF network slice is technology agnostics, this term seems not appropriate.
AS per RFC 3985, AC is the physical or virtual. So, it describes the layer-2
technology  such as an ATM VPI/VCI, an Ethernet port, a VLAN, a PPP
connection on a  physical interface.
5
CE
mailing list

o implies a generic consumer/producer relationship.
o IEFT Network slices endpoints are logical entities. During realization of IETF network slices, they will be mapped to CE nodes
o CE itself is not the endpoint. Endpoints are mapped to CE
o Using CE in both logical context and realization context (mapping) can be confusing.
o CE is not a common terminology outside IP/MPLS domains e.g. optical, DWDM, microwave, and wireless networks.
o It may limit the implementations to VPN flavors.

IETF network slice mapping during the IETF network slice realization
Based on the discussions above on endpoint, there are various use-cases of the IETF network slice which in general fall into two categories:
Please note that based on suggestion from Adrian and others on mailing list, Figure-2 of RFC 3985 is used as a base:

  1.  Use-cases where the endpoint maps to CE as shown in Figure-1. The prime example of this use case is the 4G/5G e2e network slicing where the IETF network slice is created on 5G RAN and 5G Core nodes between N3 interfaces (see [1],[2]). In this case the RAN and Core are CE1 and CE2 nodes and the endpoints are mapped to CE nodes. Another example of this use case is again in 4G/5G e2e network slicing in Cloud RAN deployment when the IETF network slice is created between DU and CU nodes across F1 interface in Midhaul network (See  [1],[2]). In this case the endpoints are mapped to CE1 and CE2 (which are DU and CU nodes). In both cases the endpoints of IETF network slice realization are PE nodes (i.e. Cell Siter Routers and Border routers).
[1] Figure 4.7.1 https://www.etsi.org/deliver/etsi_ts/128500_128599/128530/15.00.00_60/ts_128530v150000p.pdf<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.etsi.org%2Fdeliver%2Fetsi_ts%2F128500_128599%2F128530%2F15.00.00_60%2Fts_128530v150000p.pdf&data=04%7C01%7Ckiranm%40futurewei.com%7Cadd48f93578c42dac9f808d8de71566a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637503925662727851%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=fhJ6B%2BJN58e%2BKed6menBEYJ3UAWdYyk2wSgB8Q3CYvE%3D&reserved=0>
[2] Figure 1 of https://tools.ietf.org/id/draft-clt-dmm-tn-aware-mobility-06.html#TS.23.501-3GPP

  1.  Use-cases where the endpoint maps to PE as shown in Figure-2. First example of this use case is DC Interconnect (DCI) where the IETF network slice is used to connect the PE nodes (i.e. DCGW). In this case the endpoints are mapped to PE nodes. The second use-case is the networking wholesale among operators where one operator sells the wholesale transport connectivity to another operator. In this case the Border routers between two operators will be the PE nodes used for mapping of IETF network slice endpoints. In both cases the endpoint for IETF network slice realization are PE nodes as well.

Consumer vs. customer
The co-authors do agree with either terms.
Please see Adrian’s view summarized here https://mailarchive.ietf.org/arch/msg/teas/V8ow_uptUZXHemdvHXggd7mqxU4/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fteas%2FV8ow_uptUZXHemdvHXggd7mqxU4%2F&data=04%7C01%7Ckiranm%40futurewei.com%7Cadd48f93578c42dac9f808d8de71566a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637503925662727851%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=06AR9q7v4FYaBk7zhNHr4cvuPPdg3EfFlgoD6pZNE1E%3D&reserved=0>

                                                                                   /|\
         ??? (e.g. NS-AP1)                       ??? (e.g. NS-AP2)       Definition |
           (maps to CE1)                          (maps to CE2)          of IETF NS |
               o<--------- IETF Network Slice   ------->o
                                 Service 1
               +     |                            |     +               Mapping     |
               +     |<----------- S1 ----------->|     +               of IETF NS  |
               +     |                            |     +                          \|/
           +         v                            v        +
         +           |----|                  |----|          +
    |-----|    |     | PE1|==================| PE2|          |-----|
    |     |----------|    |                  |    |     |    |     |
    |     |    |     |    |                  |    |----------|     |
    |     |----------|    |                  |    |     |    |     |
    |-----|    |     |    |==================|    |    AC    |-----|
              AC     |----|                  |----|
    Customer         Provider                Provider         Customer
    Edge 1           Edge 1                  Edge 2           Edge 2

Figure-1 For use-cases when NS-AP (or ???) mapped to CE

                                                                                   /|\
         ??? (e.g. NS-AP4)                       ??? (e.g. NS-AP3)       Definition |
           (maps to PE1)                          (maps to PE2)          of IETF NS |
               o<--------- IETF Network Slice   ------->o
                                 Service 2
               +     |                            |     +               Mapping     |
               +     |<----------- S2 ----------->|     +               of IETF NS  |
               +     |                            |     +                          \|/
                +    v                            v    +
                 +   |----|                  |----|  +
    |-----|    |   + | PE1|==================| PE2| +        |-----|
    |     |----------|    |                  |    |     |    |     |
    |     |    |     |    |                  |    |----------|     |
    |     |----------|    |                  |    |     |    |     |
    |-----|    |     |    |==================|    |    AC    |-----|
              AC     |----|                  |----|
    Customer         Provider                Provider         Customer
    Edge 1           Edge 1                  Edge 2           Edge 2

Figure-2 For use-cases when NS-AP (or ???) mapped to PE

  Legend:
      O: Representation of the IETF network slice access point (NS-AP or ???)
      +: Mapping of NS-AP (pr ???) to PE or CE nodes on IETF network
      S1,S2: Realization of the IETF network slice

Cheers,

 Jeff, Kiran, Luis, Shunsuke, Reza

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 4 Mar 2021 11:02:06 -0500

(I am not retaining the original message.  Please see it separately as 
it is long and detailed.)

I am confused by at least two aspects of the proposals from the document 
authors.

1) I am confused as to why PE is not listed as a viable term for the 
endpoint.  It seems the natural endpoint of the IETF Network Slice (not 
from the perspective of the service user) just as the PE is the endpoint 
of the operators service in the VPN cases, even though the customer's 
focus is on the CE devices.

2) I am confused by the assertion taht the 4G use case requires that the 
end points be the CE.  In those environments, the CE is not under the 
control of the what 3GPPP calls the Transport Network Slice controller. 
  As such, the CE can not be the endpoint of the IETF Network Slice.

I suspect that there are other places where I am misunderstanding the email.

---

From: John E Drake <[email-masked]>
Date: Thu, 4 Mar 2021 19:53:43 +0000

'Attachment circuit' is the channel by which data flows between a CE and PE and it is completely technology independent.  I didn't see any objection to this term prior to the email, below.

Yours Irrespectively,

John

Juniper Business Use Only
From: Teas <[email-masked]> On Behalf Of Rokui, Reza (Nokia - CA/Ottawa)
Sent: Thursday, March 4, 2021 9:00 AM
To: Lou Berger <[email-masked]>; TEAS WG <[email-masked]>; [email-masked] <[email-masked]>; BRUNGARD, DEBORAH A <[email-masked]>; [email-masked]
Cc: Shunsuke Homma <[email-masked]>; Jeff Tantsura <[email-masked]>; Kiran Makhijani <[email-masked]>; Luis M. Contreras <[email-masked]>; Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>
Subject: [Teas] Response of IETF Network slice coauthors to TEAS mailing list

[External Email. Be cautious of content]

Hello all,

IETF network slice as a Service
The co-authors agree with the mailing list suggestion to treat the IETF network slice as  a service.
In summary, an IETF Network Slice Service contains multiple endpoints (see discussion below for endpoint), multiple connections and multiple SLOs.
This is aligned with the mailing list. In consequence we propose to add "Service" to the text  in the draft defining what an IETF network slice is.

>From the discussions on the mailing list, there was an opinion in the WG to use the term 'CE/PE' terminology instead of IETF network slice endpoint (NSE).
Echoing the WG preference, we would adopt CE/PE terminology.
However, we would need to define another term to refer to the boundary between CE and PE
which is necessary for other works such as NBI data modeling and framework (to-be-decided). A term such as access point (AP, NS-AP or ??? ) could be a possible choice for NSE.
(see proposed in https://mailarchive.ietf.org/arch/msg/teas/TZDKLptFTkc6ZBH4x0ZhOrWhfEE/<https://urldefense.com/v3/__https:/nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Fmailarchive.ietf.org*2Farch*2Fmsg*2Fteas*2FTZDKLptFTkc6ZBH4x0ZhOrWhfEE*2F&data=04*7C01*7Ckiranm*40futurewei.com*7Cadd48f93578c42dac9f808d8de71566a*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C1*7C637503925662717859*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&sdata=g3j*2F0bOXoCdjWax9aZvIdpJkzeA82qF0m56UQNHYWC4*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!Ss61gKcRpGg4qEp93XhLRromL3_n4ICoUhGdO6v_g3MgdFgGDl9gtw1MO4P53dc$>)

Term
Suggested by
Pros

Cons
1
AP (access point)

  1.  Use-cases where the endpoint maps to CE as shown in Figure-1. The prime example of this use case is the 4G/5G e2e network slicing where the IETF network slice is created on 5G RAN and 5G Core nodes between N3 interfaces (see [1],[2]). In this case the RAN and Core are CE1 and CE2 nodes and the endpoints are mapped to CE nodes. Another example of this use case is again in 4G/5G e2e network slicing in Cloud RAN deployment when the IETF network slice is created between DU and CU nodes across F1 interface in Midhaul network (See  [1],[2]). In this case the endpoints are mapped to CE1 and CE2 (which are DU and CU nodes). In both cases the endpoints of IETF network slice realization are PE nodes (i.e. Cell Siter Routers and Border routers).
[1] Figure 4.7.1 https://www.etsi.org/deliver/etsi_ts/128500_128599/128530/15.00.00_60/ts_128530v150000p.pdf<https://urldefense.com/v3/__https:/nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Fwww.etsi.org*2Fdeliver*2Fetsi_ts*2F128500_128599*2F128530*2F15.00.00_60*2Fts_128530v150000p.pdf&data=04*7C01*7Ckiranm*40futurewei.com*7Cadd48f93578c42dac9f808d8de71566a*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C1*7C637503925662727851*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&sdata=fhJ6B*2BJN58e*2BKed6menBEYJ3UAWdYyk2wSgB8Q3CYvE*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!NEt6yMaO-gk!Ss61gKcRpGg4qEp93XhLRromL3_n4ICoUhGdO6v_g3MgdFgGDl9gtw1Mn2Ofz5Y$>
[2] Figure 1 of https://tools.ietf.org/id/draft-clt-dmm-tn-aware-mobility-06.html#TS.23.501-3GPP

Consumer vs. customer
The co-authors do agree with either terms.
Please see Adrian's view summarized here https://mailarchive.ietf.org/arch/msg/teas/V8ow_uptUZXHemdvHXggd7mqxU4/<https://urldefense.com/v3/__https:/nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Fmailarchive.ietf.org*2Farch*2Fmsg*2Fteas*2FV8ow_uptUZXHemdvHXggd7mqxU4*2F&data=04*7C01*7Ckiranm*40futurewei.com*7Cadd48f93578c42dac9f808d8de71566a*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C1*7C637503925662727851*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&sdata=06AR9q7v4FYaBk7zhNHr4cvuPPdg3EfFlgoD6pZNE1E*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUl!!NEt6yMaO-gk!Ss61gKcRpGg4qEp93XhLRromL3_n4ICoUhGdO6v_g3MgdFgGDl9gtw1MBUNfP74$>

                                                                                   /|\

                                                                                   /|\

  Legend:

Cheers,

---

From: <[email-masked]>
Date: Fri, 5 Mar 2021 08:58:59 +0000

Hi all,

Agree with John.

I see that NBI is mentioned (which I hope we will change one day to something more meaningful), but in that interface the mapping of the slice to a local interface/component of a PE is not visible to the customer.

If the concern is the local identification of the attachment circuit at the CE side (to handle multi-homing cases, for example), then this is a local identifier of the attachment circuit as seen by the customer.

Given the granularity to be captured in the definition draft, I do think that "attachment circuit" is just sufficient. Of course, local/remote identifiers of such circuit (can be manipulated when it comes to the modeling part), but that does not justify a need for a new term.

Cheers,
Med

De : Teas [mailto:[email-masked]] De la part de John E Drake
Envoyé : jeudi 4 mars 2021 20:54
À : Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>; Lou Berger <[email-masked]>; TEAS WG <[email-masked]>; [email-masked] <[email-masked]>; BRUNGARD, DEBORAH A <[email-masked]>; [email-masked]
Cc : Shunsuke Homma <[email-masked]>; Jeff Tantsura <[email-masked]>; Kiran Makhijani <[email-masked]>; Luis M. Contreras <[email-masked]>
Objet : Re: [Teas] Response of IETF Network slice coauthors to TEAS mailing list

Yours Irrespectively,

John

Juniper Business Use Only
From: Teas <[email-masked]<mailto:[email-masked]>> On Behalf Of Rokui, Reza (Nokia - CA/Ottawa)
Sent: Thursday, March 4, 2021 9:00 AM
To: Lou Berger <[email-masked]<mailto:[email-masked]>>; TEAS WG <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; BRUNGARD, DEBORAH A <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: Shunsuke Homma <[email-masked]<mailto:[email-masked]>>; Jeff Tantsura <[email-masked]<mailto:[email-masked]>>; Kiran Makhijani <[email-masked]<mailto:[email-masked]>>; Luis M. Contreras <[email-masked]<mailto:[email-masked]>>; Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>>
Subject: [Teas] Response of IETF Network slice coauthors to TEAS mailing list

Hello all,

Term

Suggested by

Pros

Cons

1

AP (access point)

o aligned with RFC 8453

2

Draft Authors

3

4

Attachment Circuit (AC)

mailing list

o RFC 3985

5

CE

mailing list

Consumer vs. customer

                                                                                   /|\

                                                                                   /|\

  Legend:

Cheers,

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.