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

[[e-mail]]

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:[e-mail]] De la part de Joel M.
> Halpern
> Envoyé : vendredi 5 février 2021 18:04
> À : [e-mail]
> Objet : [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

_________________________________________________________________________________________________________________________

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.