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

["Rokui, Reza (Nokia - CA/Ottawa)" <[e-mail]>]

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" <[e-mail]> 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 <[e-mail]>

    > *Date: *Wednesday, February 10, 2021 at 11:21 AM

    > *To: *Reza Rokui <[e-mail]>, "[e-mail]"

    > <[e-mail]>, "'Joel M. Halpern'" <[e-mail]>,

    > "[e-mail]" <[e-mail]>

    > *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 <[e-mail]> *On Behalf Of * Rokui, Reza (Nokia

    > - CA/Ottawa)

    > *Sent:* Wednesday, February 10, 2021 7:39 AM

    > *To:* [e-mail]; 'Joel M. Halpern' <[e-mail]>;

    > [e-mail]

    > *Cc:* Rokui, Reza (Nokia - CA/Ottawa) <[e-mail]>

    > *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"

    > <[e-mail] on behalf of [e-mail]

    > <mailto:[e-mail][e-mail]>>

    > 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 <[e-mail] <mailto:[e-mail]>>

    > On Behalf Of Joel M. Halpern

    >

    >      Sent: 05 February 2021 17:04

    >

    >      To: [e-mail] <mailto:[e-mail]>

    >

    >      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

    >

    > [e-mail] <mailto:[e-mail]>

    >

    > https://www.ietf.org/mailman/listinfo/teas

    > <https://www.ietf.org/mailman/listinfo/teas>

    >

    >      _______________________________________________

    >

    >      Teas mailing list

    >

    > [e-mail] <mailto:[e-mail]>

    >

    > https://www.ietf.org/mailman/listinfo/teas

    > <https://www.ietf.org/mailman/listinfo/teas>

    >

    >

    > _______________________________________________

    > Teas mailing list

    > [e-mail]

    > https://www.ietf.org/mailman/listinfo/teas

    >