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

[[e-mail]]

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

'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 <[e-mail]<mailto:[e-mail]>> On Behalf Of Rokui, Reza (Nokia - CA/Ottawa)
Sent: Thursday, March 4, 2021 9:00 AM
To: Lou Berger <[e-mail]<mailto:[e-mail]>>; TEAS WG <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; BRUNGARD, DEBORAH A <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: Shunsuke Homma <[e-mail]<mailto:[e-mail]>>; Jeff Tantsura <[e-mail]<mailto:[e-mail]>>; Kiran Makhijani <[e-mail]<mailto:[e-mail]>>; Luis M. Contreras <[e-mail]<mailto:[e-mail]>>; Rokui, Reza (Nokia - CA/Ottawa) <[e-mail]<mailto:[e-mail]>>
Subject: [Teas] Response of IETF Network slice coauthors to TEAS mailing list

[External Email. Be cautious of content]

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://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$>)

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://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

  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://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$>


                                                                                   /|\
         ??? (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


_________________________________________________________________________________________________________________________

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.