[Teas] Statistical parameters in draft-ietf-teas-ietf-network-slice-nbi-yang (was RE: Upcoming changes to draft-ietf-teas-ietf-network-slices)

[[e-mail]]

Hi Greg,

(changing the subject so that this can be tracked by the authors of draft-ietf-teas-ietf-network-slice-nbi-yang)

Glad to see that we are in agreement about adding statistical parameters to the module. I hope that percentile values will be supported in the next iterations of the spec.

I like the spirit of the PAM SLO Draft. FWIW, please find some comments to the PAM SLO draft at these urls:


  *   pdf: https://raw.githubusercontent.com/boucadair/IETF-Drafts-Reviews/master/draft-mhmcsfh-ippm-pam-00-rev%20Med.pdf
  *   doc: https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-mhmcsfh-ippm-pam-00-rev%20Med.doc

Cheers,
Med

De : Greg Mirsky <[e-mail]>
Envoyé : vendredi 4 mars 2022 22:54
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>
Cc : [e-mail]; TEAS WG <[e-mail]>
Objet : Re: [Teas] Upcoming changes to draft-ietf-teas-ietf-network-slices

Hi Med, et al.,
thank you for pointing out the example of using the maximum value of a performance metric as the measure of service conformance to an SLO. I think that other statistical parameters, e.g., percentile, may be also used in that role.
And as we're discussing the topic of IETF network slice conformance to an SLA that is presented as a multi-SLO set, I bring to your attention a new draft submitted to the IPPM WG - Precision Availability Metrics for SLO-Governed End-to-End Services<https://datatracker.ietf.org/doc/draft-mhmcsfh-ippm-pam/> . We always appreciate your comments, questions, and suggestions. Please consider adding the IPPM mailing list.

Regards,
Greg

On Wed, Mar 2, 2022 at 10:49 PM <[e-mail]<mailto:[e-mail]>> wrote:
Hi Adrian, all,

All good points. Thanks for tracking the issues and fixing them.

For the third point, I wonder if it is useful to include a short statement to position the service demarcation point vs. service attachment point (draft-ietf-opsawg-sap) or leave that to the SAP spec.

Cheers,
Med

De : Teas <[e-mail]<mailto:[e-mail]>> De la part de Adrian Farrel
Envoyé : mercredi 2 mars 2022 22:15
À : 'TEAS WG' <[e-mail]<mailto:[e-mail]>>
Objet : [Teas] Upcoming changes to draft-ietf-teas-ietf-network-slices


Hi,



I am just about to post -06 of this document. None of the changes, below should be a surprise. 1, 3, and 4 were talked about at IETF-112. 2 is just fine-tuning the text already in -05.



  1.  Deprecating NBI/SBI



Per the discussion at IETF-112 and following on from Med’s comments, I am replacing “NBI” with “IETF Network Slice Service Interface”, and “SBI” with “Network Configuration Interface”.



These are abstract terms, and the implementations might choose to use NSSM and NSNM. They might also choose to stick with NBI, but I personally find that term ambiguous in the greater scheme of things.



  1.  Clarifying the relationships between slices, connectivity constructs, SLOs/SLEs, and network resource partitions.



Recent reviews and discussions of draft-bestbar-teas-ns-packet have made it clear that the current text is not sufficiently unambiguous. Although I know what I meant, the text is open to interpretation and needs to be tightened up.



The relationships are easy to express:



  *   A network slice is a service requested by / provided for the customer
  *   The network slice service is expressed in terms of one or more connectivity constructs.
An implementation or operator is free to limit the number of connectivity constructs in a slice to exactly one.
  *   Each connectivity construct has a set of SLOs and SLEs.
The set does not need to be the same for every connectivity construct in the slice.
An implementation or operator is free to require that all connectivity constructs in a slice have the same set of SLOs and SLEs.
  *   One or more connectivity constructs from one or more slices are mapped to a set of network resources called a Network Resource Partition (NRP).
One connectivity construct is only mapped to one NRP.
An NRP may be chosen because of its ability to support a specific set of SLOs and SLEs, or its ability to support particular connectivity types.
An implementation or operator is free to map each connectivity construct to a separate NRP, although there may be scaling implications depending on the solution implemented.
Thus, the connectivity constructs in one slice may be mapped to one or more NRPs.
By implication from the above, an implementation or operator is free to map all the connectivity constructs in a slice to a single NRP and to not share that NRP with connectivity constructs from another slice.
  *   An NRP is simply a collection of (reserved) resources extracted from the underlying physical network.
The process of determining the NRP may be made easier if the physical network topology is first filtered into a Filter Topology in order to be aware of the subset of network resources that are suitable for specific NRPs.



  1.  What to call an end point



During IETF-112 we spotted several overlapping terms (CE, end-point, NSE, maybe PE) and decided that the more generic term “Service Demarcation Point” should be used.



This will help remove the confusion about where the service begins and ends, allowing the existing text that enumerates the options to not get blurred by other text in the document. Of course, CEs and PEs still exist and need to be mentioned, but the service demarcation point term allows us to be generic without forcing any one of the four implementation options already described in the text and Figure 1.



  1.  General editorial pass to clean up spelling and language use



Best,

Adrian





_________________________________________________________________________________________________________________________



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.
_______________________________________________
Teas mailing list
[e-mail]<mailto:[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.