Subject: [Teas] network Slice Endpoint in draft-ietf-teas-ietf-network-slice-definition-00

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 5 Feb 2021 12:04:29 -0500

Rereading this draft, I realized that I am either confused by or 
disagree with the description of the "Network Slice Endpoint" contianed 
there.

The endpoint that I think matters is the place where the IETF Network 
Slice Controller starts controlling the QoS and traffic delivery.  The 
Controller doesn't care about the identity of the device outside of that.

Figure 1 in section 4.2 seems to define that endpoint as the network 
slice realiation endpoint, and describes the network slice endpoint as 
the thing outside the IetF network slice.  This seems counter-productive 
to me.  It complicates teh relationship between the endpoitn and the 
service being abstracted.  For example, if the service is beign 
delivered with MPLS, the Network Slice Endpoint likely can not put the 
labels on the packet for the MPLS, as it is outside of the IETF network 
Slice.  So we will need yet another layer of classification, and yet 
more interworking.
Further, someone has to get the queueing right for traffic coming out of 
the Network Slice Endpoint.  But it is not part of the IETF Network 
Slice, so we don't have any way to get it right.

If we define the edge of the space we care about co-incident with the 
edge of the space we influence, things get a lot cleaner.

Yours,
Joel

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 5 Feb 2021 22:29:04 -0000

Ah, the old "endpoint" discussion.

Yes, Joel is right, we need to disambiguate endpoints from endpoints.
There are traffic endpoints (the sender and receiver of packets), and there
are endpoints of the service (the ingress and egress to the slice).

There is probably a risk that we get sucked in to the wider 5G picture, but
we need to focus (as Joel says) on the IETF network slice.

I suggest "source/destination" and "IETF network slice ingress/egress".

And we can avoid discussion of the wider 5G context, as noted elsewhere in
the draft, by diverting that material into a dedicated document.

Cheers,
Adrian

-----Original Message-----
From: Teas <[email-masked]> On Behalf Of Joel M. Halpern
Sent: 05 February 2021 17:04
To: [email-masked]
Subject: [Teas] network Slice Endpoint in
draft-ietf-teas-ietf-network-slice-definition-00

Yours,
Joel

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

---

From: "Rokui, Reza (Nokia - CA/Ottawa)" <[email-masked]>
Date: Wed, 10 Feb 2021 12:39:04 +0000

Joel and Adrian,

Agreed that there shall be clarity about the endpoints.

                >>>>>> There are traffic endpoints (the sender and receiver of packets), and there are endpoints of the service (the ingress and egress to the slice).

This is correct Adrian.

An “IETF network slice” is between two or more endpoints as outlined in the draft.

In summary, the  IETF network slice is defined  between various device/applications/network functions on multiple “IETF network slice endpoints”.  These are traffic endpoints of the IETF network slice. We refer to them in the draft as “NSE” (IETF Network Slice Endpoints).

In addition , as Adrian mentioned there are endpoints to the realization of the transport slice (i.e. various services/tunnels/paths). I am suggesting to use term “NSI” (IETF Network Slice Ingress).  Please provide your suggestions for NSI if you have any other suggestions.

                >>>> For example, if the service is being

    delivered with MPLS, the Network Slice Endpoint likely cannot put the

    more interworking.

This is not correct.  Whatever technology is used to realize the IETF network slice must be supported by endpoints. If MPLS is technology of choice, the endpoint must support it in its data-path (and might also support it in its control-plane).

Cheers,

Reza

    ------------------Original Message-----------------------

On 2021-02-05, 5:29 PM, "Teas on behalf of Adrian Farrel" <[email-masked] on behalf of [email-masked]> wrote:

    Cheers,

    Adrian

    -----Original Message-----

    To: [email-masked]

    there.

    more interworking.

    Yours,

    Joel

    Teas mailing list

    [email-masked]

    Teas mailing list

    [email-masked]

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 10 Feb 2021 09:09:28 -0500

Rexza, there seems to be an inconssitency at the end of your note.
You state that whatever technology is used for teh IETF network slice 
must be supported by the endpoint.  If by Endpoint we mean the edge of 
the IETF Network Slice, I agree.
However, you actually draw the "Network Slice Endpoint" as being outside 
of the IETF Network Slice.  This creates two problems.  First, the IETF 
Network Slice Controller can not ensure that the correct technology 
usage is applied, as the Network Slice Endpoint is not under the control 
of the IETF Network Slice Controller.  Second, this implies that the 
IETF Network Slice will trust the technology marking (for example MPLS 
label) being sent by the external entity.  The general model is that 
such trust is not assumed.

Thus, I can not see how to make what you have diagrammed work.
Given that, I am asking the WG (which now owns the document) to modify 
the figure.

Yours,
Joel

On 2/10/2021 7:39 AM, Rokui, Reza (Nokia - CA/Ottawa) wrote:
>                  >>>>>> There are traffic endpoints (the sender and 
> receiver of packets), and there are endpoints of the service (the 
> ingress and egress to the slice).
> 
> This is correct Adrian.
> 
> In summary, the  IETF network slice is defined  between various 
> device/applications/network functions on multiple “IETF network slice 
> endpoints”.  These are traffic endpoints of the IETF network slice. We 
> refer to them in the draft as “NSE” (IETF Network Slice Endpoints).
> 
> In addition , as Adrian mentioned there are endpoints to the realization 
> of the transport slice (i.e. various services/tunnels/paths). I am 
> suggesting to use term “NSI” (IETF Network Slice Ingress).  Please 
> provide your suggestions for NSI if you have any other suggestions.
> 
>                  >>>> For example, if the service is being
> 
> This is not correct.  Whatever technology is used to realize the IETF 
> network slice must be supported by endpoints. If MPLS is technology of 
> choice, the endpoint must support it in its data-path (and might also 
> support it in its control-plane).
> 
> Cheers,
> 
> Reza
> 
> On 2021-02-05, 5:29 PM, "Teas on behalf of Adrian Farrel" 
> <[email-masked] on behalf of [email-masked]> wrote:
>

---

From: "Rokui, Reza (Nokia - CA/Ottawa)" <[email-masked]>
Date: Wed, 10 Feb 2021 15:00:47 +0000

Joel,
Comments are inlined.

Cheers,
Reza

On 2021-02-10, 9:09 AM, "Joel M. Halpern" <[email-masked]> wrote:

[Reza] Yes it is.  Endpoint means the IETF Network Slice endpoints. There is only one type of endpoints. I will modify the definition draft and remove NSRE.

    However, you actually draw the "Network Slice Endpoint" as being outside 
    of the IETF Network Slice.  
[Reza] What does with " outside" of IETF network slice mean? An IETF network slice is between various endpoints.

This creates two problems.  First, the IETF 
    Network Slice Controller can not ensure that the correct technology 
    usage is applied, as the Network Slice Endpoint is not under the control 
    of the IETF Network Slice Controller.  Second, this implies that the 
    IETF Network Slice will trust the technology marking (for example MPLS 
    label) being sent by the external entity.  The general model is that 
    such trust is not assumed.
[Reza] This is correct that this is not the role of NCS to make sure the correct technology is applied to components outside the IETF scope. Having said that, the technology on both side must be the same.
So, whatever technology is used in NCS to realize the IETF Network Slice (which is the logic on NCS Mapping function) should take this into consideration. (Refer to IETF Network Slice Framework draft as well).

    Thus, I can not see how to make what you have diagrammed work.
    Given that, I am asking the WG (which now owns the document) to modify 
    the figure.
[Reza] the new text and diagram with be added.

    Yours,
    Joel

    On 2/10/2021 7:39 AM, Rokui, Reza (Nokia - CA/Ottawa) wrote:
    >                  >>>>>> There are traffic endpoints (the sender and

---

From: John E Drake <[email-masked]>
Date: Wed, 10 Feb 2021 16:21:19 +0000

Hi,

Comment inline

Yours Irrespectively,

John

Juniper Business Use Only
From: Teas <[email-masked]> On Behalf Of Rokui, Reza (Nokia - CA/Ottawa)
Sent: Wednesday, February 10, 2021 7:39 AM
To: [email-masked]; 'Joel M. Halpern' <[email-masked]>; [email-masked]
Cc: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>
Subject: Re: [Teas] network Slice Endpoint in draft-ietf-teas-ietf-network-slice-definition-00

[External Email. Be cautious of content]

Joel and Adrian,

This is correct Adrian.

    more interworking.

[JD]  This is incorrect.   E.g., in IETF VPNs, the traffic from the CE to the PE is *not* MPLS encapsulated.  It is the PE that does the encapsulation.

Cheers,

Reza

    ------------------Original Message-----------------------

On 2021-02-05, 5:29 PM, "Teas on behalf of Adrian Farrel" <[email-masked] on behalf of [email-masked]<mailto:[email-masked][email-masked]>> wrote:

    Cheers,

    Adrian

    -----Original Message-----

    From: Teas <[email-masked]<mailto:[email-masked]>> On Behalf Of Joel M. Halpern

    To: [email-masked]<mailto:[email-masked]>

    there.

    more interworking.

    Yours,

    Joel

    Teas mailing list

    [email-masked]<mailto:[email-masked]>

    Teas mailing list

    [email-masked]<mailto:[email-masked]>

---

From: "Rokui, Reza (Nokia - CA/Ottawa)" <[email-masked]>
Date: Wed, 10 Feb 2021 16:42:09 +0000

See inline please.

Cheers,
Reza

From: John E Drake <[email-masked]>
Date: Wednesday, February 10, 2021 at 11:21 AM
To: Reza Rokui <[email-masked]>, "[email-masked]" <[email-masked]>, "'Joel M. Halpern'" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: [Teas] network Slice Endpoint in draft-ietf-teas-ietf-network-slice-definition-00

Hi,

Comment inline

Yours Irrespectively,

John

Joel and Adrian,

This is correct Adrian.

    more interworking.

[Reza] Disagree. There are use-cases where the traffic to transport network is not IP and is Labeled-packets.

Cheers,

Reza

    ------------------Original Message-----------------------

    Cheers,

    Adrian

    -----Original Message-----

    there.

    more interworking.

    Yours,

    Joel

    Teas mailing list

    Teas mailing list

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 10 Feb 2021 17:29:21 -0000

Hi all, 

In case this discussion is getting heated, can I observe that I find Figure 2 of RFC 3985 hugely useful in this context. Yes, it is only referring to a P2P service and not an MP2MP service, but the same concepts apply and it is likely that all our figures will only show P2P anyway.

You might note that that figure does not use the term “end point” and does this without any loss of meaning. However, whether the terms CE and PE will be applicable for us (probably they are) is up for debate.

You might also note that the rest of 3985 *does* use the term “endpoint” but it does so only to refer to “tunnel endpoints”.

Let’s step even further back from this.

Is a network slice “connectivity” or does is it a network service?

Connections, tunnels, links all have end points.

Services have “service delivery points” and “access points”.

Or is a slice a type of network (virtual or logical or sliced)?

Networks have “edges” and “access points”.

Adrian

From: Teas <[email-masked]> On Behalf Of John E Drake
Sent: 10 February 2021 16:21
To: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>; [email-masked]; 'Joel M. Halpern' <[email-masked]>; [email-masked]
Subject: Re: [Teas] network Slice Endpoint in draft-ietf-teas-ietf-network-slice-definition-00

Hi,

Comment inline

Yours Irrespectively,

John

From: Teas <[email-masked] <mailto:[email-masked]> > On Behalf Of Rokui, Reza (Nokia - CA/Ottawa)
Sent: Wednesday, February 10, 2021 7:39 AM
To: [email-masked] <mailto:[email-masked]> ; 'Joel M. Halpern' <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> 
Cc: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked] <mailto:[email-masked]> >
Subject: Re: [Teas] network Slice Endpoint in draft-ietf-teas-ietf-network-slice-definition-00

Joel and Adrian,

This is correct Adrian.

    more interworking.

Cheers,

Reza

    ------------------Original Message-----------------------

On 2021-02-05, 5:29 PM, "Teas on behalf of Adrian Farrel" <[email-masked] on behalf of [email-masked] <mailto:[email-masked][email-masked]> > wrote:

    Cheers,

    Adrian

    -----Original Message-----

    From: Teas <[email-masked] <mailto:[email-masked]> > On Behalf Of Joel M. Halpern

    To: [email-masked] <mailto:[email-masked]> 

    there.

    more interworking.

    Yours,

    Joel

    Teas mailing list

    [email-masked] <mailto:[email-masked]> 

    Teas mailing list

    [email-masked] <mailto:[email-masked]>

---

From: Joel Halpern Direct <[email-masked]>
Date: Wed, 10 Feb 2021 12:41:25 -0500

In every case I know of (which is I grant not every case) the non-IP 
packet is still a packet.  It is generally delivered to the service 
provider as an Ethernet packet (since that is the only other kind of 
packet we actually deal with.)

I do not know of any operator who trusts his customer to put an MPLS 
label on a packet which the operator will use for switching.  (The 
closest I know of is when the operator actually controls the CPE.  Which 
is clearly not what you are describing.)

If you have another use case in mind, it would be very helpful if you 
would explain it in more detail.

Yours,
Joel

On 2/10/2021 11:42 AM, Rokui, Reza (Nokia - CA/Ottawa) wrote:
> See inline please.
> 
> Cheers,
> 
> Reza
> 
> *From: *John E Drake <[email-masked]>
> *Date: *Wednesday, February 10, 2021 at 11:21 AM
> *To: *Reza Rokui <[email-masked]>, "[email-masked]" 
> <[email-masked]>, "'Joel M. Halpern'" <[email-masked]>, 
> "[email-masked]" <[email-masked]>
> *Subject: *RE: [Teas] network Slice Endpoint in 
> *From:* Teas <[email-masked]> *On Behalf Of * Rokui, Reza (Nokia 
> - CA/Ottawa)
> *Sent:* Wednesday, February 10, 2021 7:39 AM
> *To:* [email-masked]; 'Joel M. Halpern' <[email-masked]>; 
> [email-masked]
> *Cc:* Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>
> *Subject:* Re: [Teas] network Slice Endpoint in 
> *[External Email. Be cautious of content]*
> 
> Joel and Adrian,
> 
> *//*
> */[JD]  This is incorrect.   E.g., in IETF VPNs, the traffic from the CE 
> to the PE is *not* MPLS encapsulated.  It is the PE that does the 
> encapsulation./*
> 
> [Reza] Disagree. There are use-cases where the traffic to transport 
> network is not IP and is Labeled-packets.
> 
> Cheers,
> 
> Reza
> 
> <[email-masked] on behalf of [email-masked] 
> <mailto:[email-masked][email-masked]>> 
> wrote:
> 
>      From: Teas <[email-masked] <mailto:[email-masked]>> 
> On Behalf Of Joel M. Halpern
> 
> <https://www.ietf.org/mailman/listinfo/teas>
> 
> <https://www.ietf.org/mailman/listinfo/teas>
> 
>

---

From: "Rokui, Reza (Nokia - CA/Ottawa)" <[email-masked]>
Date: Wed, 10 Feb 2021 18:09:58 +0000

Hi Adrian,

My comment is inlined.

Reza

From: Adrian Farrel <[email-masked]>
Organization: Old Dog Consulting
Reply-To: "[email-masked]" <[email-masked]>
Date: Wednesday, February 10, 2021 at 12:29 PM
To: 'John E Drake' <jdrake=[email-masked]>, Reza Rokui <[email-masked]>, "'Joel M. Halpern'" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: [Teas] network Slice Endpoint in draft-ietf-teas-ietf-network-slice-definition-00

Hi all,

You might note that that figure does not use the term “end point” and does this without any loss of meaning. However, whether the terms CE and PE will be applicable for us (probably they are) is up for debate.
[Reza] this picture might be useful but without referring to PE and CE. IMO it is not applicable to our discussion since IETF network slice is technology-agnostic.

Let’s step even further back from this.
Is a network slice “connectivity” or does is it a network service?
[Reza] In Definition draft the co-authors intentionally did not use term “Service” since this term is overloaded and anybody can have his own interpretation.
So, IETF network slice is a group of connections between multiple endpoints which are realized in the operator’s transport network using any L0/L1/L2/L3 services/tunnels.
Note that the transport network might either be IP/MPLS or other technologies (e.g. PON)

Connections, tunnels, links all have end points.
Services have “service delivery points” and “access points”.
Or is a slice a type of network (virtual or logical or sliced)?
Networks have “edges” and “access points”.
[Reza] Good point Adrian. All these are related to “IETF Network Slice REALIZATION”. So any L0/L1/L2/L3 services/tunnels used to realize the IETF network slice will have its own access point, endpoints etc.
These are different from “IETF Network Slice Endpoints” but obviously there will be a relationship between them.

Adrian

Hi,

Comment inline

Yours Irrespectively,

John

Juniper Business Use Only
From: Teas <[email-masked]<mailto:[email-masked]>> On Behalf Of Rokui, Reza (Nokia - CA/Ottawa)
Sent: Wednesday, February 10, 2021 7:39 AM
To: [email-masked]<mailto:[email-masked]>; 'Joel M. Halpern' <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Teas] network Slice Endpoint in draft-ietf-teas-ietf-network-slice-definition-00

Joel and Adrian,

This is correct Adrian.

    more interworking.

Cheers,

Reza

    ------------------Original Message-----------------------

    Cheers,

    Adrian

    -----Original Message-----

    there.

    more interworking.

    Yours,

    Joel

    Teas mailing list

    Teas mailing list

---

From: Kiran Makhijani <[email-masked]>
Date: Wed, 10 Feb 2021 18:17:00 +0000

Reza, and all,
Agreed, architecturally, network slice is a type of network, based on the discussion, maybe NSEs can be called NS-AP (access points) and their realizations remain unchanged – NSREs?
Looking forward to the updated figure.
Cheers,
Kiran

From: Teas <[email-masked]> on behalf of Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>
Date: Wednesday, February 10, 2021 at 10:10
To: [email-masked] <[email-masked]>, 'John E Drake' <jdrake=[email-masked]>, 'Joel M. Halpern' <[email-masked]>, [email-masked] <[email-masked]>
Cc: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>
Subject: Re: [Teas] network Slice Endpoint in draft-ietf-teas-ietf-network-slice-definition-00
Hi Adrian,

My comment is inlined.

Reza

Hi all,

Adrian

Hi,

Comment inline

Yours Irrespectively,

John

Joel and Adrian,

This is correct Adrian.

    more interworking.

Cheers,

Reza

    ------------------Original Message-----------------------

    Cheers,

    Adrian

    -----Original Message-----

    there.

    more interworking.

    Yours,

    Joel

    Teas mailing list

    https://www.ietf.org/mailman/listinfo/teas<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteas&data=04%7C01%7Ckiranm%40futurewei.com%7C9d061022e3134937e99808d8cdef1b65%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637485774164684689%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Or0VHlh6juqRDIKJ8Ip7oAtrtASa1anmCu6wfZulGcE%3D&reserved=0>

    Teas mailing list

    https://www.ietf.org/mailman/listinfo/teas<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteas&data=04%7C01%7Ckiranm%40futurewei.com%7C9d061022e3134937e99808d8cdef1b65%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637485774164694683%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Bg%2Bl%2FUfgZV4r0xHOPRtNvp6lXzNe76vnhNlVK7QzMck%3D&reserved=0>

---

From: Uma Chunduri <[email-masked]>
Date: Thu, 11 Feb 2021 16:32:37 -0800

> I suggest "source/destination" and "IETF network slice ingress/egress".

+1 for the above.

--
Uma C.

---

From: "Rokui, Reza (Nokia - CA/Ottawa)" <[email-masked]>
Date: Fri, 12 Feb 2021 14:09:40 +0000

Joel,

There are some discussions on this topic for 5G for example. See the following draft:

  *   draft-geng-teas-network-slice-mapping-02

Reza

On 2021-02-10, 12:41 PM, "Joel Halpern Direct" <[email-masked]> wrote:

    Yours,

    Joel

    > An “IETF network slice” is between two or more endpoints as outlined in

    > the draft.

    >      labels on the packet for the MPLS, as it is outside of the IETF

    > network

    >      There are traffic endpoints (the sender and receiver of packets),

    > and there

    >      There is probably a risk that we get sucked in to the wider 5G

    > picture, but

    >      And we can avoid discussion of the wider 5G context, as noted

    > elsewhere in

    >      disagree with the description of the "Network Slice Endpoint"

    > contianed

    >      Controller doesn't care about the identity of the device outside of

    > that.

    >      the thing outside the IetF network slice.  This seems

    > counter-productive

    >      labels on the packet for the MPLS, as it is outside of the IETF

    > network

    >      Further, someone has to get the queueing right for traffic coming

    > out of

---

From: "Rokui, Reza (Nokia - CA/Ottawa)" <[email-masked]>
Date: Fri, 12 Feb 2021 14:30:58 +0000

Uma,

Please my previous response to this email thread.
The draft co-authors are working on these terms  but the suggested terms (or some of them) might be considered.

Reza

From: Teas <[email-masked]> on behalf of Uma Chunduri <[email-masked]>
Date: Thursday, February 11, 2021 at 7:32 PM
To: "[email-masked]" <[email-masked]>
Cc: "Joel M. Halpern" <[email-masked]>, TEAS WG <[email-masked]>
Subject: Re: [Teas] network Slice Endpoint in draft-ietf-teas-ietf-network-slice-definition-00

+1 for the above.

--
Uma C.

On Fri, Feb 5, 2021 at 2:29 PM Adrian Farrel <[email-masked]<mailto:[email-masked]>> wrote:
Ah, the old "endpoint" discussion.

Cheers,
Adrian

-----Original Message-----
From: Teas <[email-masked]<mailto:[email-masked]>> On Behalf Of Joel M. Halpern
Sent: 05 February 2021 17:04
To: [email-masked]<mailto:[email-masked]>
Subject: [Teas] network Slice Endpoint in

Yours,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 12 Feb 2021 09:43:50 -0500

Reza, I looked at that paper.  I do not see anything in there that 
addresses the inconsistency I am calling out below.

Yours,
Joel

On 2/12/2021 9:09 AM, Rokui, Reza (Nokia - CA/Ottawa) wrote:
>      > See inline please.
>      >
>      > Cheers,
>      >
>      > Reza
>      >
>      > *From: *John E Drake <[email-masked]>
> 
>      > *Date: *Wednesday, February 10, 2021 at 11:21 AM
> 
>      > *To: *Reza Rokui <[email-masked]>, "[email-masked]"
> 
>      > <[email-masked]>, "'Joel M. Halpern'" <[email-masked]>,
> 
>      > "[email-masked]" <[email-masked]>
> 
>      > *Subject: *RE: [Teas] network Slice Endpoint in
> 
>      > draft-ietf-teas-ietf-network-slice-definition-00
> 
>      >
> 
>      > Hi,
> 
>      >
> 
>      > Comment inline
> 
>      >
> 
>      > Yours Irrespectively,
> 
>      >
> 
>      > John
> 
>      >
> 
>      > Juniper Business Use Only
> 
>      >
> 
>      > *From:* Teas <[email-masked]> *On Behalf Of * Rokui, Reza 
> (Nokia
> 
>      > - CA/Ottawa)
> 
>      > *Sent:* Wednesday, February 10, 2021 7:39 AM
> 
>      > *To:* [email-masked]; 'Joel M. Halpern' <[email-masked]>;
> 
>      > [email-masked]
> 
>      > *Cc:* Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>
> 
>      > *Subject:* Re: [Teas] network Slice Endpoint in
> 
>      > draft-ietf-teas-ietf-network-slice-definition-00
> 
>      >
> 
>      > *[External Email. Be cautious of content]*
> 
>      >
> 
>      > Joel and Adrian,
> 
>      >
> 
>      > Agreed that there shall be clarity about the endpoints.
> 
>      >
> 
>      >                  >>>>>> There are traffic endpoints (the sender and
> 
>      > receiver of packets), and there are endpoints of the service (the
> 
>      > ingress and egress to the slice).
> 
>      >
> 
>      > This is correct Adrian.
> 
>      >
> 
>      > An “IETF network slice” is between two or more endpoints as 
> outlined in
> 
>      > the draft.
> 
>      >
> 
>      > In summary, the  IETF network slice is defined  between various
> 
>      > device/applications/network functions on multiple “IETF network 
> slice
> 
>      > endpoints”.  These are traffic endpoints of the IETF network 
> slice. We
> 
>      > refer to them in the draft as “NSE” (IETF Network Slice Endpoints).
> 
>      >
> 
>      > In addition , as Adrian mentioned there are endpoints to the 
> realization
> 
>      > of the transport slice (i.e. various services/tunnels/paths). I am
> 
>      > suggesting to use term “NSI” (IETF Network Slice Ingress).  Please
> 
>      > provide your suggestions for NSI if you have any other suggestions.
> 
>      >
> 
>      >                  >>>> For example, if the service is being
> 
>      >
> 
>      >      delivered with MPLS, the Network Slice Endpoint likely 
> cannot put the
> 
>      >
> 
>      >      labels on the packet for the MPLS, as it is outside of the IETF
> 
>      > network
> 
>      >
> 
>      >      Slice.  So we will need yet another layer of classification, 
> and yet
> 
>      >
> 
>      >      more interworking.
> 
>      >
> 
>      > This is not correct.  Whatever technology is used to realize the 
> IETF
> 
>      > network slice must be supported by endpoints. If MPLS is 
> technology of
> 
>      > choice, the endpoint must support it in its data-path (and might 
> also
> 
>      > support it in its control-plane).
> 
>      >
> 
>      > *//*
> 
>      >
> 
>      > */[JD]  This is incorrect.   E.g., in IETF VPNs, the traffic from 
> the CE
> 
>      > to the PE is *not* MPLS encapsulated.  It is the PE that does the
> 
>      > encapsulation./*
> 
>      >
> 
>      > [Reza] Disagree. There are use-cases where the traffic to transport
> 
>      > network is not IP and is Labeled-packets.
> 
>      >
> 
>      > Cheers,
> 
>      >
> 
>      > Reza
> 
>      >
> 
>      >      ------------------Original Message-----------------------
> 
>      >
> 
>      > On 2021-02-05, 5:29 PM, "Teas on behalf of Adrian Farrel"
> 
>      > <[email-masked] on behalf of [email-masked]
> 
>      > 
>      > wrote:
>      >
>      >      Ah, the old "endpoint" discussion.
> 
>      >
> 
>      >      Yes, Joel is right, we need to disambiguate endpoints from 
> endpoints.
> 
>      >
> 
>      >      There are traffic endpoints (the sender and receiver of 
> packets),
> 
>      > and there
> 
>      >
> 
>      >      are endpoints of the service (the ingress and egress to the 
> slice).
> 
>      >
> 
>      >      There is probably a risk that we get sucked in to the wider 5G
> 
>      > picture, but
> 
>      >
> 
>      >      we need to focus (as Joel says) on the IETF network slice.
> 
>      >
> 
>      >      I suggest "source/destination" and "IETF network slice 
> ingress/egress".
> 
>      >
> 
>      >      And we can avoid discussion of the wider 5G context, as noted
> 
>      > elsewhere in
> 
>      >
> 
>      >      the draft, by diverting that material into a dedicated document.
> 
>      >
> 
>      >      Cheers,
> 
>      >
> 
>      >      Adrian
> 
>      >
> 
>      >      -----Original Message-----
> 
>      >
> 
>      >      From: Teas <[email-masked] 
> <mailto:[email-masked]>>
> 
>      > On Behalf Of Joel M. Halpern
> 
>      >
> 
>      >      Sent: 05 February 2021 17:04
> 
>      >
> 
>      >      To: [email-masked] <mailto:[email-masked]>
> 
>      >
> 
>      >      Subject: [Teas] network Slice Endpoint in
> 
>      >
> 
>      >      draft-ietf-teas-ietf-network-slice-definition-00
> 
>      >
> 
>      >      Rereading this draft, I realized that I am either confused by or
> 
>      >
> 
>      >      disagree with the description of the "Network Slice Endpoint"
> 
>      > contianed
> 
>      >
> 
>      >      there.
> 
>      >
> 
>      >      The endpoint that I think matters is the place where the 
> IETF Network
> 
>      >
> 
>      >      Slice Controller starts controlling the QoS and traffic 
> delivery.  The
> 
>      >
> 
>      >      Controller doesn't care about the identity of the device 
> outside of
> 
>      > that.
> 
>      >
> 
>      >      Figure 1 in section 4.2 seems to define that endpoint as the 
> network
> 
>      >
> 
>      >      slice realiation endpoint, and describes the network slice 
> endpoint as
> 
>      >
> 
>      >      the thing outside the IetF network slice.  This seems
> 
>      > counter-productive
> 
>      >
> 
>      >      to me.  It complicates teh relationship between the endpoitn 
> and the
> 
>      >
> 
>      >      service being abstracted.  For example, if the service is beign
> 
>      >
> 
>      >      delivered with MPLS, the Network Slice Endpoint likely can 
> not put the
> 
>      >
> 
>      >      labels on the packet for the MPLS, as it is outside of the IETF
> 
>      > network
> 
>      >
> 
>      >      Slice.  So we will need yet another layer of classification, 
> and yet
> 
>      >
> 
>      >      more interworking.
> 
>      >
> 
>      >      Further, someone has to get the queueing right for traffic 
> coming
> 
>      > out of
> 
>      >
> 
>      >      the Network Slice Endpoint.  But it is not part of the IETF 
> Network
> 
>      >
> 
>      >      Slice, so we don't have any way to get it right.
> 
>      >
> 
>      >      If we define the edge of the space we care about co-incident 
> with the
> 
>      >
> 
>      >      edge of the space we influence, things get a lot cleaner.
> 
>      >
> 
>      >      Yours,
> 
>      >
> 
>      >      Joel
> 
>      >
> 
>      >      _______________________________________________
> 
>      >
> 
>      >      Teas mailing list
> 
>      >
> 
>      > [email-masked] <mailto:[email-masked]>
> 
>      >
> 
>      > https://www.ietf.org/mailman/listinfo/teas
> 
>      > <https://www.ietf.org/mailman/listinfo/teas>
> 
>      >
> 
>      >      _______________________________________________
> 
>      >
> 
>      >      Teas mailing list
> 
>      >
> 
>      > [email-masked] <mailto:[email-masked]>
> 
>      >
> 
>      > https://www.ietf.org/mailman/listinfo/teas
> 
>      > <https://www.ietf.org/mailman/listinfo/teas>
> 
>      >
> 
>      >
> 
>      > _______________________________________________
> 
>      > Teas mailing list
> 
>      > [email-masked]
> 
>      > https://www.ietf.org/mailman/listinfo/teas
> 
>      >
> 
>

---

From: "Rokui, Reza (Nokia - CA/Ottawa)" <[email-masked]>
Date: Fri, 12 Feb 2021 14:51:30 +0000

Joel,

Please see section 4.3.2.1. Layer 3 and Layer 2 Encapsulations where the sentence start with If the AN or CN could support MPLS,….

It shows that the traffic from AN or CN (i.e. RAN or Core Network) might be MPLS.

Reza

On 2021-02-12, 9:43 AM, "Joel M. Halpern" <[email-masked]> wrote:

    Yours,

    Joel

    > There are some discussions on this topic for 5G for example. See the

    > following draft:

    > On 2021-02-10, 12:41 PM, "Joel Halpern Direct"

    > <[email-masked]> wrote:

    >      closest I know of is when the operator actually controls the CPE.

    > Which

    >      > *From:* Teas <[email-masked]> *On Behalf Of * Rokui, Reza

    >      > An “IETF network slice” is between two or more endpoints as

    >      > device/applications/network functions on multiple “IETF network

    >      > endpoints”.  These are traffic endpoints of the IETF network

    >      > In addition , as Adrian mentioned there are endpoints to the

    >      >      delivered with MPLS, the Network Slice Endpoint likely

    >      >      Slice.  So we will need yet another layer of classification,

    >      > This is not correct.  Whatever technology is used to realize the

    >      > network slice must be supported by endpoints. If MPLS is

    >      > choice, the endpoint must support it in its data-path (and might

    >      > */[JD]  This is incorrect.   E.g., in IETF VPNs, the traffic from

    >      >      Yes, Joel is right, we need to disambiguate endpoints from

    >      >      There are traffic endpoints (the sender and receiver of

    >      >      are endpoints of the service (the ingress and egress to the

    >      >      I suggest "source/destination" and "IETF network slice

    >      >      From: Teas <[email-masked]

    >      >      The endpoint that I think matters is the place where the

    >      >      Slice Controller starts controlling the QoS and traffic

    >      >      Controller doesn't care about the identity of the device

    >      >      Figure 1 in section 4.2 seems to define that endpoint as the

    >      >      slice realiation endpoint, and describes the network slice

    >      >      to me.  It complicates teh relationship between the endpoitn

    >      >      delivered with MPLS, the Network Slice Endpoint likely can

    >      >      Slice.  So we will need yet another layer of classification,

    >      >      Further, someone has to get the queueing right for traffic

    >      >      the Network Slice Endpoint.  But it is not part of the IETF

    >      >      If we define the edge of the space we care about co-incident

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 12 Feb 2021 10:13:30 -0500

Yes, it shows that the authors thinks the AN / CN could send MPLS.
If that label is consumed by the operational edge (ingress) as an 
indicator of the service to be provided, that is fine.  But that is not 
what drew.  I know of no operator that will allow an MPLS label from a 
customer to be passed into and used by the internals of their network.

Yours,
Joel

On 2/12/2021 9:51 AM, Rokui, Reza (Nokia - CA/Ottawa) wrote:
> Joel,
> 
> Please see section 4_.3.2.1. Layer 3 and Layer 2 Encapsulations wh_ere 
> the sentence start with _If the AN or CN could support MPLS,…._
> 
>      > Joel,
>      > There are some discussions on this topic for 5G for example. See the
> 
>      > following draft:
> 
>      >
> 
>      >   * draft-geng-teas-network-slice-mapping-02
> 
>      >
> 
>      > Reza
> 
>      >
> 
>      > On 2021-02-10, 12:41 PM, "Joel Halpern Direct"
> 
>      > <[email-masked]> wrote:
> 
>      >
> 
>      >      In every case I know of (which is I grant not every case) 
> the non-IP
> 
>      >
> 
>      >      packet is still a packet.  It is generally delivered to the 
> service
> 
>      >
> 
>      >      provider as an Ethernet packet (since that is the only other 
> kind of
> 
>      >
> 
>      >      packet we actually deal with.)
> 
>      >
> 
>      >      I do not know of any operator who trusts his customer to put 
> an MPLS
> 
>      >
> 
>      >      label on a packet which the operator will use for 
> switching.  (The
> 
>      >
> 
>      >      closest I know of is when the operator actually controls the 
> CPE.
> 
>      > Which
> 
>      >
> 
>      >      is clearly not what you are describing.)
> 
>      >
> 
>      >      If you have another use case in mind, it would be very 
> helpful if you
> 
>      >
> 
>      >      would explain it in more detail.
> 
>      >
> 
>      >      Yours,
> 
>      >
> 
>      >      Joel
> 
>      >
> 
>      >      On 2/10/2021 11:42 AM, Rokui, Reza (Nokia - CA/Ottawa) wrote:
> 
>      >
> 
>      >      > See inline please.
> 
>      >
> 
>      >      >
> 
>      >
> 
>      >      > Cheers,
> 
>      >
> 
>      >      >
> 
>      >
> 
>      >      > Reza
> 
>      >
> 
>      >      >
> 
>      >
> 
>      >      > *From: *John E Drake <[email-masked]>
> 
>      >
> 
>      >      > *Date: *Wednesday, February 10, 2021 at 11:21 AM
> 
>      >
> 
>      >      > *To: *Reza Rokui <[email-masked]>, "[email-masked]"
> 
>      >
> 
>      >      > <[email-masked]>, "'Joel M. Halpern'" 
> <[email-masked]>,
> 
>      >
> 
>      >      > "[email-masked]" <[email-masked]>
> 
>      >
> 
>      >      > *Subject: *RE: [Teas] network Slice Endpoint in
> 
>      >
> 
>      >      > draft-ietf-teas-ietf-network-slice-definition-00
> 
>      >
> 
>      >      >
> 
>      >
> 
>      >      > Hi,
> 
>      >
> 
>      >      >
> 
>      >
> 
>      >      > Comment inline
> 
>      >
> 
>      >      >
> 
>      >
> 
>      >      > Yours Irrespectively,
> 
>      >
> 
>      >      >
> 
>      >
> 
>      >      > John
> 
>      >
> 
>      >      >
> 
>      >
> 
>      >      > Juniper Business Use Only
> 
>      >
> 
>      >      >
> 
>      >
> 
>      >      > *From:* Teas <[email-masked]> *On Behalf Of * 
> Rokui, Reza
> 
>      > (Nokia
> 
>      >
> 
>      >      > - CA/Ottawa)
> 
>      >
> 
>      >      > *Sent:* Wednesday, February 10, 2021 7:39 AM
> 
>      >
> 
>      >      > *To:* [email-masked]; 'Joel M. Halpern' 
> <[email-masked]>;
> 
>      >
> 
>      >      > [email-masked]
> 
>      >
> 
>      >      > *Cc:* Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>
> 
>      >
> 
>      >      > *Subject:* Re: [Teas] network Slice Endpoint in
> 
>      >
> 
>      >      > draft-ietf-teas-ietf-network-slice-definition-00
> 
>      >
> 
>      >      >
> 
>      >
> 
>      >      > *[External Email. Be cautious of content]*
> 
>      >
> 
>      >      >
> 
>      >
> 
>      >      > Joel and Adrian,
> 
>      >
> 
>      >      >
> 
>      >
> 
>      >      > Agreed that there shall be clarity about the endpoints.
> 
>      >
> 
>      >      >
> 
>      >
> 
>      >      >                  >>>>>> There are traffic endpoints (the 
> sender and
> 
>      >
> 
>      >      > receiver of packets), and there are endpoints of the 
> service (the
> 
>      >
> 
>      >      > ingress and egress to the slice).
> 
>      >
> 
>      >      >
> 
>      >
> 
>      >      > This is correct Adrian.
> 
>      >
> 
>      >      >
> 
>      >
> 
>      >      > An “IETF network slice” is between two or more endpoints as
> 
>      > outlined in
> 
>      >
> 
>      >      > the draft.
> 
>      >
> 
>      >      >
> 
>      >
> 
>      >      > In summary, the  IETF network slice is defined  between 
> various
> 
>      >
> 
>      >      > device/applications/network functions on multiple “IETF 
> network
> 
>      > slice
> 
>      >
> 
>      >      > endpoints”.  These are traffic endpoints of the IETF network
> 
>      > slice. We
> 
>      >
> 
>      >      > refer to them in the draft as “NSE” (IETF Network Slice 
> Endpoints).
> 
>      >
> 
>      >      >
> 
>      >
> 
>      >      > In addition , as Adrian mentioned there are endpoints to the
> 
>      > realization
> 
>      >
> 
>      >      > of the transport slice (i.e. various 
> services/tunnels/paths). I am
> 
>      >
> 
>      >      > suggesting to use term “NSI” (IETF Network Slice 
> Ingress).  Please
> 
>      >
> 
>      >      > provide your suggestions for NSI if you have any other 
> suggestions.
> 
>      >
> 
>      >      >
> 
>      >
> 
>      >      >                  >>>> For example, if the service is being
> 
>      >
> 
>      >      >
> 
>      >
> 
>      >      >      delivered with MPLS, the Network Slice Endpoint likely
> 
>      > cannot put the
> 
>      >
> 
>      >      >
> 
>      >
> 
>      >      >      labels on the packet for the MPLS, as it is outside 
> of the IETF
> 
>      >
> 
>      >      > network
> 
>      >
> 
>      >      >
> 
>      >
> 
>      >      >      Slice.  So we will need yet another layer of 
> classification,
> 
>      > and yet
> 
>      >
> 
>      >      >
> 
>      >
> 
>      >      >      more interworking.
> 
>      >
> 
>      >      >
> 
>      >
> 
>      >      > This is not correct.  Whatever technology is used to 
> realize the
> 
>      > IETF
> 
>      >
> 
>      >      > network slice must be supported by endpoints. If MPLS is
> 
>      > technology of
> 
>      >
> 
>      >      > choice, the endpoint must support it in its data-path (and 
> might
> 
>      > also
> 
>      >
> 
>      >      > support it in its control-plane).
> 
>      >
> 
>      >      >
> 
>      >
> 
>      >      > *//*
> 
>      >
> 
>      >      >
> 
>      >
> 
>      >      > */[JD]  This is incorrect.   E.g., in IETF VPNs, the 
> traffic from
> 
>      > the CE
> 
>      >
> 
>      >      > to the PE is *not* MPLS encapsulated.  It is the PE that 
> does the
> 
>      >
> 
>      >      > encapsulation./*
> 
>      >
> 
>      >      >
> 
>      >
> 
>      >      > [Reza] Disagree. There are use-cases where the traffic to 
> transport
> 
>      >
> 
>      >      > network is not IP and is Labeled-packets.
> 
>      >
> 
>      >      >
> 
>      >
> 
>      >      > Cheers,
> 
>      >
> 
>      >      >
> 
>      >
> 
>      >      > Reza
> 
>      >
> 
>      >      >
> 
>      >
> 
>      >      >      ------------------Original Message-----------------------
> 
>      >
> 
>      >      >
> 
>      >
> 
>      >      > On 2021-02-05, 5:29 PM, "Teas on behalf of Adrian Farrel"
> 
>      >
> 
>      >      > <[email-masked] on behalf of [email-masked]
> 
>      >
> 
>      >      >
> 
>      > 
>      >      > wrote:
>      >      >
>      >      >      Ah, the old "endpoint" discussion.
> 
>      >
> 
>      >      >
> 
>      >
> 
>      >      >      Yes, Joel is right, we need to disambiguate endpoints 
> from
> 
>      > endpoints.
> 
>      >
> 
>      >      >
> 
>      >
> 
>      >      >      There are traffic endpoints (the sender and receiver of
> 
>      > packets),
> 
>      >
> 
>      >      > and there
> 
>      >
> 
>      >      >
> 
>      >
> 
>      >      >      are endpoints of the service (the ingress and egress 
> to the
> 
>      > slice).
> 
>      >
> 
>      >      >
> 
>      >
> 
>      >      >      There is probably a risk that we get sucked in to the 
> wider 5G
> 
>      >
> 
>      >      > picture, but
> 
>      >
> 
>      >      >
> 
>      >
> 
>      >      >      we need to focus (as Joel says) on the IETF network 
> slice.
> 
>      >
> 
>      >      >
> 
>      >
> 
>      >      >      I suggest "source/destination" and "IETF network slice
> 
>      > ingress/egress".
> 
>      >
> 
>      >      >
> 
>      >
> 
>      >      >      And we can avoid discussion of the wider 5G context, 
> as noted
> 
>      >
> 
>      >      > elsewhere in
> 
>      >
> 
>      >      >
> 
>      >
> 
>      >      >      the draft, by diverting that material into a 
> dedicated document.
> 
>      >
> 
>      >      >
> 
>      >
> 
>      >      >      Cheers,
> 
>      >
> 
>      >      >
> 
>      >
> 
>      >      >      Adrian
> 
>      >
> 
>      >      >
> 
>      >
> 
>      >      >      -----Original Message-----
> 
>      >
> 
>      >      >
> 
>      >
> 
>      >      >      From: Teas <[email-masked]
> 
>      > <mailto:[email-masked]>>
> 
>      >
> 
>      >      > On Behalf Of Joel M. Halpern
> 
>      >
> 
>      >      >
> 
>      >
> 
>      >      >      Sent: 05 February 2021 17:04
> 
>      >
> 
>      >      >
> 
>      >
> 
>      >      >      To: [email-masked] <mailto:[email-masked]>
> 
>      >
> 
>      >      >
> 
>      >
> 
>      >      >      Subject: [Teas] network Slice Endpoint in
> 
>      >
> 
>      >      >
> 
>      >
> 
>      >      >      draft-ietf-teas-ietf-network-slice-definition-00
> 
>      >
> 
>      >      >
> 
>      >
> 
>      >      >      Rereading this draft, I realized that I am either 
> confused by or
> 
>      >
> 
>      >      >
> 
>      >
> 
>      >      >      disagree with the description of the "Network Slice 
> Endpoint"
> 
>      >
> 
>      >      > contianed
> 
>      >
> 
>      >      >
> 
>      >
> 
>      >      >      there.
> 
>      >
> 
>      >      >
> 
>      >
> 
>      >      >      The endpoint that I think matters is the place where the
> 
>      > IETF Network
> 
>      >
> 
>      >      >
> 
>      >
> 
>      >      >      Slice Controller starts controlling the QoS and traffic
> 
>      > delivery.  The
> 
>      >
> 
>      >      >
> 
>      >
> 
>      >      >      Controller doesn't care about the identity of the device
> 
>      > outside of
> 
>      >
> 
>      >      > that.
> 
>      >
> 
>      >      >
> 
>      >
> 
>      >      >      Figure 1 in section 4.2 seems to define that endpoint 
> as the
> 
>      > network
> 
>      >
> 
>      >      >
> 
>      >
> 
>      >      >      slice realiation endpoint, and describes the network 
> slice
> 
>      > endpoint as
> 
>      >
> 
>      >      >
> 
>      >
> 
>      >      >      the thing outside the IetF network slice.  This seems
> 
>      >
> 
>      >      > counter-productive
> 
>      >
> 
>      >      >
> 
>      >
> 
>      >      >      to me.  It complicates teh relationship between the 
> endpoitn
> 
>      > and the
> 
>      >
> 
>      >      >
> 
>      >
> 
>      >      >      service being abstracted.  For example, if the 
> service is beign
> 
>      >
> 
>      >      >
> 
>      >
> 
>      >      >      delivered with MPLS, the Network Slice Endpoint 
> likely can
> 
>      > not put the
> 
>      >
> 
>      >      >
> 
>      >
> 
>      >      >      labels on the packet for the MPLS, as it is outside 
> of the IETF
> 
>      >
> 
>      >      > network
> 
>      >
> 
>      >      >
> 
>      >
> 
>      >      >      Slice.  So we will need yet another layer of 
> classification,
> 
>      > and yet
> 
>      >
> 
>      >      >
> 
>      >
> 
>      >      >      more interworking.
> 
>      >
> 
>      >      >
> 
>      >
> 
>      >      >      Further, someone has to get the queueing right for 
> traffic
> 
>      > coming
> 
>      >
> 
>      >      > out of
> 
>      >
> 
>      >      >
> 
>      >
> 
>      >      >      the Network Slice Endpoint.  But it is not part of 
> the IETF
> 
>      > Network
> 
>      >
> 
>      >      >
> 
>      >
> 
>      >      >      Slice, so we don't have any way to get it right.
> 
>      >
> 
>      >      >
> 
>      >
> 
>      >      >      If we define the edge of the space we care about 
> co-incident
> 
>      > with the
> 
>      >
> 
>      >      >
> 
>      >
> 
>      >      >      edge of the space we influence, things get a lot cleaner.
> 
>      >
> 
>      >      >
> 
>      >
> 
>      >      >      Yours,
> 
>      >
> 
>      >      >
> 
>      >
> 
>      >      >      Joel
> 
>      >
> 
>      >      >
> 
>      >
> 
>      >      >      _______________________________________________
> 
>      >
> 
>      >      >
> 
>      >
> 
>      >      >      Teas mailing list
> 
>      >
> 
>      >      >
> 
>      >
> 
>      >      > [email-masked] <mailto:[email-masked]>
> 
>      >
> 
>      >      >
> 
>      >
> 
>      >      > https://www.ietf.org/mailman/listinfo/teas
> 
>      >
> 
>      >      > <https://www.ietf.org/mailman/listinfo/teas>
> 
>      >
> 
>      >      >
> 
>      >
> 
>      >      >      _______________________________________________
> 
>      >
> 
>      >      >
> 
>      >
> 
>      >      >      Teas mailing list
> 
>      >
> 
>      >      >
> 
>      >
> 
>      >      > [email-masked] <mailto:[email-masked]>
> 
>      >
> 
>      >      >
> 
>      >
> 
>      >      > https://www.ietf.org/mailman/listinfo/teas
> 
>      >
> 
>      >      > <https://www.ietf.org/mailman/listinfo/teas>
> 
>      >
> 
>      >      >
> 
>      >
> 
>      >      >
> 
>      >
> 
>      >      > _______________________________________________
> 
>      >
> 
>      >      > Teas mailing list
> 
>      >
> 
>      >      > [email-masked]
> 
>      >
> 
>      >      > https://www.ietf.org/mailman/listinfo/teas
> 
>      >
> 
>      >      >
> 
>      >
> 
>      >
>

---

From: "Rokui, Reza (Nokia - CA/Ottawa)" <[email-masked]>
Date: Fri, 12 Feb 2021 16:26:17 +0000

>>> as an indicator of the service to be provided, that is fine.
This is my understanding as well. The mpls label is used for separation of e2e network slides which means separation of L0/L2/L2/L3 services during the realization.

Reza

On 2021-02-12, 10:13 AM, "Joel M. Halpern" <[email-masked]> wrote:

    Yours,
    Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 12 Feb 2021 11:41:03 -0500

The version that works is "consumed by the edge" and "provides 
indication".  The simplest way out of this is to go to the terminology 
others have suggested of talking about ingress (and egress), which are 
at the edge of the IETF Network Slice.

Yours,
Joel

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 12 Feb 2021 16:41:07 -0000

Pardon the ASCII art, but I just wanted to quickly illustrate that this is not a new debate by a very long way. As Joel says, some technologies are simply not allowed to be injected into the provider network: MPLS is a good example. In this case either:

- the access connection uses a payload technology such as Ethernet so that the CE-CE connection is an emulated service

- the CE is a provider controlled node that is actually part of the provider network

Where the access network is a RAN, it seems unlikely that the PE will have radio capabilities. So the CE must convert to a signal type the provider network can process.

Now the (possibly) interesting case is where the provider network is IP. In this case the CE could send an IP packet to the PE (provided address spaces are resolved).

Now, when we look at the figures, the debate about where the edge of the slice is located should drop out relatively easily. Just ask: what network resources can be shared, are under provider control, and can be sliced?

I think that, further, if we consider a slice to be a network that looks and feels to the customer like it might be a provider network, then this also helps identify the edge.

However, *if* we consider the network slice to be a service (which I accept many don't want to do) the question about at what point the service is provided might be more entertaining. It was while considering this that I found Figure 2 of RFC 3985 useful.

_________________________     _____________________

(                         )   (                 

(           -----------   )   (   -----------   Provider

( Access   | Customer  |__)___(__| Provider  |  Network

( Network  | Edge Node |  )   (  | Edge Node |  Slice

(           -----------   )   (   -----------

(_________________________)   (______________________

________________   ________________________________

(                ) (                            

(           -----------           -----------   Provider

( Access   | Customer  |_________| Provider  |  Network

( Network  | Edge Node |         | Edge Node |  Slice

(           -----------           -----------

(________________) (_________________________________

Adrian

From: Teas <[email-masked]> On Behalf Of Rokui, Reza (Nokia - CA/Ottawa)
Sent: 12 February 2021 14:52
To: Joel M. Halpern <[email-masked]>; [email-masked]
Subject: Re: [Teas] network Slice Endpoint in draft-ietf-teas-ietf-network-slice-definition-00

Joel,

Reza

On 2021-02-12, 9:43 AM, "Joel M. Halpern" <[email-masked] <mailto:[email-masked]> > wrote:

    Yours,

    Joel

    > <[email-masked] <mailto:[email-masked]> > wrote:

    >      > *From: *John E Drake <[email-masked] <mailto:[email-masked]> >

    >      > *To: *Reza Rokui <[email-masked] <mailto:[email-masked]> >, "[email-masked] <mailto:[email-masked]> "

    >      > <[email-masked] <mailto:[email-masked]> >, "'Joel M. Halpern'" <[email-masked] <mailto:[email-masked]> >,

    >      > "[email-masked] <mailto:[email-masked]> " <[email-masked] <mailto:[email-masked]> >

    >      > *From:* Teas <[email-masked] <mailto:[email-masked]> > *On Behalf Of * Rokui, Reza 

    >      > *To:* [email-masked] <mailto:[email-masked]> ; 'Joel M. Halpern' <[email-masked] <mailto:[email-masked]> >;

    >      > [email-masked] <mailto:[email-masked]> 

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

    >      >      To: [email-masked] <mailto:[email-masked]>  <mailto:[email-masked]>

    >      > [email-masked] <mailto:[email-masked]>  <mailto:[email-masked]>

    >      > [email-masked] <mailto:[email-masked]>  <mailto:[email-masked]>

---

From: John E Drake <[email-masked]>
Date: Fri, 12 Feb 2021 16:46:37 +0000

Hi,

Comments inline

Yours Irrespectively,

John

Juniper Business Use Only
From: Adrian Farrel <[email-masked]>
Sent: Wednesday, February 10, 2021 12:29 PM
To: John E Drake <[email-masked]>; 'Rokui, Reza (Nokia - CA/Ottawa)' <[email-masked]>; 'Joel M. Halpern' <[email-masked]>
Cc: [email-masked]
Subject: RE: [Teas] network Slice Endpoint in draft-ietf-teas-ietf-network-slice-definition-00

Hi all,

[JD]  Almost certainly – it’s the standard IETF terminology

[JD]  It’s a network service

[JD]  This sounds good to me

Adrian

From: Teas <[email-masked]<mailto:[email-masked]>> On Behalf Of John E Drake
Sent: 10 February 2021 16:21
To: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; 'Joel M. Halpern' <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Teas] network Slice Endpoint in draft-ietf-teas-ietf-network-slice-definition-00

Hi,

Comment inline

Yours Irrespectively,

John

Joel and Adrian,

This is correct Adrian.

    more interworking.

Cheers,

Reza

    ------------------Original Message-----------------------

    Cheers,

    Adrian

    -----Original Message-----

    there.

    more interworking.

    Yours,

    Joel

    Teas mailing list

    https://www.ietf.org/mailman/listinfo/teas<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!USwujae5c4K64PC5PJd3jKQC-8QgVMQ2vbXzXImhk3Q8K12pHTTKZw2CuDDVyP0$>

    Teas mailing list

    https://www.ietf.org/mailman/listinfo/teas<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!USwujae5c4K64PC5PJd3jKQC-8QgVMQ2vbXzXImhk3Q8K12pHTTKZw2CuDDVyP0$>

---

From: Uma Chunduri <[email-masked]>
Date: Fri, 12 Feb 2021 15:08:48 -0800

Thank you!

Modulo the naming as discussed the Figure 1 scope and description is
correctly specified from myview.*

--
Uma C.

*Frankly a bit lost on the objection/discussion (maybe I am missing
something badly).

On Fri, Feb 12, 2021 at 6:31 AM Rokui, Reza (Nokia - CA/Ottawa) <
[email-masked]> wrote:

> *From: *Teas <[email-masked]> on behalf of Uma Chunduri <
> [email-masked]>
> *Date: *Thursday, February 11, 2021 at 7:32 PM
> *To: *"[email-masked]" <[email-masked]>
> *Cc: *"Joel M. Halpern" <[email-masked]>, TEAS WG <[email-masked]>
> *Subject: *Re: [Teas] network Slice Endpoint in

---

From: <[email-masked]>
Date: Tue, 16 Feb 2021 16:05:13 +0000

Hi Joel, 

I disagree with this note. I do think that both flavors of "endpoint" should be included in the draft. 

>From the customer standpoint, a slice request cannot be characterized by elements not visible to the customer. The scope of a requested slice can only be characterized between nodes that are known to the requestor. This is usually called, CE.  

The mapping between a CE and a network device (typically, a PE) is a process that is internal to the slice provider.  

The CE-PE link cannot be systematically excluded as some specific behaviors may need to be enforced in the CE-PE link. Think about a slice that is implemented by means of a PE-based VPN and which requires some specific routing + QoS policies at the CE-PE link.

Cheers,
Med

> -----Message d'origine-----
> De : Teas [mailto:[email-masked]] De la part de Joel M.
> Halpern
> Envoyé : vendredi 5 février 2021 18:04
> À : [email-masked]
> Objet : [Teas] network Slice Endpoint in draft-ietf-teas-ietf-
> network-slice-definition-00
> 
> contianed there.
> Slice Controller starts controlling the QoS and traffic delivery.
> The Controller doesn't care about the identity of the device outside
> of that.
> 
> slice realiation endpoint, and describes the network slice endpoint
> as the thing outside the IetF network slice.  This seems counter-
> productive to me.  It complicates teh relationship between the
> endpoitn and the service being abstracted.  For example, if the
> service is beign delivered with MPLS, the Network Slice Endpoint
> likely can not put the labels on the packet for the MPLS, as it is
> outside of the IETF network Slice.  So we will need yet another layer
> of classification, and yet more interworking.
> Further, someone has to get the queueing right for traffic coming out
> of the Network Slice Endpoint.  But it is not part of the IETF
> Network Slice, so we don't have any way to get it right.
> 

_________________________________________________________________________________________________________________________

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.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 16 Feb 2021 11:11:45 -0500

The document is not about the request from the external customer (the 
request for the end-to-end network slice). It is about the request from 
other orchestration systems to the IETF Network Slice management 
systems.  Yes, those systems need to know where they intent to utilize 
the IETF network slice.  But the IETF network slice does not need to 
know about that.

In particular, when we get to talking about configuring the IETF Network 
Slice properties, the edge (ingress) that the IETF Network Slice 
controller controls (and corresponding egress) is what needs to be 
provisioned.
It is possible that on the egress side there needs to be information 
about how to deliver the traffic externally.  But that would not be in 
terms of end-points since from the perspective of the IETF Network 
Slice, on the egress that is not an endpoint of anything.

Yours,
Joel

---

From: <[email-masked]>
Date: Tue, 16 Feb 2021 16:39:02 +0000

Re-,

Please see inline. 

Cheers,
Med

> Envoyé : mardi 16 février 2021 17:12
> À : [email-masked]
> Objet : Re: [Teas] network Slice Endpoint in draft-ietf-teas-ietf-
> request for the end-to-end network slice). It is about the request
> from other orchestration systems to the IETF Network Slice management
> systems. 

[Med] ... which is still behaving as the customer role. 

 Yes, those systems need to know where they intent to
> utilize the IETF network slice.  But the IETF network slice does not
> need to know about that.

[Med] This is what I fail to see. The orchestrator has an internal vision that is not available to the entity asking for a slice. These nodes are not even known to the "other orchestration systems" when asking for a slice. 

> 
> In particular, when we get to talking about configuring the IETF
> Network Slice properties, the edge (ingress) that the IETF Network
> Slice controller controls (and corresponding egress) is what needs to
> be provisioned.

[Med] Agree, but that is a distinct phase. 

BTW, ingress/egress are as a function of the traffic direction. A node (PE) may behave as both ingress and egress for the same slice.  

> about how to deliver the traffic externally.

[Med] Agree. That node does not need to be visible (known in advance) to the entity that will consume the corresponding slice.

  But that would not be
> in terms of end-points since from the perspective of the IETF Network

[Med] I agree that "endpoint" is confusing. "Customer Node/Edge" vs "Provider Edge" are my favorite here. 

> > I disagree with this note. I do think that both flavors of
> "endpoint" should be included in the draft.
> >
> >>From the customer standpoint, a slice request cannot be
> characterized by elements not visible to the customer. The scope of a
> requested slice can only be characterized between nodes that are
> known to the requestor. This is usually called, CE.
> >
> > The mapping between a CE and a network device (typically, a PE) is
> a process that is internal to the slice provider.
> >
> > The CE-PE link cannot be systematically excluded as some specific
> behaviors may need to be enforced in the CE-PE link. Think about a
> slice that is implemented by means of a PE-based VPN and which
> requires some specific routing + QoS policies at the CE-PE link.
> >
> > Cheers,
> > Med

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 16 Feb 2021 11:43:52 -0500

I would be happy to use CE and PE.  I would also be happy to use 
completely different words.  The current diagram and terminology makes 
this very confusing, and leads to problems.

Yours,
Joel

---

From: <[email-masked]>
Date: Tue, 16 Feb 2021 16:58:39 +0000

Re-,

Indeed. That's need to be fixed. 

As we are on the terminology, I do also suggest that the draft is updated to adhere to RFC8309. Given the recursiveness discussed in the draft, having geo-coordinates interfaces is also confusing. Inspiring from RFC8309 would make more sense.

Cheers,
Med

> De : Joel M. Halpern [mailto:[email-masked]]
> Envoyé : mardi 16 février 2021 17:44
> À : BOUCADAIR Mohamed TGI/OLN <[email-masked]>;
> [email-masked]
> completely different words.  The current diagram and terminology
> makes this very confusing, and leads to problems.
> 
> Yours,
> Joel
> 
> > [Med] This is what I fail to see. The orchestrator has an internal
> vision that is not available to the entity asking for a slice. These
> nodes are not even known to the "other orchestration systems" when
> asking for a slice.
> >
> >>
> > BTW, ingress/egress are as a function of the traffic direction. A
> node (PE) may behave as both ingress and egress for the same slice.
> >
> > [Med] Agree. That node does not need to be visible (known in
> advance) to the entity that will consume the corresponding slice.
> >
> >    But that would not be
> _____________________________________________________________________
> _
> > ___________________________________________________
> >
> > 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.
> >

---

From: John E Drake <[email-masked]>
Date: Tue, 16 Feb 2021 19:11:59 +0000

CE, PE, and attachment circuit are all pretty standard IETF terms.

Yours Irrespectively,

John

> Sent: Tuesday, February 16, 2021 11:44 AM
> To: [email-masked]; [email-masked]
> I would be happy to use CE and PE.  I would also be happy to use completely
> different words.  The current diagram and terminology makes this very
> confusing, and leads to problems.
> 
> Yours,
> Joel
> 
> > [Med] This is what I fail to see. The orchestrator has an internal vision that is
> not available to the entity asking for a slice. These nodes are not even known to
> the "other orchestration systems" when asking for a slice.
> >
> >>
> > BTW, ingress/egress are as a function of the traffic direction. A node (PE) may
> behave as both ingress and egress for the same slice.
> >
> > [Med] Agree. That node does not need to be visible (known in advance) to the
> entity that will consume the corresponding slice.
> >
> >    But that would not be
> _________________________________________________________________
> _____
> > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
> > 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.
> >
> > privileged information that may be protected by law; they should not be
> distributed, used or copied without authorisation.
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;!!N
> Et6yMaO-gk!WwkejosBVkuIchCGJXaCm1T8VfR8wz-qtyI0_9r0T-
> BO1LShePwDGA6L6j-HWgk$

---

From: tom petch <[email-masked]>
Date: Wed, 17 Feb 2021 10:27:26 +0000

From: Teas <[email-masked]> on behalf of John E Drake <jdrake=[email-masked]>
Sent: 16 February 2021 19:11

<tp>
Indeed, the RFC Editor offers a choice of
- Customer Edge (CE)  or
- Control Element (CE)  or
- Congestion Experienced (CE)

Tom Petch

Yours Irrespectively,

John

---

From: John E Drake <[email-masked]>
Date: Tue, 23 Feb 2021 14:52:36 +0000

Hi,

Eric and I have reviewed the Definitions draft, the email thread with the subject line: Network Slice Endpoint in draft-ietf-teas-ietf-network-slice-definition-00, and the RFCs referenced in emails on that thread - 3985, 4110, 4026, 4664, and 8309, and we would like to propose that in the Definitions draft we replace 'network slice endpoint' with 'CE' and 'network slice realization endpoint' with 'PE', that we reference  RFCs  3985, 4110, 4026, 4664, and 8309, and that we  replace the current figure in Endpoint section with several figures, which show connectivity constructs and which are consistent with these RFCs.  We would also like to replace 'consumer' with 'customer', add 'attachment circuit', and add a new term, viz, 'IETF Network Slice Service', whose definition is a set of CEs, a set of connectivity constructs (MP2MP, P2MP, P2P, etc.) between subsets of these CEs and an SLO for each CE sending to each connectivity construct.

As an aside, the Endpoint section of the Definitions draft uses the bulk of its prose enumerating what its endpoints are not.  Per Yakov, since there are a potentially infinite number of things which its endpoints are not, this is futile and we would like to remove that prose.

Yours Irrespectively,

Eric and John

> From: Teas <[email-masked]> On Behalf Of
> [email-masked]
> Sent: Tuesday, February 16, 2021 11:59 AM
> As we are on the terminology, I do also suggest that the draft is updated to
> adhere to RFC8309. Given the recursiveness discussed in the draft, having geo-
> coordinates interfaces is also confusing. Inspiring from RFC8309 would make
> more sense.
> 
> Cheers,
> Med
> 
> > De : Joel M. Halpern [mailto:[email-masked]] Envoyé : mardi 16
> > février 2021 17:44 À : BOUCADAIR Mohamed TGI/OLN
> > <[email-masked]>; [email-masked] Objet : Re: [Teas]
> > network Slice Endpoint in draft-ietf-teas-ietf-
> > >> Envoyé : mardi 16 février 2021 17:12 À : [email-masked] Objet : Re:
> > >> [Teas] network Slice Endpoint in draft-ietf-teas-ietf-
> ____
> ________________________________________________________
> 
> 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.
> Et6yMaO-gk!TrdpM67-tg4psF0dnG7jBV9LisKHxO_oCNxmQXrJhY-
> B6MFchY8gBvvb8CNl408$

---

From: <[email-masked]>
Date: Tue, 23 Feb 2021 14:56:24 +0000

Hi John, all, 

I strongly support this proposal. 

Cheers,
Med

> De : Teas [mailto:[email-masked]] De la part de John E Drake
> Envoyé : mardi 23 février 2021 15:53
> À : BOUCADAIR Mohamed TGI/OLN <[email-masked]>; Joel M.
> Halpern <[email-masked]>; [email-masked]
> Eric and I have reviewed the Definitions draft, the email thread with
> the subject line: Network Slice Endpoint in draft-ietf-teas-ietf-
> network-slice-definition-00, and the RFCs referenced in emails on
> that thread - 3985, 4110, 4026, 4664, and 8309, and we would like to
> propose that in the Definitions draft we replace 'network slice
> endpoint' with 'CE' and 'network slice realization endpoint' with
> 'PE', that we reference  RFCs  3985, 4110, 4026, 4664, and 8309, and
> that we  replace the current figure in Endpoint section with several
> figures, which show connectivity constructs and which are consistent
> with these RFCs.  We would also like to replace 'consumer' with
> 'customer', add 'attachment circuit', and add a new term, viz, 'IETF
> Network Slice Service', whose definition is a set of CEs, a set of
> connectivity constructs (MP2MP, P2MP, P2P, etc.) between subsets of
> these CEs and an SLO for each CE sending to each connectivity
> construct.
> 
> As an aside, the Endpoint section of the Definitions draft uses the
> bulk of its prose enumerating what its endpoints are not.  Per Yakov,
> since there are a potentially infinite number of things which its
> endpoints are not, this is futile and we would like to remove that
> prose.
> 
> Yours Irrespectively,
> 
> Eric and John
> 
> 
> > Subject: Re: [Teas] network Slice Endpoint in
> > As we are on the terminology, I do also suggest that the draft is
> > updated to adhere to RFC8309. Given the recursiveness discussed in
> the
> > draft, having geo- coordinates interfaces is also confusing.
> Inspiring
> > from RFC8309 would make more sense.
> >
> > Cheers,
> > Med
> >
> > > >> The document is not about the request from the external
> customer
> > > (the
> > > >> request for the end-to-end network slice). It is about the
> > > >> request from other orchestration systems to the IETF Network
> > > >> Slice
> > > management
> > > >> systems.
> > > >
> > > >> utilize the IETF network slice.  But the IETF network slice
> does
> > > not
> > > >> need to know about that.
> > > >
> > > >> Network Slice properties, the edge (ingress) that the IETF
> > > >> Network Slice controller controls (and corresponding egress)
> is
> > > >> what needs
> > > to
> > > >> be provisioned.
> > > >
> > > > [Med] I agree that "endpoint" is confusing. "Customer
> Node/Edge"
> > > > vs
> > > "Provider Edge" are my favorite here.
> > > >
> > > >>
> > > >> Yours,
> > > >> Joel
> > > >>
> > > >> characterized by elements not visible to the customer. The
> scope
> > > of a
> > > >>> The mapping between a CE and a network device (typically, a
> PE)
> > > is
> > > >> behaviors may need to be enforced in the CE-PE link. Think
> about
> > > >> a slice that is implemented by means of a PE-based VPN and
> which
> > > > 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.
> >
> not
> > be distributed, used or copied without authorisation.
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/tea
> s
> > __;!!N

---

From: Daniele Ceccarelli <[email-masked]>
Date: Tue, 23 Feb 2021 15:15:24 +0000

Hi all,

Yes, it seems the best way to get out of this vicious circle. 
Strong support from my side as well.

BR
Daniele  

-----Original Message-----
From: Teas <[email-masked]> On Behalf Of [email-masked]
Sent: den 23 februari 2021 15:56
To: John E Drake <jdrake=[email-masked]>; Joel M. Halpern <[email-masked]>; [email-masked]
Subject: Re: [Teas] network Slice Endpoint in draft-ietf-teas-ietf-network-slice-definition-00

Hi John, all, 

Cheers,
Med

> Envoyé : mardi 23 février 2021 15:53 À : BOUCADAIR Mohamed TGI/OLN 
> <[email-masked]>; Joel M.
> Halpern <[email-masked]>; [email-masked] Objet : Re: [Teas] 
> network-slice-definition-00, and the RFCs referenced in emails on that 
> thread - 3985, 4110, 4026, 4664, and 8309, and we would like to 
> https://protect2.fireeye.com/v1/url?k=e71e3448-b8850caa-e71e74d3-86073
> b36ea28-f473e980337d466f&q=1&e=e3970131-6d04-4b1b-bf59-0a8c907c3a46&u=
> https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.ietf.org%2Fmai
> lman%2Flistinfo%2Ftea
> s
> > __;!!N

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.

---

From: Kiran Makhijani <[email-masked]>
Date: Tue, 23 Feb 2021 16:52:44 +0000

Hello:
This does not align with the current document at several levels. We are lost.

I guess suggesting CE/PE looks at these definitions from a provider point of view – ‘what do I need to do to provide this slice?’ But as we continued to refine and ‘snip’ the text (found not useful) – it became more about how user of slice sees it.
At one point customer was replaced with consumer, now we have opposite request (btw, I have no preference). We have covered in the past that service is overused – each technology has its own meaning of service (# of RFCs pointed to). Since we were defining in a tech-agnostic way, the preference is to avoid it.  I see a user of slice saying ‘this is my network’ rather than ‘a service I asked for’. At this time – user is only interacting with a network slice controller – does not know which network provider is going to provide the resources for slices.

If this were an end-to-end slice, PE and CE could make sense. But it is not, the scope of work in IETF network slice can be end-to-end but mainly just a segment. I understand comfort with legacy terms, but I think it is not important here – a lot of effort has gone in making this document stand on its own (again because it is unaware of means of realizing legacy/existing technologies).

When we do the act of ‘realizing’ slices, all these suggestions are spot-on useful. I read first half of draft-bestbar-teas-ns-packet – it is an excellent place for realization or provider-centric type of discussion.

Cheers,
Kiran

From: Teas <[email-masked]> on behalf of John E Drake <jdrake=[email-masked]>
Date: Tuesday, February 23, 2021 at 06:52
To: [email-masked] <[email-masked]>, Joel M. Halpern <[email-masked]>, [email-masked] <[email-masked]>
Subject: Re: [Teas] network Slice Endpoint in draft-ietf-teas-ietf-network-slice-definition-00
Hi,

Yours Irrespectively,

Eric and John

> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteas__%3B!!N&amp;data=04%7C01%7Ckiranm%40futurewei.com%7Ca9aed50bd6fb4368c39408d8d80ab0ca%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637496887761926645%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=faK5qheEwsQhlbRHFuuHkv%2BRl3tgWzp%2FOtiBUNJSFls%3D&amp;reserved=0
_______________________________________________
Teas mailing list
[email-masked]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteas&amp;data=04%7C01%7Ckiranm%40futurewei.com%7Ca9aed50bd6fb4368c39408d8d80ab0ca%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637496887761926645%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=SnXf5%2FZ3IQcyZzOVIi0CDfcwo3bUJWLNKz%2FF6djDl1M%3D&amp;reserved=0

---

From: "Rokui, Reza (Nokia - CA/Ottawa)" <[email-masked]>
Date: Tue, 23 Feb 2021 16:53:15 +0000

All,

In summary I am in agreement for some parts.

Please see a few comments inline.

Reza

On 2021-02-23, 9:52 AM, "Teas on behalf of John E Drake" <[email-masked] on behalf of jdrake=[email-masked]> wrote:

    Hi,

    Eric and I have reviewed the Definitions draft, the email thread with the subject line: Network Slice Endpoint in draft-ietf-teas-ietf-network-slice-definition-00, and the RFCs referenced in emails on that thread - 3985, 4110, 4026, 4664, and 8309, and we would like to propose that in the Definitions draft we replace 'network slice endpoint' with 'CE' and 'network slice realization endpoint' with 'PE', that we reference  RFCs  3985, 4110, 4026, 4664, and 8309,

[Reza] The IETF network slice endpoints (NSE) can  be mapped to some virtual or physical interfaces on CE or PE depends on the use-case. But the  “IETF network slice endpoints” are not CE or PE nodes themselves.

We have added more explanation to draft-wd-teas-ietf-network-slice-nbi-yang-02 figure 4 and 5. This is the summary.

“IETF network slice endpoints (NSE)” are logical entities which can be mapped to interfaces on CE or PE nodes depends on use-case. The following pictures show two use-cases where in one NSE are mapped to interface on PE nodes and in other one NSE are mapped to interface on CE nodes.

              NSE1                                     NSE2
       (With PE1 parameters)                       (with PE2 parameters)
               o<--------- IETF Network Slice 1 ------->o
               +     |                            |     +
               +     |<----------- S1 ----------->|     +
               +     |                            |     +
               +     |    |<------ T1 ------>|    |     +
                 +   v    v                  v    v   +
                   + +----+                  +----+ +
    +-----+    |     | PE1|==================| PE2|          +-----+
    |     |----------X    |                  |    |     |    |     |
    |     |    |     |    |                  |    X----------|     |
    |     |----------X    |                  |    |     |    |     |
    +-----+    |     |    |==================|    |     |    +-----+
               AC    +----+                  +----+     AC
    Customer         Provider                Provider        Customer
    Edge 1           Edge 1                  Edge 2           Edge 2

              NSE3                                     NSE4
       (With CE1 parameters)                       (with CE2 parameters)
               o<--------- IETF Network Slice 2 ------->o
               +     |                            |     +
               +     |<----------- S2 ----------->|     +
               +     |                            |     +
             +       |    |<------ T2 ------>|    |      +
           +         v    v                  v    v        +
         +     AC    +----+                  +----+          +
    +-----+    |     | PE1|==================| PE2|          +-----+
    |     |----------X    |                  |    |     |    |     |
    |     |    |     |    |                  |    X----------|     |
    |     |----------X    |                  |    |     |    |     |
    +-----+    |     |    |==================|    |     |    +-----+
               AC    +----+                  +----+     AC
    Customer         Provider                Provider         Customer
    Edge 1           Edge 1                  Edge 2           Edge 2

  Legend:
       O: Representation of the IETF network slice endpoints (NSE)
       +: Mapping of NES to PE or CE nodes on IETF network
       X: Physical interfaces used for realization of IETF network slice
       S1: L0/L1/L2/L3 services used for realization of IETF network slice
       T1: Tunnels used for realization of IETF network slice

and that we  replace the current figure in Endpoint section with several figures, which show connectivity constructs and which are consistent with these RFCs.

[Reza] It is fine. Please suggest a figure and it can be included in draft

We would also like to replace 'consumer' with 'customer',

[Reza] Fine

add 'attachment circuit', and add a new term, viz, 'IETF Network Slice Service',

[Reza] Why new term? This is what it is called “IETF Network Slice”.

whose definition is a set of CEs, a set of connectivity constructs (MP2MP, P2MP, P2P, etc.) between subsets of these CEs and an SLO for each CE sending to each connectivity construct.

[Reza] which part of draft are you referring?

    Yours Irrespectively,

    Eric and John

    > Subject: Re: [Teas] network Slice Endpoint in draft-ietf-teas-ietf-network-slice-

    > definition-00

    > > >> The document is not about the request from the external customer

    > > >> from other orchestration systems to the IETF Network Slice

    > > >> utilize the IETF network slice.  But the IETF network slice does

    > > >> Slice controller controls (and corresponding egress) is what needs

    > > >> It is possible that on the egress side there needs to be

    > > information

    > > >> in terms of end-points since from the perspective of the IETF

    > > > [Med] I agree that "endpoint" is confusing. "Customer Node/Edge" vs

    > > >> characterized by elements not visible to the customer. The scope

    > > >>> The mapping between a CE and a network device (typically, a PE)

    > 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.

    Teas mailing list

    [email-masked]

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 23 Feb 2021 09:26:46 -0800

Hi John,
thank you and Eric for putting this part in a great concise way. It is now
much simpler and simple, in my opinion, is always the better way.
Yes, I support the proposed update to this WG document.

Regards,
Greg

On Tue, Feb 23, 2021 at 6:52 AM John E Drake <jdrake=
[email-masked]> wrote:

> Hi,
>
> Eric and I have reviewed the Definitions draft, the email thread with the
> subject line: Network Slice Endpoint in
> draft-ietf-teas-ietf-network-slice-definition-00, and the RFCs referenced
> in emails on that thread - 3985, 4110, 4026, 4664, and 8309, and we would
> like to propose that in the Definitions draft we replace 'network slice
> endpoint' with 'CE' and 'network slice realization endpoint' with 'PE',
> that we reference  RFCs  3985, 4110, 4026, 4664, and 8309, and that we
> replace the current figure in Endpoint section with several figures, which
> show connectivity constructs and which are consistent with these RFCs.  We
> would also like to replace 'consumer' with 'customer', add 'attachment
> circuit', and add a new term, viz, 'IETF Network Slice Service', whose
> definition is a set of CEs, a set of connectivity constructs (MP2MP, P2MP,
> P2P, etc.) between subsets of these CEs and an SLO for each CE sending to
> each connectivity construct.
>
> As an aside, the Endpoint section of the Definitions draft uses the bulk
> of its prose enumerating what its endpoints are not.  Per Yakov, since
> there are a potentially infinite number of things which its endpoints are
> not, this is futile and we would like to remove that prose.
>
> Yours Irrespectively,
>
> Eric and John
>
>
> updated to
> exploites ou

---

From: <[email-masked]>
Date: Tue, 23 Feb 2021 17:59:26 +0000

Hi Reza,

It seems that you missed the “attachment circuit” notion in John’s message, which can be mapped to “ep-network-access” in draft-wd-teas-ietf-network-slice-nbi-yang you cited:

   o  "ep-network-access": Is the list that includes the interfaces
      attached to an edge device of the IETF Network Slice by which the
      customer traffic is received.

Things would be much more simple if we say things as we know them:

OLD:
      an edge device of the IETF Network Slice by which the
      customer traffic is received
NEW:
      PE

Cheers,
Med

PS: I was not aware of draft-wd-teas-ietf-network-slice-nbi-yang but I’m really happy that the authors are reusing what we is done in draft-ietf-opsawg-l3sm-l3nm. An import of draft-ietf-opsawg-vpn-common would be logical rather tha defining the roles of the nodes, and so on.

De : Teas [mailto:[email-masked]] De la part de Rokui, Reza (Nokia - CA/Ottawa)
Envoyé : mardi 23 février 2021 17:53
À : John E Drake <jdrake=[email-masked]>; BOUCADAIR Mohamed TGI/OLN <[email-masked]>; Joel M. Halpern <[email-masked]>; [email-masked]
Cc : Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>
Objet : Re: [Teas] network Slice Endpoint in draft-ietf-teas-ietf-network-slice-definition-00

All,

Reza

On 2021-02-23, 9:52 AM, "Teas on behalf of John E Drake" <[email-masked] on behalf of jdrake=[email-masked]<mailto:[email-masked]%20on%20behalf%20of%20jdrake=[email-masked]>> wrote:

    Hi,

              NSE1                                     NSE2

              NSE3                                     NSE4

  Legend:

[Reza] Fine

    Yours Irrespectively,

    Eric and John

    > From: Teas <[email-masked]<mailto:[email-masked]>> On Behalf Of

    > [email-masked]<mailto:[email-masked]>

    > To: Joel M. Halpern <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

    > > <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> Objet : Re: [Teas]

    > > On 2/16/2021 11:39 AM, [email-masked]<mailto:[email-masked]> wrote:

    > > >> Envoyé : mardi 16 février 2021 17:12 À : [email-masked]<mailto:[email-masked]> Objet : Re:

    > > >> On 2/16/2021 11:05 AM, [email-masked]<mailto:[email-masked]> wrote:

    > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;!!N<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!N>

    Teas mailing list

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 23 Feb 2021 13:19:22 -0500

A) I support John and Eric's proposal.
B) You say that you added more explanation in your individual YANG 
draft.  However,t he section you quote does not explain why one would 
want to (much less need to) create the confusion by naming two different 
kinds of things the same way.  Nor why the IETF Network Slice Controller 
would be responsible for provisioning the user of the IETF Network 
Slice.  In short, you did not explain.

Yours,
Joel

On 2/23/2021 11:53 AM, Rokui, Reza (Nokia - CA/Ottawa) wrote:
> On 2021-02-23, 9:52 AM, "Teas on behalf of John E Drake" 
> <[email-masked] on behalf of jdrake=[email-masked]> 
> wrote:
> 
>      Hi,
> 
>      Eric and I have reviewed the Definitions draft, the email thread 
> with the subject line: Network Slice Endpoint in 
> draft-ietf-teas-ietf-network-slice-definition-00, and the RFCs 
> referenced in emails on that thread - 3985, 4110, 4026, 4664, and 8309, 
> and we would like to propose that in the Definitions draft we replace 
> 'network slice endpoint' with 'CE' and 'network slice realization 
> endpoint' with 'PE', that we reference  RFCs  3985, 4110, 4026, 4664, 
> and 8309,
> 
> [Reza] The IETF network slice endpoints (NSE) can  be mapped to some 
> virtual or physical interfaces on CE or PE depends on the use-case. But 
> the  “IETF network slice endpoints” are not CE or PE nodes themselves.
> 
> We have added more explanation to 
> _draft-wd-teas-ietf-network-slice-nbi-yang-02_ figure 4 and 5. This is 
> the summary.
> 
> “IETF network slice endpoints (NSE)” are logical entities which can be 
> mapped to interfaces on CE or PE nodes depends on use-case. The 
> following pictures show two use-cases where in one NSE are mapped to 
> interface on PE nodes and in other one NSE are mapped to interface on CE 
> nodes.
> 
> NSE1                                     NSE2
> 
> and that we  replace the current figure in Endpoint section with several 
> with these RFCs.
> whose definition is a set of CEs, a set of connectivity constructs 
> (MP2MP, P2MP, P2P, etc.) between subsets of these CEs and an SLO for 
> each CE sending to each connectivity construct.
> 
> endpoints are not, this is futile and we would like to remove that prose.
> 
>      > From: Teas <[email-masked]> On Behalf Of
> 
>      > [email-masked]
> 
>      > Sent: Tuesday, February 16, 2021 11:59 AM
> 
>      > To: Joel M. Halpern <[email-masked]>; [email-masked]
> 
>      > Subject: Re: [Teas] network Slice Endpoint in 
> draft-ietf-teas-ietf-network-slice-
> 
>      > definition-00
> 
>      >
> 
>      > [External Email. Be cautious of content]
> 
>      >
> 
>      >
> 
>      > Re-,
> 
>      >
> 
>      > Indeed. That's need to be fixed.
> 
>      >
> 
>      > As we are on the terminology, I do also suggest that the draft is 
> updated to
> 
>      > adhere to RFC8309. Given the recursiveness discussed in the 
> draft, having geo-
> 
>      > coordinates interfaces is also confusing. Inspiring from RFC8309 
> would make
> 
>      > more sense.
> 
>      >
> 
>      > Cheers,
> 
>      > Med
> 
>      >
> 
>      > > -----Message d'origine-----
> 
>      > > De : Joel M. Halpern [mailto:[email-masked]] Envoyé : mardi 16
> 
>      > > février 2021 17:44 À : BOUCADAIR Mohamed TGI/OLN
> 
>      > > <[email-masked]>; [email-masked] Objet : Re: [Teas]
> 
>      > > network Slice Endpoint in draft-ietf-teas-ietf-
> 
>      > > network-slice-definition-00
> 
>      > >
> 
>      > > I would be happy to use CE and PE.  I would also be happy to use
> 
>      > > completely different words.  The current diagram and 
> terminology makes
> 
>      > > this very confusing, and leads to problems.
> 
>      > >
> 
>      > > Yours,
> 
>      > > Joel
> 
>      > >
> 
>      > > On 2/16/2021 11:39 AM, [email-masked] wrote:
> 
>      > > > Re-,
> 
>      > > >
> 
>      > > > Please see inline.
> 
>      > > >
> 
>      > > > Cheers,
> 
>      > > > Med
> 
>      > > >
> 
>      > > >> -----Message d'origine-----
> 
>      > > >> De : Teas [mailto:[email-masked]] De la part de Joel M.
> 
>      > > >> Halpern
> 
>      > > >> Envoyé : mardi 16 février 2021 17:12 À : [email-masked] Objet 
> : Re:
> 
>      > > >> [Teas] network Slice Endpoint in draft-ietf-teas-ietf-
> 
>      > > >> network-slice-definition-00
> 
>      > > >>
> 
>      > > >> The document is not about the request from the external customer
> 
>      > > (the
> 
>      > > >> request for the end-to-end network slice). It is about the 
> request
> 
>      > > >> from other orchestration systems to the IETF Network Slice
> 
>      > > management
> 
>      > > >> systems.
> 
>      > > >
> 
>      > > > [Med] ... which is still behaving as the customer role.
> 
>      > > >
> 
>      > > >   Yes, those systems need to know where they intent to
> 
>      > > >> utilize the IETF network slice.  But the IETF network slice does
> 
>      > > not
> 
>      > > >> need to know about that.
> 
>      > > >
> 
>      > > > [Med] This is what I fail to see. The orchestrator has an 
> internal
> 
>      > > vision that is not available to the entity asking for a slice. 
> These
> 
>      > > nodes are not even known to the "other orchestration systems" when
> 
>      > > asking for a slice.
> 
>      > > >
> 
>      > > >>
> 
>      > > >> In particular, when we get to talking about configuring the IETF
> 
>      > > >> Network Slice properties, the edge (ingress) that the IETF 
> Network
> 
>      > > >> Slice controller controls (and corresponding egress) is what 
> needs
> 
>      > > to
> 
>      > > >> be provisioned.
> 
>      > > >
> 
>      > > > [Med] Agree, but that is a distinct phase.
> 
>      > > >
> 
>      > > > BTW, ingress/egress are as a function of the traffic direction. A
> 
>      > > node (PE) may behave as both ingress and egress for the same slice.
> 
>      > > >
> 
>      > > >> It is possible that on the egress side there needs to be
> 
>      > > information
> 
>      > > >> about how to deliver the traffic externally.
> 
>      > > >
> 
>      > > > [Med] Agree. That node does not need to be visible (known in
> 
>      > > advance) to the entity that will consume the corresponding slice.
> 
>      > > >
> 
>      > > >    But that would not be
> 
>      > > >> in terms of end-points since from the perspective of the IETF
> 
>      > > Network
> 
>      > > >> Slice, on the egress that is not an endpoint of anything.
> 
>      > > >
> 
>      > > > [Med] I agree that "endpoint" is confusing. "Customer 
> Node/Edge" vs
> 
>      > > "Provider Edge" are my favorite here.
> 
>      > > >
> 
>      > > >>
> 
>      > > >> Yours,
> 
>      > > >> Joel
> 
>      > > >>
> 
>      > > >> On 2/16/2021 11:05 AM, [email-masked] wrote:
> 
>      > > >>> Hi Joel,
> 
>      > > >>>
> 
>      > > >>> I disagree with this note. I do think that both flavors of
> 
>      > > >> "endpoint" should be included in the draft.
> 
>      > > >>>
> 
>      > > >>> >From the customer standpoint, a slice request cannot be
> 
>      > > >> characterized by elements not visible to the customer. The scope
> 
>      > > of a
> 
>      > > >> requested slice can only be characterized between nodes that are
> 
>      > > >> known to the requestor. This is usually called, CE.
> 
>      > > >>>
> 
>      > > >>> The mapping between a CE and a network device (typically, a PE)
> 
>      > > is
> 
>      > > >> a process that is internal to the slice provider.
> 
>      > > >>>
> 
>      > > >>> The CE-PE link cannot be systematically excluded as some 
> specific
> 
>      > > >> behaviors may need to be enforced in the CE-PE link. Think 
> about a
> 
>      > > >> slice that is implemented by means of a PE-based VPN and which
> 
>      > > >> requires some specific routing + QoS policies at the CE-PE link.
> 
>      > > >>>
> 
>      > > >>> Cheers,
> 
>      > > >>> Med
> 
>      > > >
> 
>      > > >
> 
>      > > >
> 
>      > >
> 
>      > _________________________________________________________________
> 
>      > ____
> 
>      > > _
> 
>      > > > ___________________________________________________
> 
>      > > >
> 
>      > > > 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.
> 
>      > > >
> 
>      >
> 
>      > _________________________________________________________________
> 
>      > ________________________________________________________
> 
>      >
> 
>      > 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.
> 
>      >
> 
>      > Et6yMaO-gk!TrdpM67-tg4psF0dnG7jBV9LisKHxO_oCNxmQXrJhY-
> 
>      > B6MFchY8gBvvb8CNl408$
>

---

From: "Rokui, Reza (Nokia - CA/Ottawa)" <[email-masked]>
Date: Tue, 23 Feb 2021 19:09:59 +0000

Agreed Med. We can use PE in that context.

Reza

From: "[email-masked]" <[email-masked]>
Date: Tuesday, February 23, 2021 at 12:59 PM
To: Reza Rokui <[email-masked]>, John E Drake <jdrake=[email-masked]>, "Joel M. Halpern" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: [Teas] network Slice Endpoint in draft-ietf-teas-ietf-network-slice-definition-00

Hi Reza,

OLD:

Cheers,
Med

All,

Reza

    Hi,

              NSE1                                     NSE2

              NSE3                                     NSE4

  Legend:

[Reza] Fine

    Yours Irrespectively,

    Eric and John

    Teas mailing list

Thank you.

---

From: Eric Gray <[email-masked]>
Date: Tue, 23 Feb 2021 14:19:55 -0500

Reza,

	Please see in-line responses below…

	Note: I am trying not to repeat responses already made.  If I respond to ay point with a similar response to ay already given, I apologize in advance...

—
Eric

> — [SNIP] ---
>  
> De : Teas [mailto:[email-masked] <mailto:[email-masked]>] De la part de Rokui, Reza (Nokia - CA/Ottawa)
> À : John E Drake <jdrake=[email-masked] <mailto:jdrake=[email-masked]>>; BOUCADAIR Mohamed TGI/OLN <[email-masked] <mailto:[email-masked]>>; Joel M. Halpern <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
> Cc : Rokui, Reza (Nokia - CA/Ottawa) <[email-masked] <mailto:[email-masked]>>
> On 2021-02-23, 9:52 AM, "Teas on behalf of John E Drake" <[email-masked] on behalf of jdrake=[email-masked] <mailto:[email-masked]%20on%20behalf%20of%20jdrake=[email-masked]>> wrote:
>  
>     Hi,
>  

CE and PE components are as capable of being virtual as any component currently included in the draft - hence it might be a littler bit disingenuous to assume that the end points described in the draft cannot be part of a CER or PE, because these are “nodes” (implying physical devices).

If we are defining ed points specifically to justify using new terminology, perhaps we could stop doing that? 

> We have added more explanation to draft-wd-teas-ietf-network-slice-nbi-yang-02 figure 4 and 5. This is the summary.

It is awkward to have a terminology section, or a definition draft, that refers to a modeling draft for explanation of the terms being defined.

>                +     |    |<------ T1 ------>|    |     +

This is not so much a new term as a clarification for the phrase “IETF Network Slice” when applied to a “service interface.”

In order to describe a interface generic enough to be applied in any technology agnostic fashion, we should be defining a “service” interface (as is obvious from the choice to describe this in “service” terms - i.e. - “service level objectives”).

If we use the phrase “IETF Network Slice Service,” it is clearer that we are referring to a “service-based” abstraction of any underlying “IETF Network Slice."

> [Reza] which part of draft are you referring?

I had not thought this to be too subtle to be grasped by any observer that has been following the discussion on end point definitions.

The primary discussion in the draft is in section 4.2 (IETF Network Slice Endpoints).  

However, the term “endpoint” appears quite often and is entirely unclear that there is more than one type of endpoint in almost all cases.  Hence, because we have defined these in a new way, it is as if we need to refer (at least) to section 4.2 each and every time we use the term - and clarify which type of endpoint we are actually using in each case.

If we were clear that we are referring to “IETF Network Slice Service” endpoints, there is a more common term we could use to describe the relationship between the endpoints and the network components where they may occur.  A set of terms that are not only commonly used, but well understood in the industry.

>  — [SNIP] ---

---

From: "Luis M. Contreras" <[email-masked]>
Date: Tue, 23 Feb 2021 23:45:55 +0100

Hi all,

Regarding the CE / PE discussion, I have doubts if this would apply to
scenarios where we could have stitching of IETF Network Slices or in
scenarios where an IETF Network Slice of technology X is supported on  IETF
Network Slice of technology Y. While end-point can work in all the cases, I
think that CE / PE don't become naturally applicable in all cases.

Respect to the discussion on IETF Network Slice Service, I think it is
redundant since we are talking of consumer/customer and provider in the
context of  IETF Network Slice, so being "Service" redundant there.
Probably adds more confusion than clarification.

Best regards

Luis

El mar, 23 feb 2021 a las 20:20, Eric Gray (<[email-masked]>) escribió:

> Reza,
>
> Please see *in-line responses* below…
>
> Note: I am trying not to repeat responses already made.  If I respond to
> ay point with a similar response to ay already given, I apologize in
> advance...
>
> —
> Eric
>
> — [SNIP] ---
>
> *De :* Teas [mailto:[email-masked] <[email-masked]>] *De la
> part de* Rokui, Reza (Nokia - CA/Ottawa)
> *Envoyé :* mardi 23 février 2021 17:53
> *À :* John E Drake <jdrake=[email-masked]>; BOUCADAIR
> Mohamed TGI/OLN <[email-masked]>; Joel M. Halpern <
> [email-masked]>; [email-masked]
> *Cc :* Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>
> *Objet :* Re: [Teas] network Slice Endpoint in
> On 2021-02-23, 9:52 AM, "Teas on behalf of John E Drake" <[email-masked]
> on behalf of jdrake=[email-masked]> wrote:
>
>     Hi,
>
> the subject line: Network Slice Endpoint in
> that we reference  RFCs  3985, 4110, 4026, 4664, and 8309,
>
> virtual or physical interfaces on CE or PE depends on the use-case. But the
>  “IETF network slice endpoints” are not CE or PE nodes themselves.
>
>
> *CE and PE components are as capable of being virtual as any component
> currently included in the **draft - hence it might be a littler bit
> disingenuous to assume that the end points described in the draft cannot be
> part of a CER or PE, because these are “nodes” (implying physical devices).*
>
> *If we are defining ed points specifically
> to justify using new terminology, perhaps we could stop doing that? *
>
> *draft-wd-teas-ietf-network-slice-nbi-yang-02* figure 4 and 5. This is
> the summary.
>
>
> *It is awkward to have a terminology section, or a definition **draft,
> that refers to a modeling draft for explanation of the terms being defined.*
>
>
> mapped to interfaces on CE or PE nodes depends on use-case. The following
> pictures show two use-cases where in one NSE are mapped to interface on PE
> nodes and in other one NSE are mapped to interface on CE nodes.
>
>               NSE1                                     NSE2
> figures, which show connectivity constructs and which are consistent with
> these RFCs.
> *This is not so much a new term as a clarification for the phrase “IETF
> Network Slice” when applied to a “service interface.**”*
>
> *In order to describe a interface generic enough to be applied in any
> technology **agnostic fashion, we should be defining
> a “service” interface (as is obvious from the choice to describe this
> in “service” terms - i.e. - “service level objectives”).*
>
> *If we use the phrase “IETF Network Slice Service,” it is clearer that we
> are referring to a “service-based” abstraction of any underlying “IETF
> Network Slice."*
>
>
> whose definition is a set of CEs, a set of connectivity constructs (MP2MP,
> P2MP, P2P, etc.) between subsets of these CEs and an SLO for each CE
> sending to each connectivity construct.
>
> bulk of its prose enumerating what its endpoints are not.  Per Yakov, since
> *I had not thought this to be too subtle to be grasped by any observer
> that has been following the discussion on end point **definitions.*
>
> *The primary discussion in the draft is in section 4.2 (IETF Network Slice
> Endpoints).  *
>
> *However, the term “endpoint” appears quite often and is entirely unclear
> that there is more than one type of endpoint in almost all cases.  Hence,
> because we have defined these in a new way, it is as if we need to refer
> (at least) to section 4.2 each and every time we use the term - and clarify
> which type of endpoint we are actually using in each case.*
>
> *If we were clear that we are referring to “IETF Network Slice
> Service” endpoints, there is a more common term we could use to describe
> the relationship between the endpoints and the network components where
> they may occur.  A set of terms that are not only commonly used, but well
> understood in the industry.*
>
>
>     Yours Irrespectively,
>
>     Eric and John
>
>  — [SNIP] ---
>

-- 
___________________________________________
Luis M. Contreras
[email-masked]
[email-masked]
Global CTIO unit / Telefonica

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 23 Feb 2021 21:10:19 -0500

We can (easily, and consistently with other IETF use of the term) allow 
for a PE that connects to either a CE or to another operators PE.  The 
point is that the PE are the first / last device in the relevant domain 
that the provider controls to provide the service (in this case, the 
IETF Network Slice).
By assumption in the current definitions and Framework drafts, the 
consumer is a distinct domain.  There also can be, as you say, neighbor 
separate domains.

Yours,
Joel

On 2/23/2021 5:45 PM, Luis M. Contreras wrote:
> scenarios where an IETF Network Slice of technology X is supported on 
> IETF Network Slice of technology Y. While end-point can work in all the 
> cases, I think that CE / PE don't become naturally applicable in all cases.
> 
> El mar, 23 feb 2021 a las 20:20, Eric Gray (<[email-masked] 
> <mailto:[email-masked]>>) escribió:
> 
>     Reza,
> 
>     Please see /*in-line responses*/ below…
> 
>     Note: I am trying not to repeat responses already made.  If I
>     respond to ay point with a similar response to ay already given, I
>     apologize in advance...
> 
>     —
>     Eric
> 
>>     — [SNIP] ---
>>     __ __
>>     *De :*Teas [mailto:[email-masked]
>>     <mailto:[email-masked]>]*De la part de*Rokui, Reza (Nokia -
>>     CA/Ottawa)
>>     *Envoyé :*mardi 23 février 2021 17:53
>>     *À :*John E Drake <jdrake=[email-masked]
>>     <mailto:jdrake=[email-masked]>>; BOUCADAIR Mohamed
>>     TGI/OLN <[email-masked]
>>     <mailto:[email-masked]>>; Joel M. Halpern
>>     <[email-masked] <mailto:[email-masked]>>;[email-masked]
>>     <mailto:[email-masked]>
>>     *Cc :*Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]
>>     <mailto:[email-masked]>>
>>     *Objet :*Re: [Teas] network Slice Endpoint in
>>     draft-ietf-teas-ietf-network-slice-definition-00____
>>     __ __
>>     All,____
>>     __ __
>>     In summary I am in agreement for some parts.____
>>     Please see a few comments inline.____
>>     __ __
>>     Reza____
>>     __ __
>>     __ __
>>     __ __
>>     __ __
>>     <[email-masked] on behalf of
>>     jdrake=[email-masked]
>>     <mailto:[email-masked]%20on%20behalf%20of%20jdrake=[email-masked]>>
>>     wrote:____
>>     __ __
>>         Hi,____
>>     __ __
>>         Eric and I have reviewed the Definitions draft, the email
>>     thread with the subject line: Network Slice Endpoint in
>>     referenced in emails on that thread - 3985, 4110, 4026, 4664, and
>>     8309, and we would like to propose that in the Definitions draft
>>     we replace 'network slice endpoint' with 'CE' and 'network slice
>>     realization endpoint' with 'PE', that we reference  RFCs  3985,
>>     4110, 4026, 4664, and 8309,____
>>     __ __
>>     [Reza] The IETF network slice endpoints (NSE) can  be mapped to
>>     some virtual or physical interfaces on CE or PE depends on the
>>     use-case. But the  “IETF network slice endpoints” are not CE or PE
>>     nodes themselves.
> 
>     */CE and PE components are as capable of being virtual as any
>     component currently included in the /**/draft - hence it might be a
>     littler bit disingenuous to assume that the end points described in
>     //the////draft////cannot// be part of a CER or PE, because these are
>     //“//nodes//”// (implying physical devices)./*
>     */
>     /*
>     */If we are defining ed points specifically to
>     //justify////using////new// terminology, perhaps we could stop
>     //doing// that? /*
> 
>>     ____
>>     We have added more explanation
>>     to_draft-wd-teas-ietf-network-slice-nbi-yang-02_figure 4 and 5.
>>     This is the summary.
> 
>     */It is awkward to have a terminology section, or a definition
>     /**/draft, that refers to a modeling draft for explanation of the
>     terms being defined./*
> 
>>     ____
>>     __ __
>>     “IETF network slice endpoints (NSE)” are logical entities which
>>     can be mapped to interfaces on CE or PE nodes depends on use-case.
>>     The following pictures show two use-cases where in one NSE are
>>     mapped to interface on PE nodes and in other one NSE are mapped to
>>     interface on CE nodes.____
>>     __ __
>>     NSE1                                     NSE2____
>>            (With PE1 parameters)                       (with PE2
>>     parameters)____
>>                    o<--------- IETF Network Slice 1 ------->o____
>>                    +     |                            |     +____
>>                    +     |<----------- S1 ----------->|     +____
>>                    +     |                            |     +____
>>                    +     |    |<------ T1 ------>|    |     +____
>>                      +   v    v                  v    v   +____
>>                        + +----+                  +----+ +____
>>         +-----+    |     | PE1|==================| PE2|         
>>     +-----+____
>>         |     |----------X    |                  |    |     |    |    
>>     |____
>>         |     |    |     |    |                  |    X----------|    
>>     |____
>>         |     |----------X    |                  |    |     |    |    
>>     |____
>>         +-----+    |     |    |==================|    |     |   
>>     +-----+____
>>                    AC    +----+                  +----+     AC____
>>         Customer         Provider                Provider       
>>     Customer____
>>         Edge 1           Edge 1                  Edge 2           Edge
>>     2____
>>     __ __
>>     __ __
>>     __ __
>>     NSE3                                     NSE4____
>>            (With CE1 parameters)                       (with CE2
>>     parameters)____
>>                    o<--------- IETF Network Slice 2 ------->o____
>>                    +     |                            |     +____
>>                    +     |<----------- S2 ----------->|     +____
>>                    +     |                            |     +____
>>                  +       |    |<------ T2 ------>|    |      +____
>>                +         v    v                  v    v        +____
>>              +     AC    +----+                  +----+          +____
>>         +-----+    |     | PE1|==================| PE2|         
>>     +-----+____
>>         |     |----------X    |                  |    |     |    |    
>>     |____
>>         |     |    |     |    |                  |    X----------|    
>>     |____
>>         |     |----------X    |                  |    |     |    |    
>>     |____
>>         +-----+    |     |    |==================|    |     |   
>>     +-----+____
>>                    AC    +----+                  +----+     AC____
>>         Customer         Provider                Provider        
>>     Customer____
>>         Edge 1           Edge 1                  Edge 2           Edge
>>     2____
>>     __ __
>>     __ __
>>       Legend:____
>>            O: Representation of the IETF network slice endpoints (NSE)____
>>            +: Mapping of NES to PE or CE nodes on IETF network____
>>            X: Physical interfaces used for realization of IETF network
>>     slice____
>>            S1: L0/L1/L2/L3 services used for realization of IETF
>>     network slice____
>>            T1: Tunnels used for realization of IETF network slice____
>>     __ __
>>     __ __
>>     and that we  replace the current figure in Endpoint section with
>>     several figures, which show connectivity constructs and which are
>>     consistent with these RFCs. ____
>>     [Reza] It is fine. Please suggest a figure and it can be included
>>     in draft____
>>     __ __
>>     We would also like to replace 'consumer' with 'customer',____
>>     [Reza] Fine____
>>     __ __
>>     add 'attachment circuit', and add a new term, viz, 'IETF Network
>>     Slice Service',____
>     */This is not so much a new term as a clarification for the
>     phrase “IETF Network Slice” when applied to a “service interface./**/”/*
>     */
>     /*
>     */In order to describe a interface generic enough to be applied in
>     any technology /**/agnostic fashion, we should be defining a
>     //“//service//”// interface (as is //obvious// from the choice to
>     describe this in //“//service//”// terms - i.e. - //“service// level
>     objectives//”//)./*
>     */
>     /*
>     */If we use the phrase //“//IETF Network Slice Service,//”// it is
>     clearer that we are referring to a
>     //“//service-based//”// abstraction of any underlying //“//IETF
>     Network Slice."/*
> 
>>     ____
>>     __ __
>>     (MP2MP, P2MP, P2P, etc.) between subsets of these CEs and an SLO
>>     for each CE sending to each connectivity construct.____
>>     __ __
>>         As an aside, the Endpoint section of the Definitions draft
>>     uses the bulk of its prose enumerating what its endpoints are
>>     not.  Per Yakov, since there are a potentially infinite number of
>>     things which its endpoints are not, this is futile and we would
>>     like to remove that prose.____
>     */I had not thought this to be too subtle to be grasped by any
>     observer that has been following the discussion on end point
>     /**/definitions./*
>     */
>     /*
>     */The primary discussion in the draft is in section 4.2 (/_IETF
>     Network Slice Endpoints_/). /*
>     */
>     /*
>     */However, the term //“//endpoint//”// appears //quite// often and
>     is entirely unclear that there is more than one type of endpoint in
>     almost all cases.  Hence, because we have defined these in a new
>     way, it is as if we need to refer (at least) to section 4.2 each and
>     every time we use the term - and clarify which type of endpoint we
>     are actually using in each case./*
>     */
>     /*
>     */If we were clear that we are referring to //“//IETF Network Slice
>     Service//”// endpoints, there is a more common term we could use to
>     describe the relationship between the endpoints and
>     //the////network// components where they may occur.  A set of terms
>     that are not only commonly used, but well understood in the industry./*
> 
>>     ____
>>     __ __
>>         Yours Irrespectively,____
>>     __ __
>>         Eric and John____
>>     __ __
>>     __ — [SNIP] ---__
> [email-masked] <mailto:[email-masked]>
> <mailto:[email-masked]>

---

From: <[email-masked]>
Date: Wed, 24 Feb 2021 06:16:42 +0000

Hi Luis,

Actually, this is all about recursion, service decomposition and manipulating customer/provider ROLES. In all cases, there are reference points delimiting the scope of the slice from both the customer view (we call them, customer edges) and provider view (provider edges).

Nothing prevents that at the realization stage, two PEs can’t be connected. I’m thinking about the example where inter-AS VPN can be used to implement an IETF network slice.

BTW, can you please clarify what do you mean by a “IETF Network Slice of technology X or Y” as slice is technology-agnostic? Thank you.

Cheers,
Med

De : Luis M. Contreras [mailto:[email-masked]]
Envoyé : mardi 23 février 2021 23:46
À : Eric Gray <[email-masked]>
Cc : BOUCADAIR Mohamed TGI/OLN <[email-masked]>; Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>; John E Drake <jdrake=[email-masked]>; [email-masked]; Joel M. Halpern <[email-masked]>
Objet : Re: [Teas] network Slice Endpoint in draft-ietf-teas-ietf-network-slice-definition-00

Hi all,

Regarding the CE / PE discussion, I have doubts if this would apply to scenarios where we could have stitching of IETF Network Slices or in scenarios where an IETF Network Slice of technology X is supported on  IETF Network Slice of technology Y. While end-point can work in all the cases, I think that CE / PE don't become naturally applicable in all cases.

Respect to the discussion on IETF Network Slice Service, I think it is redundant since we are talking of consumer/customer and provider in the context of  IETF Network Slice, so being "Service" redundant there. Probably adds more confusion than clarification.

Best regards

Luis

El mar, 23 feb 2021 a las 20:20, Eric Gray (<[email-masked]<mailto:[email-masked]>>) escribió:
Reza,

—
Eric

— [SNIP] ---

De : Teas [mailto:[email-masked]] De la part de Rokui, Reza (Nokia - CA/Ottawa)
Envoyé : mardi 23 février 2021 17:53
À : John E Drake <jdrake=[email-masked]<mailto:jdrake=[email-masked]>>; BOUCADAIR Mohamed TGI/OLN <[email-masked]<mailto:[email-masked]>>; Joel M. Halpern <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc : Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>>
Objet : Re: [Teas] network Slice Endpoint in draft-ietf-teas-ietf-network-slice-definition-00

All,

Reza

    Hi,

              NSE1                                     NSE2

              NSE3                                     NSE4

  Legend:

    Yours Irrespectively,

    Eric and John

 — [SNIP] ---

--
___________________________________________
Luis M. Contreras
[email-masked]<mailto:[email-masked]>
[email-masked]<mailto:[email-masked]>
Global CTIO unit / Telefonica

---

From: "Luis M. Contreras" <[email-masked]>
Date: Wed, 24 Feb 2021 10:59:57 +0100

Thanks Med and Joel for the answers.

Noting what you said, and assuming that we are covering not only IP/MPLS
technologies, probably we need to associate the same idea of CE and PE to
technologies where those roles are not commonly associated, such as OTN,
DWDM or wireless / microwave, since all of them can be potential targets of
the IETF Network Slicing realization. Then, if we follow this same
rationale and finally the WG decides to go in this direction, I guess we
need to span the CE and PE conception also to those, maybe explaining this
in the definitions draft. Am I right?

Med, when I was referring to IETF Network Slice of technology X or Y I was
thinking on the realization. So my point here is that in case you have an
IETF Network Slice let's say realized as IP/MPLS, and another one let's say
realized on OTN or DWDM, where the IP/MPLS slice is supported by the
OTN/DWDM slice, can we consider that the CE is IP/MPLS and the PE is
OTN/DWDM? It sounds strange to me.

Best regards

Luis

El mié, 24 feb 2021 a las 7:16, <[email-masked]> escribió:

> Hi Luis,
>
>
>
> Actually, this is all about recursion, service decomposition and
> manipulating customer/provider ROLES. In all cases, there are reference
> points delimiting the scope of the slice from both the customer view (we
> call them, customer edges) and provider view (provider edges).
>
>
>
> Nothing prevents that at the realization stage, two PEs can’t be
> connected. I’m thinking about the example where inter-AS VPN can be used to
> implement an IETF network slice.
>
>
>
> BTW, can you please clarify what do you mean by a “IETF Network Slice of
> technology X or Y” as slice is technology-agnostic? Thank you.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* Luis M. Contreras [mailto:[email-masked]]
> *Envoyé :* mardi 23 février 2021 23:46
> *À :* Eric Gray <[email-masked]>
> *Cc :* BOUCADAIR Mohamed TGI/OLN <[email-masked]>; Rokui,
> Reza (Nokia - CA/Ottawa) <[email-masked]>; John E Drake <jdrake=
> [email-masked]>; [email-masked]; Joel M. Halpern <
> [email-masked]>
> on behalf of jdrake=[email-masked]
> <[email-masked]%20on%20behalf%20of%20jdrake=[email-masked]>>
> wrote:
>
>
>
>     Hi,
>
>
>
> currently included in the draft - hence it might be a littler bit
> *It is awkward to have a terminology section, or a definition draft, that
> refers to a modeling draft for explanation of the terms being defined.*
>
>
>
>
>
> Network Slice” when applied to a “service interface.”*
>
>
>
> technology agnostic fashion, we should be defining a “service” interface
> (as is obvious from the choice to describe this in “service” terms - i.e.
> - “service level objectives”).*
>
>
>
> that has been following the discussion on end point definitions.*
>
>
>

---

From: Young Lee <[email-masked]>
Date: Wed, 24 Feb 2021 19:22:07 +0900

Hi,

This is an interesting discussion. I am now in the mobile side and
reconginize that there are a number of scenarios that may need transport
network slices (which is now called IETF network slices). For instance,
possibly slices may be needed in the fronthaul, midhaul and backhaul as
well as within DC networks that host the functions. Other than backhaul
networks, the terms CE and PE may not be adequate because for the
aforementioned transport networks except the backhaul, CE and PE
terminology would not easily apply. For each of the aforementioned
transport subnetworks, I think using slice endpoints makes more sense.

In other words, I agree with Luis on this point.

My two cents,
Young

2021년 2월 24일 (수) 오후 7:00, Luis M. Contreras <[email-masked]>님이 작성:

>> *De :* Teas [mailto:[email-masked] <[email-masked]>] *De
>> la part de* Rokui, Reza (Nokia - CA/Ottawa)
>> (MP2MP, P2MP, P2P, etc.) between subsets of these CEs and an SLO for each
>> CE sending to each connectivity construct.
>>
>>
>>
>> *The primary discussion in the draft is in section 4.2 (IETF Network
>> Slice Endpoints).  *
>>
>>
>>

---

From: <[email-masked]>
Date: Wed, 24 Feb 2021 10:24:26 +0000

Re-,

Please see inline.

Cheers,
Med

De : Luis M. Contreras [mailto:[email-masked]]
Envoyé : mercredi 24 février 2021 11:00
À : BOUCADAIR Mohamed TGI/OLN <[email-masked]>
Cc : Eric Gray <[email-masked]>; Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>; John E Drake <jdrake=[email-masked]>; [email-masked]; Joel M. Halpern <[email-masked]>
Objet : Re: [Teas] network Slice Endpoint in draft-ietf-teas-ietf-network-slice-definition-00

Noting what you said, and assuming that we are covering not only IP/MPLS technologies, probably we need to associate the same idea of CE and PE to technologies where those roles are not commonly associated, such as OTN, DWDM or wireless / microwave, since all of them can be potential targets of the IETF Network Slicing realization. Then, if we follow this same rationale and finally the WG decides to go in this direction, I guess we need to span the CE and PE conception also to those, maybe explaining this in the definitions draft. Am I right?

[Med] Yes. The document can clarify that the CE/PE terms do not assume nor preclude any technology used in the CE-PE link or within the network that hosts the PEs.

Med, when I was referring to IETF Network Slice of technology X or Y I was thinking on the realization.

[Med] OK, thanks. We all agree that part is internal to the slice provider, but I see your point. Even in this case, and from a slice ** service standpoint ** we still have the client/provider roles and the scope of the committed service defined between customer edges/provider edges.

So my point here is that in case you have an IETF Network Slice let's say realized as IP/MPLS, and another one let's say realized on OTN or DWDM, where the IP/MPLS slice is supported by the OTN/DWDM slice, can we consider that the CE is IP/MPLS and the PE is OTN/DWDM? It sounds strange to me.

Best regards

Luis

El mié, 24 feb 2021 a las 7:16, <[email-masked]<mailto:[email-masked]>> escribió:
Hi Luis,

Cheers,
Med

De : Luis M. Contreras [mailto:[email-masked]<mailto:[email-masked]>]
Envoyé : mardi 23 février 2021 23:46
À : Eric Gray <[email-masked]<mailto:[email-masked]>>
Cc : BOUCADAIR Mohamed TGI/OLN <[email-masked]<mailto:[email-masked]>>; Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>>; John E Drake <jdrake=[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Joel M. Halpern <[email-masked]<mailto:[email-masked]>>
Objet : Re: [Teas] network Slice Endpoint in draft-ietf-teas-ietf-network-slice-definition-00

Hi all,

Best regards

Luis

—
Eric

— [SNIP] ---

All,

Reza

    Hi,

              NSE1                                     NSE2

              NSE3                                     NSE4

  Legend:

    Yours Irrespectively,

    Eric and John

 — [SNIP] ---

Thank you.

---

From: Young Lee <[email-masked]>
Date: Wed, 24 Feb 2021 19:27:01 +0900

Sorry. I meant DC networks that host "core network functions".

2021년 2월 24일 (수) 오후 7:22, Young Lee <[email-masked]>님이 작성:

>> Med, when I was referring to IETF Network Slice of technology X or Y I
>> was thinking on the realization. So my point here is that in case you have
>> an IETF Network Slice let's say realized as IP/MPLS, and another one let's
>> say realized on OTN or DWDM, where the IP/MPLS slice is supported by the
>>> BTW, can you please clarify what do you mean by a “IETF Network Slice
>>> of technology X or Y” as slice is technology-agnostic? Thank you.
>>>
>>>
>>>
>>> Cheers,
>>>
>>> Med
>>>
>>>
>>>
>>> *It is awkward to have a terminology section, or a definition draft,
>>> *If we use the phrase “IETF Network Slice Service,” it is clearer that
>>> we are referring to a “service-based” abstraction of any underlying “IETF
>>> Network Slice."*
>>>
>>>
>>>
>>>
>>>
>>> *However, the term “endpoint” appears quite often and is entirely
>>> unclear that there is more than one type of endpoint in almost all cases.
>>> Hence, because we have defined these in a new way, it is as if we need to
>>> refer (at least) to section 4.2 each and every time we use the term - and
>>> clarify which type of endpoint we are actually using in each case.*
>>>
>>>
>>>

---

From: John E Drake <[email-masked]>
Date: Wed, 24 Feb 2021 13:59:37 +0000

Hi,

Please see:  https://tools.ietf.org/html/rfc4364#section-9

Yours Irrespectively,

John

> Sent: Tuesday, February 23, 2021 9:10 PM
> To: Luis M. Contreras <[email-masked]>
> Cc: [email-masked]
> We can (easily, and consistently with other IETF use of the term) allow for a PE
> that connects to either a CE or to another operators PE.  The point is that the PE
> are the first / last device in the relevant domain that the provider controls to
> provide the service (in this case, the IETF Network Slice).
> By assumption in the current definitions and Framework drafts, the consumer is
> a distinct domain.  There also can be, as you say, neighbor separate domains.
> 
> Yours,
> Joel
> 
> > IETF Network Slice of technology Y. While end-point can work in all
> > the cases, I think that CE / PE don't become naturally applicable in all cases.
> >
> > redundant since we are talking of consumer/customer and provider in
> > the context of IETF Network Slice, so being "Service" redundant there.
> >>     <mailto:teas-
> [email-masked]%20on%20behalf%20of%20jdrake=[email-masked].
> org>>
> >>     wrote:____
> >>     __ __
> >>         Hi,____
> >>     __ __
> Et6yMaO-
> gk!R0K1vBmEljR9njyi3BUwu2StTK2Kat8VOEVpNlQLTzJAaCM94ikd0TiX5GG5nho$
> >
> > <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/tea
> > s__;!!NEt6yMaO-
> gk!R0K1vBmEljR9njyi3BUwu2StTK2Kat8VOEVpNlQLTzJAaCM94ikd
> > 0TiX5GG5nho$ >
> >
> >
> >
> > --
> Et6yMaO-
> gk!R0K1vBmEljR9njyi3BUwu2StTK2Kat8VOEVpNlQLTzJAaCM94ikd0TiX5GG5nho$

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 25 Feb 2021 10:51:56 -0000

Hi all, 

Good thread, and really good to see the debate on the WG list.

I’m piling in in response to Young, mainly because that’s the email I happen to have open. But also because the perspective of Young and Luis should be valuable to us in this context.

While I think that the usage of “CE” and “PE” has a long history in packet networks, I don’t believe the concepts are firmly linked only to packet. They are pretty much what they call themselves: the PE is at the edge of the “provider” == “underlay” network, and the CE is at the edge of the “consumer” == “overlay” network. 

I find that, as the discussion continues, we are still missing a really clear figure to help us talk about what we are describing. But Reza’s [1] is a much better start than anything previous. Here I see the classic distinction between a CE-based VPN and a PE-based VPN [2], but we have to ask ourselves carefully whether we *really* want the CE-based approach in our network slicing:

*	What are the considerations for how much knowledge of the underlay network has to be shared to the CE?
*	What are the considerations for how an underlay distinguishes CE-originated slicing traffic?

These are pretty much the same questions that CE-based VPNs have to answer. Of course, the concept of a “provider-managed CE” muddies these waters somewhat.

Conversely, the port-based PE-based VPN has none of these problems, but does have to agree on the “Access Connection” encoding, and that is either payload-sensitive (like in PWE3) or technology-aware (like in L3VPN).

But my opinion of all of this is coloured by thinking about enhanced VPNs (VPN+) [3] and IETF network slices as the same thing.

I also think that Luis’ point about contiguous or stitched segments is important. There are, I think, two cases to be considered:

1.	The multi-domain IETF network slice. Here the problem is very much the same as the multi-AS L3VPN. We have to consider how the “service request” is mapped from one domain to another. But it may help to recall that, for all our dreaming, end-to-end multi-AS MPLS-TE tunnels are not much of a thing: domains don’t like sharing information about or control of their network resources. Thus the “E-NNI” between slice domains may be as much of a service interface as the “UNI” between consumer and provider.
2.	The 5G architecture considers stitching slices from different technology networks to provide an end-to-end slice. From a consumer’s point of view, this is exactly what happens, but it is not clear to me whether this is really what happens in a deployment. Surely there is aggregation as we go down the technology layers and into the “transport” networks. That is, there may be very, very many micro slices in the RAN, but as this moves onto the IP transport, it is likely that the slicing is aggregated. That means that the stitching of slices actually follows a hierarchical model with recursion. The interface between slice domains is the “UNI”.

Net-net, I like John’s original proposal. I hope we can take that as our base point and factor in further discussions.

Best,

Adrian

[1] https://mailarchive.ietf.org/arch/msg/teas/ibycGzi5cxJUJSvRxm9OsQdDqn8/

[2] RFC 4026

[3] draft-ietf-teas-enhanced-vpn

From: Teas <[email-masked]> On Behalf Of Young Lee
Sent: 24 February 2021 10:22
To: Luis M. Contreras <[email-masked]>
Cc: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>; [email-masked]; Eric Gray <[email-masked]>; John E Drake <jdrake=[email-masked]>; Joel M. Halpern <[email-masked]>; [email-masked]
Subject: Re: [Teas] network Slice Endpoint in draft-ietf-teas-ietf-network-slice-definition-00

Hi,

This is an interesting discussion. I am now in the mobile side and reconginize that there are a number of scenarios that may need transport network slices (which is now called IETF network slices). For instance, possibly slices may be needed in the fronthaul, midhaul and backhaul as well as within DC networks that host the functions. Other than backhaul networks, the terms CE and PE may not be adequate because for the aforementioned transport networks except the backhaul, CE and PE terminology would not easily apply. For each of the aforementioned transport subnetworks, I think using slice endpoints makes more sense. 

My two cents,

Young 

2021년 2월 24일 (수) 오후 7:00, Luis M. Contreras <[email-masked] <mailto:[email-masked]> >님이 작성:

Med, when I was referring to IETF Network Slice of technology X or Y I was thinking on the realization. So my point here is that in case you have an IETF Network Slice let's say realized as IP/MPLS, and another one let's say realized on OTN or DWDM, where the IP/MPLS slice is supported by the OTN/DWDM slice, can we consider that the CE is IP/MPLS and the PE is OTN/DWDM? It sounds strange to me.

Best regards

Luis

El mié, 24 feb 2021 a las 7:16, <[email-masked] <mailto:[email-masked]> > escribió:

Hi Luis, 

Cheers,

Med

De : Luis M. Contreras [mailto:[email-masked] <mailto:[email-masked]> ] 
Envoyé : mardi 23 février 2021 23:46
À : Eric Gray <[email-masked] <mailto:[email-masked]> >
Cc : BOUCADAIR Mohamed TGI/OLN <[email-masked] <mailto:[email-masked]> >; Rokui, Reza (Nokia - CA/Ottawa) <[email-masked] <mailto:[email-masked]> >; John E Drake <jdrake=[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> ; Joel M. Halpern <[email-masked] <mailto:[email-masked]> >
Objet : Re: [Teas] network Slice Endpoint in draft-ietf-teas-ietf-network-slice-definition-00

Hi all,

Best regards

Luis

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Fri, 26 Feb 2021 07:14:34 +0000

Hi,

Indeed good discussion about the terms, and thanks to Adrian for the explanation and summary of the PE-based and CE-based VPNs.

In the two figures provided in [1], the realization of IETF network slice in both the service layer and the tunnel layer are the same, the only difference is the position the NSE represents.

Thus I also support the proposal of using the well-known terms CE/PE to describe the endpoints of IETF network slice.  This could help to reduce the possible confusions caused by using one term to represent different positions. This could also help to understand the mapping from IETF network slice requirements to its realization, which could be based on the architecture and technologies described in the enhanced VPN draft [3].

Best regards,
Jie

From: Teas [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Thursday, February 25, 2021 6:52 PM
To: 'Young Lee' <[email-masked]>; 'Luis M. Contreras' <[email-masked]>
Cc: 'Joel M. Halpern' <[email-masked]>; [email-masked]; 'Eric Gray' <[email-masked]>; 'John E Drake' <jdrake=[email-masked]>; 'Rokui, Reza (Nokia - CA/Ottawa)' <[email-masked]>; [email-masked]
Subject: Re: [Teas] network Slice Endpoint in draft-ietf-teas-ietf-network-slice-definition-00

Hi all,

I find that, as the discussion continues, we are still missing a really clear figure to help us talk about what we are describing. But Reza’s [1] is a much better start than anything previous. Here I see the classic distinction between a CE-based VPN and a PE-based VPN [2], but we have to ask ourselves carefully whether we *really* want the CE-based approach in our network slicing:
-          What are the considerations for how much knowledge of the underlay network has to be shared to the CE?
-          What are the considerations for how an underlay distinguishes CE-originated slicing traffic?
These are pretty much the same questions that CE-based VPNs have to answer. Of course, the concept of a “provider-managed CE” muddies these waters somewhat.

Best,
Adrian

From: Teas <[email-masked]<mailto:[email-masked]>> On Behalf Of Young Lee
Sent: 24 February 2021 10:22
To: Luis M. Contreras <[email-masked]<mailto:[email-masked]>>
Cc: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Eric Gray <[email-masked]<mailto:[email-masked]>>; John E Drake <jdrake=[email-masked]<mailto:jdrake=[email-masked]>>; Joel M. Halpern <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Teas] network Slice Endpoint in draft-ietf-teas-ietf-network-slice-definition-00

Hi,

My two cents,
Young

2021년 2월 24일 (수) 오후 7:00, Luis M. Contreras <[email-masked]<mailto:[email-masked]>>님이 작성:
Thanks Med and Joel for the answers.

Best regards

Luis

Cheers,
Med

Hi all,

Best regards

Luis

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 26 Feb 2021 19:42:47 -0500

This is an interesting discussion.

I understand their is a paradigm shift with Enhanced VPN  network slicing
framework, however I think as John and Eric stated and I agree with their
proposed update that “CE” replace “Network slice endpoint” and PE replace
“Network Slice Realization Endpoint”.

>From an industry  perspective from an operators point of view,  I can see
that maybe the Network slicing paradigm shift is being driven by 5G which
has its key constructs of XHaul front back and mid haul vRAN and the mobile
handset UE 3GPP user data plane and how much the CE is now aware of the
underlay.

As Adrian pointed out the CE based VPN versus PE based VPNs and the trade
off for operators with CE based VPNs and how much knowledge are operators
willing to give their customers about the underlay.

As we all know that even though 5G is the industry driver of network
slicing, the framework of network slicing as far as degree of isolation and
steering is all based on the very overlay VPN concept now enhanced VPN+ to
provide an improved user or SLA experience.   So the concept of network
slicing  underpinned of overlay VPN with underlay resources and steering
can be used for any use case with requirements of a higher grade SLA and
not just 5G , such as DETNET or any content provider video streaming
service offering or any service requiring a higher degree of isolation.

Their are definitely trade off from an economics and value added service
and ROI perspective  for CE versus PE based VPNs.

Another point noted in this thread which I think is important and that is
“confusion” related to changing the historical PE / CE terminology.

That being said I do agree with John and Eric on their proposed change.

Kind Regards

Gyan

On Fri, Feb 26, 2021 at 2:14 AM Dongjie (Jimmy) <[email-masked]> wrote:

> Hi,
>
>
>
> Indeed good discussion about the terms, and thanks to Adrian for the
> explanation and summary of the PE-based and CE-based VPNs.
>
>
>
> In the two figures provided in [1], the realization of IETF network slice
> in both the service layer and the tunnel layer are the same, the only
> difference is the position the NSE represents.
>
>
>
> Thus I also support the proposal of using the well-known terms CE/PE to
> describe the endpoints of IETF network slice.  This could help to reduce
> the possible confusions caused by using one term to represent different
> positions. This could also help to understand the mapping from IETF network
> slice requirements to its realization, which could be based on the
> architecture and technologies described in the enhanced VPN draft [3].
>
>
>
> Best regards,
>
> Jie
>
>
>
> *From:* Teas [mailto:[email-masked]] *On Behalf Of *Adrian Farrel
> *Sent:* Thursday, February 25, 2021 6:52 PM
> *To:* 'Young Lee' <[email-masked]>; 'Luis M. Contreras' <
> [email-masked]>
> *Cc:* 'Joel M. Halpern' <[email-masked]>; [email-masked]; 'Eric Gray'
> <[email-masked]>; 'John E Drake' <jdrake=[email-masked]>;
> 'Rokui, Reza (Nokia - CA/Ottawa)' <[email-masked]>;
> I’m piling in in response to Young, mainly because that’s the email I
> happen to have open. But also because the perspective of Young and Luis
> should be valuable to us in this context.
>
>
>
> While I think that the usage of “CE” and “PE” has a long history in packet
> networks, I don’t believe the concepts are firmly linked only to packet.
> They are pretty much what they call themselves: the PE is at the edge of
> the “provider” == “underlay” network, and the CE is at the edge of the
> “consumer” == “overlay” network.
>
>
>
> I find that, as the discussion continues, we are still missing a really
> clear figure to help us talk about what we are describing. But Reza’s [1]
> is a much better start than anything previous. Here I see the classic
> distinction between a CE-based VPN and a PE-based VPN [2], but we have to
> ask ourselves carefully whether we **really** want the CE-based approach
> in our network slicing:
>
> -          What are the considerations for how much knowledge of the
> underlay network has to be shared to the CE?
>
> These are pretty much the same questions that CE-based VPNs have to
> answer. Of course, the concept of a “provider-managed CE” muddies these
> waters somewhat.
>
>
>
> Conversely, the port-based PE-based VPN has none of these problems, but
> does have to agree on the “Access Connection” encoding, and that is either
> payload-sensitive (like in PWE3) or technology-aware (like in L3VPN).
>
>
>
> But my opinion of all of this is coloured by thinking about enhanced VPNs
> (VPN+) [3] and IETF network slices as the same thing.
>
>
>
> I also think that Luis’ point about contiguous or stitched segments is
> important. There are, I think, two cases to be considered:
>
>    1. The multi-domain IETF network slice. Here the problem is very much
>    the same as the multi-AS L3VPN. We have to consider how the “service
>    request” is mapped from one domain to another. But it may help to recall
>    that, for all our dreaming, end-to-end multi-AS MPLS-TE tunnels are not
>    much of a thing: domains don’t like sharing information about or control of
>    their network resources. Thus the “E-NNI” between slice domains may be as
>    much of a service interface as the “UNI” between consumer and provider.
>    2. The 5G architecture considers stitching slices from different
>    technology networks to provide an end-to-end slice. From a consumer’s point
>    of view, this is exactly what happens, but it is not clear to me whether
>    this is really what happens in a deployment. Surely there is aggregation as
>    we go down the technology layers and into the “transport” networks. That
>    is, there may be very, very many micro slices in the RAN, but as this moves
>    onto the IP transport, it is likely that the slicing is aggregated. That
>    means that the stitching of slices actually follows a hierarchical model
>    with recursion. The interface between slice domains is the “UNI”.
>
>
>
> Net-net, I like John’s original proposal. I hope we can take that as our
> base point and factor in further discussions.
>
>
>
> Best,
>
> Adrian
>
>
>
> [1]
> https://mailarchive.ietf.org/arch/msg/teas/ibycGzi5cxJUJSvRxm9OsQdDqn8/
>
> [2] RFC 4026
>
> *From:* Teas <[email-masked]> *On Behalf Of *Young Lee
> *Sent:* 24 February 2021 10:22
> *To:* Luis M. Contreras <[email-masked]>
> *Cc:* Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>;
> [email-masked]; Eric Gray <[email-masked]>; John E Drake <
> jdrake=[email-masked]>; Joel M. Halpern <[email-masked]>;
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*M 301 502-134713101 Columbia Pike *Silver Spring, MD

---

From: Shunsuke Homma <[email-masked]>
Date: Sat, 27 Feb 2021 13:59:09 +0900

I'm wondering if CE/PE can cover all cases.

For example, can SFC CF/SFF (ref. RFC 7665) or Geneve tunnel endpoint/NVE
(ref. RFC8926)  put the internal of a provider network be an endpoint of
IETF network slice? And if so, can we call them CE or PE?

Regards,

Shunsuke

On Sat, Feb 27, 2021 at 9:43 AM Gyan Mishra <[email-masked]> wrote:

>> *Cc:* 'Joel M. Halpern' <[email-masked]>; [email-masked]; 'Eric
>> Gray' <[email-masked]>; 'John E Drake' <jdrake=
>> [email-masked]>; 'Rokui, Reza (Nokia - CA/Ottawa)' <
>> [email-masked]>; [email-masked]
>> While I think that the usage of “CE” and “PE” has a long history in
>> packet networks, I don’t believe the concepts are firmly linked only to
>> packet. They are pretty much what they call themselves: the PE is at the
>> edge of the “provider” == “underlay” network, and the CE is at the edge of
>> the “consumer” == “overlay” network.
>>
>>
>>
>> jdrake=[email-masked]>; Joel M. Halpern <
>> [email-masked]>; [email-masked]

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 27 Feb 2021 00:18:39 -0500

The ingress classifier for SFC can clearly be a PE router.  In fact, 
that is a typical case.

I would also expect for most tunnel technologies including Geneve that 
the ingress tunnel rotuer can be a PE.

Yours,
Joel

On 2/26/2021 11:59 PM, Shunsuke Homma wrote:
> For example, can SFC CF/SFF (ref. RFC 7665) or Geneve tunnel 
> endpoint/NVE (ref. RFC8926)  put the internal of a provider network be 
> an endpoint of IETF network slice? And if so, can we call them CE or PE?
> 
> Regards,
> 
> Shunsuke
> 
> On Sat, Feb 27, 2021 at 9:43 AM Gyan Mishra <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> 
>     I understand their is a paradigm shift with Enhanced VPN  network
>     slicing framework, however I think as John and Eric stated and I
>     agree with their proposed update that “CE” replace “Network slice
>     endpoint” and PE replace “Network Slice Realization Endpoint”.
> 
>      From an industry  perspective from an operators point of view,  I
>     can see that maybe the Network slicing paradigm shift is being
>     driven by 5G which has its key constructs of XHaul front back and
>     mid haul vRAN and the mobile handset UE 3GPP user data plane and how
>     much the CE is now aware of the underlay.
> 
>     As Adrian pointed out the CE based VPN versus PE based VPNs and the
>     trade off for operators with CE based VPNs and how much knowledge
>     are operators willing to give their customers about the underlay.
> 
>     slicing, the framework of network slicing as far as degree of
>     isolation and steering is all based on the very overlay VPN concept
>     now enhanced VPN+ to provide an improved user or SLA experience.  
>     So the concept of network slicing  underpinned of overlay VPN with
>     underlay resources and steering can be used for any use case with
>     requirements of a higher grade SLA and not just 5G , such as DETNET
>     or any content provider video streaming service offering or any
>     service requiring a higher degree of isolation.
> 
>     Their are definitely trade off from an economics and value added
>     service and ROI perspective  for CE versus PE based VPNs.
> 
>     Another point noted in this thread which I think is important and
>     that is “confusion” related to changing the historical PE / CE
>     terminology.
> 
>     On Fri, Feb 26, 2021 at 2:14 AM Dongjie (Jimmy) <[email-masked]
>     <mailto:[email-masked]>> wrote:
> 
>         Hi, ____
> 
>         __ __
> 
>         Indeed good discussion about the terms, and thanks to Adrian for
>         the explanation and summary of the PE-based and CE-based VPNs. ____
> 
>         __ __
> 
>         In the two figures provided in [1], the realization of IETF
>         network slice in both the service layer and the tunnel layer are
>         the same, the only difference is the position the NSE
>         represents.____
> 
>         __ __
> 
>         Thus I also support the proposal of using the well-known terms
>         CE/PE to describe the endpoints of IETF network slice.  This
>         could help to reduce the possible confusions caused by using one
>         term to represent different positions. This could also help to
>         understand the mapping from IETF network slice requirements to
>         its realization, which could be based on the architecture and
>         technologies described in the enhanced VPN draft [3].____
> 
>         __ __
> 
>         Best regards,____
> 
>         Jie____
> 
>         __ __
> 
>         *From:*Teas [mailto:[email-masked]
>         <mailto:[email-masked]>] *On Behalf Of *Adrian Farrel
>         *To:* 'Young Lee' <[email-masked]
>         <mailto:[email-masked]>>; 'Luis M. Contreras'
>         <[email-masked] <mailto:[email-masked]>>
>         *Cc:* 'Joel M. Halpern' <[email-masked]
>         <mailto:[email-masked]>>; [email-masked]
>         <mailto:[email-masked]>; 'Eric Gray' <[email-masked]
>         <mailto:[email-masked]>>; 'John E Drake'
>         <jdrake=[email-masked]
>         <mailto:[email-masked]>>; 'Rokui, Reza (Nokia -
>         CA/Ottawa)' <[email-masked]
>         <mailto:[email-masked]>>; [email-masked]
>         <mailto:[email-masked]>
>         Hi all, ____
>         Good thread, and really good to see the debate on the WG list.____
> 
>         __ __
> 
>         I’m piling in in response to Young, mainly because that’s the
>         email I happen to have open. But also because the perspective of
>         Young and Luis should be valuable to us in this context.____
> 
>         __ __
> 
>         While I think that the usage of “CE” and “PE” has a long history
>         in packet networks, I don’t believe the concepts are firmly
>         linked only to packet. They are pretty much what they call
>         themselves: the PE is at the edge of the “provider” ==
>         “underlay” network, and the CE is at the edge of the “consumer”
>         == “overlay” network. ____
> 
>         __ __
> 
>         I find that, as the discussion continues, we are still missing a
>         really clear figure to help us talk about what we are
>         describing. But Reza’s [1] is a much better start than anything
>         previous. Here I see the classic distinction between a CE-based
>         VPN and a PE-based VPN [2], but we have to ask ourselves
>         carefully whether we **really** want the CE-based approach in
>         our network slicing:____
> 
>         __-__What are the considerations for how much knowledge of the
>         underlay network has to be shared to the CE?____
> 
>         __-__What are the considerations for how an underlay
>         distinguishes CE-originated slicing traffic?____
> 
>         These are pretty much the same questions that CE-based VPNs have
>         to answer. Of course, the concept of a “provider-managed CE”
>         muddies these waters somewhat.____
> 
>         __ __
> 
>         Conversely, the port-based PE-based VPN has none of these
>         problems, but does have to agree on the “Access Connection”
>         encoding, and that is either payload-sensitive (like in PWE3) or
>         technology-aware (like in L3VPN).____
> 
>         __ __
> 
>         But my opinion of all of this is coloured by thinking about
>         enhanced VPNs (VPN+) [3] and IETF network slices as the same
>         thing.____
> 
>         __ __
> 
>         I also think that Luis’ point about contiguous or stitched
>         segments is important. There are, I think, two cases to be
>         considered:____
> 
>          1. The multi-domain IETF network slice. Here the problem is
>             very much the same as the multi-AS L3VPN. We have to
>             consider how the “service request” is mapped from one domain
>             to another. But it may help to recall that, for all our
>             dreaming, end-to-end multi-AS MPLS-TE tunnels are not much
>             of a thing: domains don’t like sharing information about or
>             control of their network resources. Thus the “E-NNI” between
>             slice domains may be as much of a service interface as the
>             “UNI” between consumer and provider.____
>          2. The 5G architecture considers stitching slices from
>             different technology networks to provide an end-to-end
>             slice. From a consumer’s point of view, this is exactly what
>             happens, but it is not clear to me whether this is really
>             what happens in a deployment. Surely there is aggregation as
>             we go down the technology layers and into the “transport”
>             networks. That is, there may be very, very many micro slices
>             in the RAN, but as this moves onto the IP transport, it is
>             likely that the slicing is aggregated. That means that the
>             stitching of slices actually follows a hierarchical model
>             with recursion. The interface between slice domains is the
>             “UNI”.____
> 
>         __ __
> 
>         Net-net, I like John’s original proposal. I hope we can take
>         that as our base point and factor in further discussions.____
> 
>         __ __
> 
>         Best,____
> 
>         Adrian____
> 
>         __ __
> 
>         [1]
>         <https://mailarchive.ietf.org/arch/msg/teas/ibycGzi5cxJUJSvRxm9OsQdDqn8/>____
> 
>         [2] RFC 4026____
> 
>         [3] draft-ietf-teas-enhanced-vpn____
> 
>         __ __
> 
>         *From:*Teas <[email-masked]
>         <mailto:[email-masked]>> *On Behalf Of *Young Lee
>         *To:* Luis M. Contreras <[email-masked]
>         <mailto:[email-masked]>>
>         *Cc:* Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]
>         <mailto:[email-masked]>>; [email-masked]
>         <mailto:[email-masked]>; Eric Gray <[email-masked]
>         <mailto:[email-masked]>>; John E Drake
>         <jdrake=[email-masked]
>         <mailto:jdrake=[email-masked]>>; Joel M. Halpern
>         <[email-masked] <mailto:[email-masked]>>;
>         [email-masked] <mailto:[email-masked]>
>         This is an interesting discussion. I am now in the mobile side
>         and reconginize that there are a number of scenarios that may
>         need transport network slices (which is now called IETF network
>         slices). For instance, possibly slices may be needed in the
>         fronthaul, midhaul and backhaul as well as within DC networks
>         that host the functions. Other than backhaul networks, the terms
>         CE and PE may not be adequate because for the aforementioned
>         transport networks except the backhaul, CE and PE terminology
>         would not easily apply. For each of the aforementioned transport
>         subnetworks, I think using slice endpoints makes more sense. ____
> 
>         __ __
> 
>         In other words, I agree with Luis on this point. ____
> 
>         __ __
> 
>         My two cents,____
> 
>         Young ____
> 
>         __ __
> 
>         2021년2월24일(수) 오후7:00, Luis M. Contreras
>         <[email-masked] <mailto:[email-masked]>>님이
>         작성:____
> 
>             Thanks Med and Joel for the answers.____
> 
>             __ __
> 
>             Noting what you said, and assuming that we are covering not
>             only IP/MPLS technologies, probably we need to associate the
>             same idea of CE and PE to technologies where those roles are
>             not commonly associated, such as OTN, DWDM or wireless /
>             microwave, since all of them can be potential targets of the
>             IETF Network Slicing realization. Then, if we follow this
>             same rationale and finally the WG decides to go in this
>             direction, I guess we need to span the CE and PE conception
>             also to those, maybe explaining this in the definitions
>             draft. Am I right?____
> 
>             __ __
> 
>             Med, when I was referring to IETF Network Slice of
>             technology X or Y I was thinking on the realization. So my
>             point here is that in case you have an IETF Network Slice
>             let's say realized as IP/MPLS, and another one let's say
>             realized on OTN or DWDM, where the IP/MPLS slice is
>             supported by the OTN/DWDM slice, can we consider that the CE
>             is IP/MPLS and the PE is OTN/DWDM? It sounds strange to me.____
> 
>             __ __
> 
>             Best regards____
> 
>             __ __
> 
>             Luis____
> 
>             __ __
> 
>             __ __
> 
>             El mié, 24 feb 2021 a las 7:16,
>             <[email-masked]
>             <mailto:[email-masked]>> escribió:____
> 
>                 Hi Luis, ____
> 
>                 ____
> 
>                 Actually, this is all about recursion, service
>                 decomposition and manipulating customer/provider ROLES.
>                 In all cases, there are reference points delimiting the
>                 scope of the slice from both the customer view (we call
>                 them, customer edges) and provider view (provider
>                 edges). ____
> 
>                 ____
> 
>                 Nothing prevents that at the realization stage, two PEs
>                 can’t be connected. I’m thinking about the example where
>                 inter-AS VPN can be used to implement an IETF network
>                 slice.____
> 
>                 ____
> 
>                 BTW, can you please clarify what do you mean by a “IETF
>                 Network Slice of technology X or Y” as slice is
>                 technology-agnostic? Thank you.____
> 
>                 ____
> 
>                 Cheers,____
> 
>                 Med____
> 
>                 ____
> 
>                 *De :*Luis M. Contreras [mailto:[email-masked]
>                 <mailto:[email-masked]>]
>                 *À :* Eric Gray <[email-masked]
>                 <mailto:[email-masked]>>
>                 *Cc :* BOUCADAIR Mohamed TGI/OLN
>                 <[email-masked]
>                 <mailto:[email-masked]>>; Rokui, Reza
>                 (Nokia - CA/Ottawa) <[email-masked]
>                 <mailto:[email-masked]>>; John E Drake
>                 <jdrake=[email-masked]
>                 <mailto:[email-masked]>>; [email-masked]
>                 <mailto:[email-masked]>; Joel M. Halpern
>                 <[email-masked] <mailto:[email-masked]>>
>                 Hi all,____
>                 Regarding the CE / PE discussion, I have doubts if this
>                 would apply to scenarios where we could have
>                 stitching of IETF Network Slices or in scenarios where
>                 an IETF Network Slice of technology X is supported on 
>                 IETF Network Slice of technology Y. While end-point can
>                 work in all the cases, I think that CE / PE don't become
>                 naturally applicable in all cases.____
> 
>                 ____
> 
>                 Respect to the discussion on IETF Network Slice Service,
>                 I think it is redundant since we are talking of
>                 consumer/customer and provider in the context of  IETF
>                 Network Slice, so being "Service" redundant there.
>                 Probably adds more confusion than clarification.____
> 
>                 ____
> 
>                 Best regards____
> 
>                 ____
> 
>                 Luis____
> 
>     /Network Solutions A//rchitect /
> 
>     /M 301 502-1347
>     13101 Columbia Pike
>     /Silver Spring, MD
> 
>

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 27 Feb 2021 01:21:30 -0500

I agree that the PE / CE nomenclature can be used for any scenario where
their is a customer handoff “demarcation” and only in those cases can apply
the network slicing endpoint concept.

Access - wireline/wireless
Wireline
MPLS/SR core VPN overlay - typical PE-CE demark

MPLS/SR inter-as provider handoffs

Wireless - RAN xHaul - 3GPP gateway to UE - fixed or mobile wireless 4G/5G
-  UE to Gateway is the handoff point

OTN-
OTN GMPLS/MPLS-TP packet core - typically that is the operators
infrastructure and so no customer handoff.

Data Center-
Data Center - typically no customer handoff
Typical DC flavors -
CLOS architecture BGP only DC
NVO3 - leaf/spine - vxlan/nvgre/geneve

Cloud - IAAS infrastructure as a service so no handoff

Content provider- no handoff

Web or content hosting - also no handoff paid for service offering

So in summary the only two scenarios where you have a customer handoff is
the operator access layer wireline and wireless above.

So I think the PE / CE nomenclature fits the bill even with the network
slicing paradigm shift.

Kind Regards

Gyan

On Fri, Feb 26, 2021 at 11:59 PM Shunsuke Homma <
[email-masked]> wrote:

>>> In the two figures provided in [1], the realization of IETF network
>>> slice in both the service layer and the tunnel layer are the same, the only
>>> ask ourselves carefully whether we **really** want the CE-based
>>> approach in our network slicing:
>>>
>>> -          What are the considerations for how an underlay
>>> distinguishes CE-originated slicing traffic?
>>>
>>> But my opinion of all of this is coloured by thinking about enhanced
>>> VPNs (VPN+) [3] and IETF network slices as the same thing.
>>>
>>>
>>>
>>>    1. The multi-domain IETF network slice. Here the problem is very
>>>    much the same as the multi-AS L3VPN. We have to consider how the “service
>> *M 301 502-134713101 Columbia Pike
>> <https://www.google.com/maps/search/13101+Columbia+Pike?entry=gmail&source=g> *Silver
>> Spring, MD
>>

*Gyan Mishra*

---

From: Shunsuke Homma <[email-masked]>
Date: Sat, 27 Feb 2021 16:00:54 +0900

Thanks, Joel and Gyan.

Yes, I agree that SFC classifier or tunnel endpoint can be a PE router.
Meanwhile, I assume there are cases that CF/VNE runs on non-PE/CE router.
For example, in case that SFC is performed within the provider's DC (e.g.,
5G DN), the ingress GW or ToR switch will be a classifier. Then, the GW/ToR
can be called CE or PE?

Certainly, in MPLS world, MPLS termination point is conventionally called
PE, but I feel PE/CE may not be generally used in DC or any other field.
Actually, Geneve termination point is called tunnel endpoint, and VxLAN
also use VTEP (VxLAN Tunnel End Point), not CE/PE. (Sorry if my
understanding is incorrect...)

If PE/CE are conceptual entities and can be applied to any cases, not only
MPLS(SR) networks, I assume that NSE and PE/CE are the same. Whichever is
fine to me.

Regards,

Shunsuke

On Sat, Feb 27, 2021 at 3:21 PM Gyan Mishra <[email-masked]> wrote:

>>> slicing framework, however I think as John and Eric stated and I agree with
>>> their proposed update that “CE” replace “Network slice endpoint” and PE
>>> replace “Network Slice Realization Endpoint”.
>>>
>>> From an industry  perspective from an operators point of view,  I can
>>> see that maybe the Network slicing paradigm shift is being driven by 5G
>>> which has its key constructs of XHaul front back and mid haul vRAN and the
>>> mobile handset UE 3GPP user data plane and how much the CE is now aware of
>>> the underlay.
>>>
>>> trade off for operators with CE based VPNs and how much knowledge are
>>> operators willing to give their customers about the underlay.
>>>
>>> Another point noted in this thread which I think is important and that
>>> is “confusion” related to changing the historical PE / CE terminology.
>>>
>>>> Net-net, I like John’s original proposal. I hope we can take that as
>>>> our base point and factor in further discussions.
>>>>
>>>>
>>>>
>>>> Best,
>>>>
>>>> Adrian
>>>>
>>>>
>>>>
>>>> [1]
>>>> Noting what you said, and assuming that we are covering not only
>>>> IP/MPLS technologies, probably we need to associate the same idea of CE and
>>>> PE to technologies where those roles are not commonly associated, such as
>>>> OTN, DWDM or wireless / microwave, since all of them can be potential
>>>> targets of the IETF Network Slicing realization. Then, if we follow this
>>>> same rationale and finally the WG decides to go in this direction, I guess
>>>> we need to span the CE and PE conception also to those, maybe explaining
>>>> this in the definitions draft. Am I right?
>>>>
>>>>
>>>>
>>>> *Cc :* BOUCADAIR Mohamed TGI/OLN <[email-masked]>;
>>>> Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>; John E Drake
>>>> <jdrake=[email-masked]>; [email-masked]; Joel M. Halpern <
>>>> [email-masked]>

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 27 Feb 2021 03:34:51 -0500

Shunsuke

> understanding is incorrect...)

   Gyan> Agreed no PE/CE handoff.  For any of the NOV3 overlay
encapsulations  types the decapsulation happens on the leaf before packet
is handed off to host endpoint.  Because it’s a host endpoint which would
 be a server and not a customers  “CPE” gear CE switch or router as in the
MPLS world or even with broadband BNG subscribers.  So that’s the big
difference in the Data Center framework from an operators perspective that
is all the operators domain.  You can think of if from a cloud perspective
the network infrastructure is IAAS “infrastructure as a service” and server
infrastructure is PAAS “platform as a service”.

>> Wireless - RAN xHaul - 3GPP gateway to UE - fixed or mobile wireless
>> 4G/5G -  UE to Gateway is the handoff point
>>
>> OTN-
>>> endpoint/NVE (ref. RFC8926)  put the internal of a provider network be an
>>> endpoint of IETF network slice? And if so, can we call them CE or PE?
>>>
>>> Regards,
>>>
>>> Shunsuke
>>>
>>>>> Thus I also support the proposal of using the well-known terms CE/PE
>>>>> to describe the endpoints of IETF network slice.  This could help to reduce
>>>>> really clear figure to help us talk about what we are describing. But
>>>>> Reza’s [1] is a much better start than anything previous. Here I see the
>>>>> classic distinction between a CE-based VPN and a PE-based VPN [2], but we
>>>>> have to ask ourselves carefully whether we **really** want the
>>>>> CE-based approach in our network slicing:
>>>>>
>>>>> Conversely, the port-based PE-based VPN has none of these problems,
>>>>> but does have to agree on the “Access Connection” encoding, and that is
>>>>> either payload-sensitive (like in PWE3) or technology-aware (like in L3VPN).
>>>>>
>>>>>
>>>>>
>>>>> <jdrake=[email-masked]>; [email-masked]; Joel M. Halpern
>>>>> <[email-masked]>

*Gyan Mishra*

---

From: "Ogaki, Kenichi" <[email-masked]>
Date: Sat, 27 Feb 2021 11:07:33 +0000

Hi All,

This is interesting discussion.

Each party can find any number of counterevidences against the opposite party even from existing RFCs since there might have been no discussion like this or there are different solutions for different usecases.

Anyway, I prefer PE/CE even as one of mobile operators.
IMHO, PE/CE concept has already gone beyond customer handoff/demarcation point. Although Adrian indicated PWE3 diagram, I usually see that CE-PE boundary inside our own (operator's internal) network rather than a customer handoff point. Even in our DC, our IP network division provides any connectivity service inside/outside DC to the other division as well as our real customers, as a CE-PE model.
In other words, C in CE actually means not real customer but whoever consumer of a connectivity service.

Thanks,
Kenichi
________________________________
From: Teas <[email-masked]> on behalf of Gyan Mishra <[email-masked]>
Sent: Saturday, February 27, 2021 5:35 PM
To: Shunsuke Homma
Cc: Dongjie (Jimmy); Joel M. Halpern; Luis M. Contreras; [email-masked]; Eric Gray; John E Drake; [email-masked]; Young Lee; Rokui, Reza (Nokia - CA/Ottawa); [email-masked]
Subject: Re: [Teas] network Slice Endpoint in draft-ietf-teas-ietf-network-slice-definition-00

Shunsuke

On Sat, Feb 27, 2021 at 2:01 AM Shunsuke Homma <[email-masked]<mailto:[email-masked]>> wrote:
Thanks, Joel and Gyan.

Yes, I agree that SFC classifier or tunnel endpoint can be a PE router. Meanwhile, I assume there are cases that CF/VNE runs on non-PE/CE router. For example, in case that SFC is performed within the provider's DC (e.g., 5G DN), the ingress GW or ToR switch will be a classifier. Then, the GW/ToR can be called CE or PE?

Certainly, in MPLS world, MPLS termination point is conventionally called PE, but I feel PE/CE may not be generally used in DC or any other field. Actually, Geneve termination point is called tunnel endpoint, and VxLAN also use VTEP (VxLAN Tunnel End Point), not CE/PE. (Sorry if my understanding is incorrect...)

   Gyan> Agreed no PE/CE handoff.  For any of the NOV3 overlay encapsulations  types the decapsulation happens on the leaf before packet is handed off to host endpoint.  Because it’s a host endpoint which would  be a server and not a customers  “CPE” gear CE switch or router as in the MPLS world or even with broadband BNG subscribers.  So that’s the big difference in the Data Center framework from an operators perspective that is all the operators domain.  You can think of if from a cloud perspective the network infrastructure is IAAS “infrastructure as a service” and server infrastructure is PAAS “platform as a service”.

If PE/CE are conceptual entities and can be applied to any cases, not only MPLS(SR) networks, I assume that NSE and PE/CE are the same. Whichever is fine to me.

Regards,

Shunsuke

On Sat, Feb 27, 2021 at 3:21 PM Gyan Mishra <[email-masked]<mailto:[email-masked]>> wrote:

I agree that the PE / CE nomenclature can be used for any scenario where their is a customer handoff “demarcation” and only in those cases can apply the network slicing endpoint concept.

Wireless - RAN xHaul - 3GPP gateway to UE - fixed or mobile wireless 4G/5G -  UE to Gateway is the handoff point

OTN-
OTN GMPLS/MPLS-TP packet core - typically that is the operators infrastructure and so no customer handoff.

Data Center-

So in summary the only two scenarios where you have a customer handoff is the operator access layer wireline and wireless above.

So I think the PE / CE nomenclature fits the bill even with the network slicing paradigm shift.

Kind Regards

Gyan

On Fri, Feb 26, 2021 at 11:59 PM Shunsuke Homma <[email-masked]<mailto:[email-masked]>> wrote:
I'm wondering if CE/PE can cover all cases.

For example, can SFC CF/SFF (ref. RFC 7665) or Geneve tunnel endpoint/NVE (ref. RFC8926)  put the internal of a provider network be an endpoint of IETF network slice? And if so, can we call them CE or PE?

Regards,

Shunsuke

On Sat, Feb 27, 2021 at 9:43 AM Gyan Mishra <[email-masked]<mailto:[email-masked]>> wrote:

I understand their is a paradigm shift with Enhanced VPN  network slicing framework, however I think as John and Eric stated and I agree with their proposed update that “CE” replace “Network slice endpoint” and PE replace “Network Slice Realization Endpoint”.

From an industry  perspective from an operators point of view,  I can see that maybe the Network slicing paradigm shift is being driven by 5G which has its key constructs of XHaul front back and mid haul vRAN and the mobile handset UE 3GPP user data plane and how much the CE is now aware of the underlay.

As Adrian pointed out the CE based VPN versus PE based VPNs and the trade off for operators with CE based VPNs and how much knowledge are operators willing to give their customers about the underlay.

As we all know that even though 5G is the industry driver of network slicing, the framework of network slicing as far as degree of isolation and steering is all based on the very overlay VPN concept now enhanced VPN+ to provide an improved user or SLA experience.   So the concept of network slicing  underpinned of overlay VPN with underlay resources and steering can be used for any use case with requirements of a higher grade SLA and not just 5G , such as DETNET or any content provider video streaming service offering or any service requiring a higher degree of isolation.

Their are definitely trade off from an economics and value added service and ROI perspective  for CE versus PE based VPNs.

Another point noted in this thread which I think is important and that is “confusion” related to changing the historical PE / CE terminology.

Kind Regards

Gyan

On Fri, Feb 26, 2021 at 2:14 AM Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Best regards,
Jie

From: Teas [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Adrian Farrel
Sent: Thursday, February 25, 2021 6:52 PM
To: 'Young Lee' <[email-masked]<mailto:[email-masked]>>; 'Luis M. Contreras' <[email-masked]<mailto:[email-masked]>>
Cc: 'Joel M. Halpern' <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; 'Eric Gray' <[email-masked]<mailto:[email-masked]>>; 'John E Drake' <jdrake=[email-masked]<mailto:[email-masked]>>; 'Rokui, Reza (Nokia - CA/Ottawa)' <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Teas] network Slice Endpoint in draft-ietf-teas-ietf-network-slice-definition-00

Hi all,

Best,
Adrian

Hi,

My two cents,
Young

Best regards

Luis

Cheers,
Med

Hi all,

Best regards

Luis

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

M 301 502-1347
13101 Columbia Pike<https://www.google.com/maps/search/13101+Columbia+Pike?entry=gmail&source=g>
Silver Spring, MD

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

M 301 502-1347
13101 Columbia Pike<https://www.google.com/maps/search/13101+Columbia+Pike?entry=gmail&source=g>
Silver Spring, MD

--

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD

---

From: Shunsuke Homma <[email-masked]>
Date: Sat, 27 Feb 2021 23:06:13 +0900

Hi Gyan,

Please see inline.

> infrastructure is PAAS “platform as a service”.

Shunsuke > Thank you for your elaboration. As you pointed out, frameworks
of NSP network and Data Center are different, and it may be difficult to
 manage with the same model. Meanwhile, in network slicing, it is needed to
 provide "E2E" connectivity guaranteed specific SLA/SLO, and network slice
will be sometimes deployed across both NSP network and Data Center. For
example, in a smart factory scenario, robots may be connected to their
operating server on NSP's cloud with Geneve-based network slice. Then, a
slice endpoint will be Geneve tunnel endpoint, neither CE nor PE.

For customers, it would be better that they can always request a slice with
the same information/data model whatever their target is. If there are
cases where CE/PE can't be fit, I think we should avoid using them as a
slice endpoint.
# If we focus on only transport (i.e., IP/MPLS based network) and never
extend the scope to other fields, it's ok to use CE/PE.

>>
>> If PE/CE are conceptual entities and can be applied to any cases, not
>> only MPLS(SR) networks, I assume that NSE and PE/CE are the same. Whichever
>> is fine to me.
>>
>> Regards,
>>
>> Shunsuke
>>
>>
>>
>>> So in summary the only two scenarios where you have a customer handoff
>>> is the operator access layer wireline and wireless above.
>>>
>>>>>> I also think that Luis’ point about contiguous or stitched segments
>>>>>> is important. There are, I think, two cases to be considered:
>>>>>>
>>>>>> 2021년 2월 24일 (수) 오후 7:00, Luis M. Contreras <[email-masked]
>>>>>> >님이 작성:
>>>>>>
>>>>>> Med, when I was referring to IETF Network Slice of technology X or Y
>>>>>> I was thinking on the realization. So my point here is that in case you
>>>>>> have an IETF Network Slice let's say realized as IP/MPLS, and another one
>>>>>> let's say realized on OTN or DWDM, where the IP/MPLS slice is supported by
>>>>>> the OTN/DWDM slice, can we consider that the CE is IP/MPLS and the PE is
>>>>>> BTW, can you please clarify what do you mean by a “IETF Network
>>>>>> Slice of technology X or Y” as slice is technology-agnostic? Thank
>>>>>> you.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Med
>>>>>>
>>>>>>
>>>>>>
>>>>>> <jdrake=[email-masked]>; [email-masked]; Joel M.
>>>>>> Halpern <[email-masked]>
>>>>>> Regarding the CE / PE discussion, I have doubts if this would apply
>>>>>> to scenarios where we could have stitching of IETF Network Slices or in
>>>>>> Respect to the discussion on IETF Network Slice Service, I think it
>>>>>> is redundant since we are talking of consumer/customer and provider in the

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 27 Feb 2021 18:24:28 -0000

As always, Kenichi makes some good points.

The term “customer” is also open to debate. For some people it means a person who pays for a service, but others just see it as the person or organisation that makes use of a service. I think this is why we started to use “consumer” in the context of network slicing. Hopefully we are all agreed that the IETF network slice is a recursive concept and the consumer of a slice could be:

*	A paying customer (probably organisational)
*	Another division of the service provider (thinking of mobile and transport divisions)
*	A structural optimisation of service provision (e.g., aggregation)

Best,

Adrian

From: Ogaki, Kenichi <[email-masked]> 
Sent: 27 February 2021 11:08
To: Gyan Mishra <[email-masked]>; Shunsuke Homma <[email-masked]>
Cc: Dongjie (Jimmy) <[email-masked]>; Joel M. Halpern <[email-masked]>; Luis M. Contreras <[email-masked]>; [email-masked]; Eric Gray <[email-masked]>; John E Drake <jdrake=[email-masked]>; [email-masked]; Young Lee <[email-masked]>; Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>; [email-masked]
Subject: Re: [Teas] network Slice Endpoint in draft-ietf-teas-ietf-network-slice-definition-00

Hi All,

Thanks,
Kenichi

  _____  

Shunsuke

On Sat, Feb 27, 2021 at 2:01 AM Shunsuke Homma <[email-masked] <mailto:[email-masked]> > wrote:

Thanks, Joel and Gyan.

Regards,

Shunsuke

On Sat, Feb 27, 2021 at 3:21 PM Gyan Mishra <[email-masked] <mailto:[email-masked]> > wrote:

Wireline

OTN-

Data Center-

Typical DC flavors -

Kind Regards 

Gyan

On Fri, Feb 26, 2021 at 11:59 PM Shunsuke Homma <[email-masked] <mailto:[email-masked]> > wrote:

Regards,

Shunsuke

On Sat, Feb 27, 2021 at 9:43 AM Gyan Mishra <[email-masked] <mailto:[email-masked]> > wrote:

 

Kind Regards 

Gyan

On Fri, Feb 26, 2021 at 2:14 AM Dongjie (Jimmy) <[email-masked] <mailto:[email-masked]> > wrote:

Hi, 

Best regards,

Jie

From: Teas [mailto:[email-masked] <mailto:[email-masked]> ] On Behalf Of Adrian Farrel
Sent: Thursday, February 25, 2021 6:52 PM
To: 'Young Lee' <[email-masked] <mailto:[email-masked]> >; 'Luis M. Contreras' <[email-masked] <mailto:[email-masked]> >
Cc: 'Joel M. Halpern' <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> ; 'Eric Gray' <[email-masked] <mailto:[email-masked]> >; 'John E Drake' <jdrake=[email-masked] <mailto:[email-masked]> >; 'Rokui, Reza (Nokia - CA/Ottawa)' <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> 
Subject: Re: [Teas] network Slice Endpoint in draft-ietf-teas-ietf-network-slice-definition-00

Hi all, 

Best,

Adrian

[2] RFC 4026

From: Teas <[email-masked] <mailto:[email-masked]> > On Behalf Of Young Lee
Sent: 24 February 2021 10:22
To: Luis M. Contreras <[email-masked] <mailto:[email-masked]> >
Cc: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> ; Eric Gray <[email-masked] <mailto:[email-masked]> >; John E Drake <jdrake=[email-masked] <mailto:jdrake=[email-masked]> >; Joel M. Halpern <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> 
Subject: Re: [Teas] network Slice Endpoint in draft-ietf-teas-ietf-network-slice-definition-00

Hi,

My two cents,

Young 

Best regards

Luis

Hi Luis, 

Cheers,

Med

Hi all,

Best regards

Luis

-- 

Gyan Mishra

M 301 502-1347
13101 Columbia Pike <https://www.google.com/maps/search/13101+Columbia+Pike?entry=gmail&source=g>  
Silver Spring, MD

-- 

Gyan Mishra

M 301 502-1347
13101 Columbia Pike <https://www.google.com/maps/search/13101+Columbia+Pike?entry=gmail&source=g>  
Silver Spring, MD

-- 

Gyan Mishra

M 301 502-1347
13101 Columbia Pike 
Silver Spring, MD

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 27 Feb 2021 13:36:52 -0500

Hi Shunsuke

On Sat, Feb 27, 2021 at 9:06 AM Shunsuke Homma <
[email-masked]> wrote:

>>> Certainly, in MPLS world, MPLS termination point is conventionally
>>> called PE, but I feel PE/CE may not be generally used in DC or any other
>>> field. Actually, Geneve termination point is called tunnel endpoint, and
>>> VxLAN also use VTEP (VxLAN Tunnel End Point), not CE/PE. (Sorry if my

    Gyan> In a DC NVO3 overlay / underlay model typical leaf/spine CLOS
folded spine architecture, the  demarcation is clearly defined if you apply
the MPLS parity to DC NVO3 directly.   In that framework the spine nodes
are like the P routers performing in line data plane forwarding similar to
P label switching leaf to leaf over the folded spine as well as termination
of control plane and the leafs terminating NVO3 tunnel endpoint vtep for
vxlan for example perform the encapsulation / decapsulation similar to PE
label imposition and disposition.  So applying the same MPLS parity to NVO3
the leaf would be the PE and the TOR connected switch would then be the
CE.  So the same PE/CE nomenclature can still apply.

For non NVO3 BGP only DC CLOS folded spine architecture we still have the
leaf and spine nodes  and here also the leaf would be the PE and TOR
hanging off the leaf would be the CE.

I think in any model even in GMPLS mode for example where you have an
peering adjacency such as inter-as tie that would be your NNI PE-PE
relationship.

As far as SFC classifier that would be on the leaf switch acting as the PE
demarcation to the CE TOR switch.

So you can really apply the PE/CE nomenclature ubiquitously to any scenario.

>
> For customers, it would be better that they can always request a slice
> with the same information/data model whatever their target is. If there are
>>>> I agree that the PE / CE nomenclature can be used for any scenario
>>>> where their is a customer handoff “demarcation” and only in those cases can
>>>> apply the network slicing endpoint concept.
>>>>
>>>>>> that is “confusion” related to changing the historical PE / CE terminology.
>>>>>>
>>>>>>> I’m piling in in response to Young, mainly because that’s the email
>>>>>>> I happen to have open. But also because the perspective of Young and Luis
>>>>>>> -          What are the considerations for how much knowledge of
>>>>>>> the underlay network has to be shared to the CE?
>>>>>>>
>>>>>>> Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>; John E
>>>>>>> Drake <jdrake=[email-masked]>; [email-masked]; Joel M.

*Gyan Mishra*

---

From: Shunsuke Homma <[email-masked]>
Date: Sun, 28 Feb 2021 13:20:48 +0900

Hi Gyan,

Please see inline.

> So you can really apply the PE/CE nomenclature ubiquitously to any

Shunsuke > Thank you very much. I understood that PE/CE model can be
applied in every network slice scenario from the aspect of traffic
handoffs. I agree with that, and it seems reasonable.

Then, my next concern is whether we should bring terms of MPLS world to
overlay world. (It depends on the realization, but I assume network slices
will be realized with overlay technologies in many cases.) NVO3 and other
 overlay technologies use "endpoint", and I feel it is more compatible to
network slice scenarios. NSE can be also applied to every network slice
scenario. As Reza mentioned, NSE is a logical entity of network slice layer
and will be mapped to (virtual/physical) node in technology layer such as
CE//PE for MPLS, VNE, VTEP, etc.

Also, I think some modification or extension of definitions of CE/PE for
these usage if we use CE/PE terms instead of NSE. As Kenichi pointed,
"customer" of CE actually means "consumer". PE may mean edge of IETF
technology-enabled domain, not provider network, in such usage.

Anyway, I don't see any serious problems whichever is chosen, and think
this is a matter of taste finally. Or we need more consideration from
different aspects.

>>>>>>> can see that maybe the Network slicing paradigm shift is being driven by 5G
>>>>>>>> the explanation and summary of the PE-based and CE-based VPNs.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> CE/PE to describe the endpoints of IETF network slice.  This could help to
>>>>>>>> reduce the possible confusions caused by using one term to represent
>>>>>>>> different positions. This could also help to understand the mapping from
>>>>>>>> IETF network slice requirements to its realization, which could be based on
>>>>>>>> the architecture and technologies described in the enhanced VPN draft [3].
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>>
>>>>>>>> Jie
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> *Cc:* 'Joel M. Halpern' <[email-masked]>; [email-masked];
>>>>>>>> 'Eric Gray' <[email-masked]>; 'John E Drake' <jdrake=
>>>>>>>> enhanced VPNs (VPN+) [3] and IETF network slices as the same thing.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>    very much the same as the multi-AS L3VPN. We have to consider how the
>>>>>>>>    “service request” is mapped from one domain to another. But it may help to
>>>>>>>>    recall that, for all our dreaming, end-to-end multi-AS MPLS-TE tunnels are
>>>>>>>>    not much of a thing: domains don’t like sharing information about or
>>>>>>>>    control of their network resources. Thus the “E-NNI” between slice domains
>>>>>>>>    may be as much of a service interface as the “UNI” between consumer and
>>>>>>>>    provider.
>>>>>>>>    different technology networks to provide an end-to-end slice. From a
>>>>>>>>    consumer’s point of view, this is exactly what happens, but it is not clear
>>>>>>>>    to me whether this is really what happens in a deployment. Surely there is
>>>>>>>>    aggregation as we go down the technology layers and into the “transport”
>>>>>>>>    networks. That is, there may be very, very many micro slices in the RAN,
>>>>>>>>    but as this moves onto the IP transport, it is likely that the slicing is
>>>>>>>>    aggregated. That means that the stitching of slices actually follows a
>>>>>>>>    hierarchical model with recursion. The interface between slice domains is
>>>>>>>>    the “UNI”.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Net-net, I like John’s original proposal. I hope we can take that
>>>>>>>> as our base point and factor in further discussions.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Best,
>>>>>>>>
>>>>>>>> Adrian
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> [1]
>>>>>>>> Med, when I was referring to IETF Network Slice of technology X or
>>>>>>>> Y I was thinking on the realization. So my point here is that in case you
>>>>>>>> Drake <jdrake=[email-masked]>; [email-masked]; Joel
>>>>>>>> M. Halpern <[email-masked]>

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 28 Feb 2021 09:30:26 -0500

Hi Shunsuke

On Sat, Feb 27, 2021 at 11:21 PM Shunsuke Homma <
[email-masked]> wrote:

>>>>> Yes, I agree that SFC classifier or tunnel endpoint can be a PE
>>>>> router. Meanwhile, I assume there are cases that CF/VNE runs on non-PE/CE
>>>>> router. For example, in case that SFC is performed within the provider's DC
>>>>> (e.g., 5G DN), the ingress GW or ToR switch will be a classifier. Then, the
>>>>> GW/ToR can be called CE or PE?
>>>>>
>>> Shunsuke > Thank you for your elaboration. As you pointed out,
>>> frameworks of NSP network and Data Center are different, and it may be
>>> difficult to  manage with the same model. Meanwhile, in network slicing, it
>>> is needed to  provide "E2E" connectivity guaranteed specific SLA/SLO, and
>>> network slice will be sometimes deployed across both NSP network and Data
>>> Center. For example, in a smart factory scenario, robots may be connected
>>> to their operating server on NSP's cloud with Geneve-based network slice.
>>> Then, a slice endpoint will be Geneve tunnel endpoint, neither CE nor PE.
>>>
>>
>> As far as SFC classifier that would be on the leaf switch acting as the
>> PE demarcation to the CE TOR switch.
>>

    Gyan> Great.  I think we are making progress.😀

> CE//PE for MPLS, VNE, VTEP, etc.

    Gyan> The concept of underlay/overlay actually historically started
with any framework where you have a concept of multi tenancy or multiple
customer framework that broadened the single tenant IP based framework to a
logical construct by creating a “hypervisor like” overlay/underlay model
now called “MPLS”.  MPLS can be utilized as a single tenant model similar
to IP based model in an enterprise MPLS framework where the PE-CE edge is
native IP “no VRF” or virtualization of the edge layer using “global table”
single layer no overlay routing PE-RR SAFI 1 for IPv4 and SAFI 4 for IPv6
BGP LU (6PE) to connect IPv6 islands over an MPLS core. “MPLS” can also be
user in a Service Provider mode of “multi tenancy” multi customer model
identical to NVO3 with a virtualization “hypervisor like” layer added with
now populating the label stack two layers deep with now a virtualization of
the PE-CE edge layer with VRF concept similar to a VM VNF on a NFV
framework, so now the topmost transport label is the  underlay global table
routing and your bottom of stack a label BOS bit set is your virtualization
layer VPN “overlay” layer identical to NVO3 “overlay/underlay” concept.  So
the idea of tunneling is tunnel endpoint and tunnel termination point is
not new and applies to any framework where you have encapsulation and
decapsualation occurring in MPLS it’s imposition and disposition of the
Label stack to forward native IP to the CE edge end in NVO3 it’s the same
removal of the outer envelope to forward native IP to the edge.  The
virtualization layer in both cases stops at the PE edge when the handoff
occurs from PE to CE as now the CE edge sits in the global table routing.
This is true any overlay/underlay architecture with MPLS and NVO3 as direct
parity examples.  We can actually think of the concept of network slice
framework as a pre existing condition of any overlay / underlay model as
logically the overlay “VPN overlay” or “NVO3 overlay”  is a slice of the
physical with the virtualization layer terminating on what we call today a
“PE” and tomorrow with network slice paradigm shift with my parity added in
the paradigm shift we end up still calling it a “PE”.

> technology-enabled domain, not provider network, in such usage.

    Gyan> Agreed.

> this is a matter of taste finally. Or we need more consideration from

    Gyan> The major take away here is in my mind is added industry
confusion or layer of abstraction as it may be with new nomenclature where
we are really still talking about the same endpoint type.  Nothing has
really changed, but it’s just wrapping our heads around the network slice
concept where in reality it has existed for decades.

>>>>>> So in summary the only two scenarios where you have a customer
>>>>>> handoff is the operator access layer wireline and wireless above.
>>>>>>
>>>>>>>> As we all know that even though 5G is the industry driver of
>>>>>>>> network slicing, the framework of network slicing as far as degree of
>>>>>>>> isolation and steering is all based on the very overlay VPN concept now
>>>>>>>> enhanced VPN+ to provide an improved user or SLA experience.   So the
>>>>>>>> concept of network slicing  underpinned of overlay VPN with underlay
>>>>>>>> resources and steering can be used for any use case with requirements of a
>>>>>>>> higher grade SLA and not just 5G , such as DETNET or any content provider
>>>>>>>> video streaming service offering or any service requiring a higher degree
>>>>>>>> of isolation.
>>>>>>>>
>>>>>>>>> network slice in both the service layer and the tunnel layer are the same,
>>>>>>>>> the only difference is the position the NSE represents.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> email I happen to have open. But also because the perspective of Young and
>>>>>>>>> Luis should be valuable to us in this context.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> in packet networks, I don’t believe the concepts are firmly linked only to
>>>>>>>>> to answer. Of course, the concept of a “provider-managed CE” muddies these
>>>>>>>>> waters somewhat.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> problems, but does have to agree on the “Access Connection” encoding, and
>>>>>>>>> that is either payload-sensitive (like in PWE3) or technology-aware (like
>>>>>>>>> in L3VPN).
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> segments is important. There are, I think, two cases to be considered:
>>>>>>>>>
>>>>>>>>>    different technology networks to provide an end-to-end slice. >From a
>>>>>>>>> Slice of technology X or Y” as slice is technology-agnostic?
>>>>>>>>> Thank you.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>>
>>>>>>>>> Med
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Regarding the CE / PE discussion, I have doubts if this would
>>>>>>>>> apply to scenarios where we could have stitching of IETF Network Slices or
>>>>>>>>> in scenarios where an IETF Network Slice of technology X is supported on
>>>>>>>>> Respect to the discussion on IETF Network Slice Service, I think
>>>>>>>>> it is redundant since we are talking of consumer/customer and provider in

*Gyan Mishra*

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 28 Feb 2021 09:53:35 -0500

Hi Shunsuke

On Sun, Feb 28, 2021 at 9:30 AM Gyan Mishra <[email-masked]> wrote:

>>> For non NVO3 BGP only DC CLOS folded spine architecture we still have
>>> the leaf and spine nodes  and here also the leaf would be the PE and TOR

> concept where in reality it has existed for decades.

    Gyan> So the concept of “network slice” is half way there with the
slide concept being a pre existing condition with the overlay VPN or NVO3
overlay concept.  The second half of the slicing that was missing that is
now being added is the underpinnings of VPN overlay which is already sliced
to the underlay now extending the overlay slicing to the underlay slice of
resources.  From a cross sectional standpoint if you think of a pie the
knife went half way through the slice but landed in the middle bottom half
being the underlay but now when the knife goes all the way through the
cross section now you have slice of pie which is the “network slice”.

>>>>>>>>> As Adrian pointed out the CE based VPN versus PE based VPNs and
>>>>>>>>> the trade off for operators with CE based VPNs and how much knowledge are
>>>>>>>>>> [email-masked]>; 'Rokui, Reza (Nokia - CA/Ottawa)'
>>>>>>>>>> <[email-masked]>; [email-masked]
>>>>>>>>>> and reconginize that there are a number of scenarios that may need
>>>>>>>>>> transport network slices (which is now called IETF network slices). For
>>>>>>>>>> instance, possibly slices may be needed in the fronthaul, midhaul and
>>>>>>>>>> backhaul as well as within DC networks that host the functions. Other than
>>>>>>>>>> backhaul networks, the terms CE and PE may not be adequate because for the
>>>>>>>>>> Med, when I was referring to IETF Network Slice of technology X
>>>>>>>>>> or Y I was thinking on the realization. So my point here is that in case
>>>>>>>>>> you have an IETF Network Slice let's say realized as IP/MPLS, and another
>>>>>>>>>> one let's say realized on OTN or DWDM, where the IP/MPLS slice is supported
>>>>>>>>>> by the OTN/DWDM slice, can we consider that the CE is IP/MPLS and the PE is

*Gyan Mishra*