Re: [Teas] Proposed text on "IETF Network Slicing Service"

[[e-mail]]

Hi Adrian, all, 

Thanks for drafting this text. 

I like the proposal but I have some comments. 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Teas [mailto:[e-mail]] De la part de Adrian Farrel
> Envoyé : lundi 9 août 2021 16:38
> À : [e-mail]
> Cc : [e-mail]
> Objet : [Teas] Proposed text on "IETF Network Slicing Service"
> 
> Hi,
> 
> Back in February and April, John Drake led some discussions about
> the definition of a Network Slice Service.
> 
> I think that that email thread reached a kind of stability on the
> list, and it is (as mentioned in San Francisco) time to bring that
> into draft-ietf-teas-ietf-network-slices.
> 
> We already have mention of "IETF Network Slice Service" in Section
> 2.1, but we don't have a definition. I propose to add a new Section
> 3.2 based on John's text as follows. This places it after the
> definition of "IETF Network Slice" in 3.1, but before the discussion
> of "IETF Network Slice System Characteristics" in Section 4.
> 
> I think there may be some debate still open about the use of "SLO"
> in this text. John originally had "SLO" but I believe that is wrong
> because each sending CE would have multiple SLOs and SLEs
> associated. I was tempted to use "SLA" instead, but that term would
> apply to the whole service. So I settled for the (cumbersome) "set
> of SLOs and SLEs".

[Med] I still don't see the need to complicate the discussion with SLO/SLE taxonomy. I hope we can simplify the definition and simply talk about service objectives. Assessing whether the delivered slice service is matching the expected one is handled by the assurance/fulfillment components. The slice service should include specific parameters/characterization of these components.

> 
> Note that this text is closely related to the discussion of
> endpoints. That is currently found in Section 4.2, but was also the
> subject of discussion on the list and will surface as a separate set
> of proposed changes in an email to follow.
> 
> Any suggestion or discussion is highly welcome.
> 
> Best,
> Adrian
> 
> ===
> 
> 3.2. IETF Network Slice Service
> 
>    A service provider instantiates an IETF network slice service for
> a
>    customer.  The IETF network slice service is specified in terms
> of a
>    set of the customer's endpoints (CEs), a set of connectivity
> matrices
>    (point-to-point (P2P), point-to-multipoint (P2MP), multipoint-to-
>    point (MP2P), or multipoint- to-multipoint (MP2MP)) between
> subsets
>    of these CEs

[Med] As indicated in another thread, this is restrictive as the slice may not always imply communication between CEs, but can involve a CE and SFs that terminates the slice flows. We need to cover this case as well. 


, and a set of SLOs and SLEs for each CE sending to

[Med] I suggest to replace this with "slice service performance requirements" or something similar.

> each
>    connectivity matrix.  I.e., in a given IETF Network Slice Service

[Med] Please use a consistent wording "IETF Network Slice Service" or "IETF network slice service" used in the previous sentences. 

>    there may be multiple connectivity matrices of the same or
> different
>    type, each connectivity matrix may be between a different subset
> of
>    CEs, and for a given connectivity matrix each sending CE has its

[Med] "sending CE" is restrictive as some slices may only require "receiving". Please think about slices to deliver multicast flow to CEs. The same comment applies for some parts of the text below.


> own
>    set of SLOs and SLEs, and the SLOs and SLEs in each set may be
>    different.  It is also the case that a given sending CE may be

[Med] s/sending CE/CE

> part
>    of multiple connectivity matrices within a single IETF network
> slice
>    service, and the CE may have different SLOs and SLEs for each
>    connectivity matrix to which it is sending.  Note that a given
>    sending CE's SLOs and SLEs for a given connectivity matrix apply
>    between it and each of the receiving CEs for that connectivity
>    matrix.

[Med] Maybe it is worth to indicate at this stage that the connectivity matrices are unidirectional and note that bidir slices will required matrices for each direction.    

> 
>    This approach results in the following possible connectivity
>    matrices:
> 
>    o  For an MP2MP connectivity matrix with N CEs, each of the N
> sending
>       CEs has its own set of SLOs and SLEs and they may all be
>       different.
> 
>    o  For a P2MP connectivity matrix, there is only one sending CE,
> and
>       there is only one set of SLOs and SLEs.
> 
>    o  For an MP2P connectivity matrix with N CEs, there is one
> receiving
>       CE and (N - 1) sending CEs.  Each sending CE has its own set
> of
>       SLOs and SLEs and they may all be different.
> 
>    o  For a P2P unidirectional connectivity matrix, there is only
> one
>       sending CE and there is only one set of SLOs and SLEs.
> 
>    o  For a P2P bidirectional connectivity matrix, there are two
> sending
>       CEs

[Med] Not sure this is always true as the "sending" part may be a source that is a head-end located in the provider's network. 

, there are two sets of SLOs and SLEs which may be
> different.
> 
>    If an IETF network slice service customer wants to have hub and
> spoke
>    connectivity between N CEs in order to control how traffic is
>    distributed between its CEs, it requests a set of N - 1 P2P
>    unidirectional connectivity matrices, each between a sending CE
> spoke
>    and the hub CE, and a P2MP connectivity matrix between the
> sending CE
>    hub and the spoke CEs.
> 
>    It should be noted that per Section 9 of [RFC4364] an IETF
> network
>    slice service customer may actually provide IETF network slice
>    services to other customers.  In this case, the underlying IETF
>    network slice service provider may be owned and operated by the
> same
>    or a different provider network.

[Med] I like this. 

> 
>    Section 4.2 provides a description of endpoints in the context of
>    IETF network slicing.  For a given IETF network slice service,
> the
>    IETF network slice customer and provider agree, on a per-CE basis
>    which end of the attachment circuit provides the service
> demarcation
>    point.

[Med] In addition to who is providing the point, there is a need to agree on features that need to be enabled in both sides for the activation of the service. Think about CE-PE routing. 

  This determines whether the attachment circuit is
> included in
>    the set of SLOs and SLEs for the subject CE.
> 
> _______________________________________________
> 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.