Re: [Teas] Slicing Framework Open issue #1 : Service != Realization

[[e-mail]]

Hi Adrian, all, 

Looks good to me as well. Thanks.

You may consider these very minor changes: 
* s/Mechanisms/mechanisms
* s/Section 3.1/Section 6

Cheers,
Med

> -----Message d'origine-----
> De : Teas <[e-mail]> De la part de Adrian Farrel
> Envoyé : vendredi 25 mars 2022 10:17
> À : [e-mail]
> Objet : [Teas] Slicing Framework Open issue #1 : Service != Realization
> 
> Hi,
> 
> First in a series of emails to resolve the open issues mentioned during
> the TEAS meeting.
> 
> We have, for the longest time, suffered from a blurring between the
> service provided to the customer, and how that service is engineered in
> the network.
> This leads us to talk about VPNs in a way where sometimes a VPN is what
> the customer gets and sometimes it is what the operator engineers. A
> good example is the term "MPLS VPN" as though the customer cares whether
> the VPN is provided using MPLS technology.
> 
> We have, to some extent, clarifies this with recent YANG "Customer
> Service Models" that describe the service offered to the customer, but
> do not constrain the provider's choice of implementation technology or
> options.
> 
> As the discussion of IETF Network Slices continues, I have repeatedly
> seen some blurring between the topics of the "IETF Network Slice
> Service" and the "IETF Network Slice." It seems to me that this mixing
> of concepts will continue as future readers pick up the document.
> 
> Although I have tried to use the two terms clearly and distinctly, the
> document is missing a clear statement to disambiguate the two.
> 
> Section 3 provides the definitions of the two terms at some length using
> subsections. The clarification would get lost if it was placed at the
> bottom of the section after the subsections, so I propose to include
> some text near the top of section as follows.
> 
> OLD
>    IETF Network Slices are created to meet specific requirements,
>    typically expressed as bandwidth, latency, latency variation, and
>    other desired or required characteristics.  Creation of an IETF
>    Network Slice is initiated by a management system or other
>    application used to specify network-related conditions for particular
>    traffic flows in response to an actual or logical IETF Network Slice
>    service request.
> 
>    Once created, these slices can be monitored, modified, deleted, and
>    otherwise managed.
> 
>    Applications and components will be able to use these IETF Network
>    Slices to move packets between the specified end-points of the
>    service in accordance with specified characteristics.
> NEW
>    IETF Network Slices are created to meet specific requirements,
>    typically expressed as bandwidth, latency, latency variation, and
>    other desired or required characteristics.  Creation of an IETF
>    Network Slice is initiated by a management system or other
>    application used to specify network-related conditions for particular
>    traffic flows in response to an actual or logical IETF Network Slice
>    service request.
> 
>    Once created, these slices can be monitored, modified, deleted, and
>    otherwise managed.
> 
>    Applications and components will be able to use these IETF Network
>    Slices to move packets between the specified end-points of the
>    service in accordance with specified characteristics.
> 
>    A clear distinction should be made between the "IETF Network
>    Slice service" which is the function delivered to the customer
>    (see Section 3.2) and which is agnostic to the technologies and
>    Mechanisms used by the service provider, and the "IETF Network
>    Slice" which is the realization of the service in the provider's
>    network achieved by partitioning network resources and by
>    applying certain tools and techniques within the network (see
>    Section 3.1).
> END
> 
> Any objections?
> 
> Thanks,
> Adrian
> 
> _______________________________________________
> 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.