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

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

+1 for the above.

--
Uma C.

On Fri, Feb 5, 2021 at 2:29 PM Adrian Farrel <adrian@olddog.co.uk> 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 <teas-bounces@ietf.org> On Behalf Of Joel M. Halpern
> Sent: 05 February 2021 17:04
> To: teas@ietf.org
> 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
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas
>
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas
>