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

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

Joel,
Comments are inlined.

Cheers,
Reza



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

    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.

[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:
    > 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).
    > 
    > Cheers,
    > 
    > Reza
    > 
    >      ------------------Original Message-----------------------
    > 
    > On 2021-02-05, 5:29 PM, "Teas on behalf of Adrian Farrel" 
    > <[e-mail] on behalf of [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]> On Behalf Of Joel M. Halpern
    > 
    >      Sent: 05 February 2021 17:04
    > 
    >      To: [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]
    > 
    >      https://www.ietf.org/mailman/listinfo/teas
    > 
    >      _______________________________________________
    > 
    >      Teas mailing list
    > 
    >      [e-mail]
    > 
    >      https://www.ietf.org/mailman/listinfo/teas
    >