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

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

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:
> 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
> 
>      >
> 
> 
> _______________________________________________
> Teas mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/teas
>