Re: [Teas] Upcoming changes to draft-ietf-teas-ietf-network-slices

[Greg Mirsky <[e-mail]>]

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]> 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]> *De la part de* Adrian Farrel
> *Envoyé :* mercredi 2 mars 2022 22:15
> *À :* 'TEAS WG' <[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]
> https://www.ietf.org/mailman/listinfo/teas
>