Re: [Teas] What SLOs and SLEs should be in the Slicing Service Model?

[[e-mail]]

Hi all,

I echo what Gyan said: this thread is about service modeling but helps to clarify how to use the framework. FWIW, here are the key points from where I sit:


  *   The framework spec does not intend to be provide an exhaustive list of each aspect it describes. These are provided as examples.
  *   A definition that is provided in the framework for a given parameter (e.g., all these parameters with max values) may be adjusted in the service model. For example, to consider statical representations such as percentile values.
  *   It would be OK if not all the objectives listed in the framework may be supported in the first version of the service model. A trade-off will need to be found: exhaustiveness vs. usability.
  *   For each parameter that can be measured/assessed as per an agreed slice service, the service model will need to include a provision for the reference setup so that adequate measurement data is retrieved (e.g., measurement period, sampling interval, notification frequency, thresholds, rate limits, etc.).
  *   The SLO/SLE taxonomy should not be frozen per parameter in the service model. This is now well covered in the framework:

==
Of course, over time, it is possible that mechanisms will
   be developed that enable a customer to verify the provision of an
   SLE, at which point it effectively becomes an SLO.
==

I don’t think any change is needed to the framework I-D, but hope the authors of the service model are monitoring this thread :-).

Cheers,
Med

De : Teas <[e-mail]> De la part de Gyan Mishra
Envoyé : samedi 26 mars 2022 01:17
À : John E Drake <[e-mail]>
Cc : [e-mail]; TEAS WG <[e-mail]>
Objet : Re: [Teas] What SLOs and SLEs should be in the Slicing Service Model?

John / All

Per this thread where we are discussing what SLO/SLE taxonomy should be in the service model does bring up some questions related to the network slice draft.

In the thread as Adrian started off the thread stating that Protection qualifies as an SLE  but Reliability is definitely an SLO and there may be a gray area of whether or not it's one or the other.

I wonder if there could be characteristics that could be both SLO & SLE?

The term measurable  & unmeasurable realization feature really helps define what characteristics define an SLO or SLE.

Does not have to be an exhaustive list but I think more than just the common SLO's & SLE's.  I think the gray area ones we should try to spell out in the draft.

Below are good points that Med brought up and I think are applicable to section 4 of the draft. Especially that over time the what maybe an SLE today maybe an SLO tomorrow and vice versa.

Flip side of that is maybe to only spell out the concrete ones that will never change sides.

**Mentioned by Med at the beginning of this thread***

* Things would be much simpler if we just focus on service requirements without making an assumption how such requirement is expressed and whether it is quantified/quantitative/qualitative/measurable/etc. Whether/how a specific service requirement is covered by service assurance/fulfillment can be part of the slice service definition itself.

* What we may tag as an SLE today because of the technology limitations, may not stay as such forever. It may be true that an "expectation" may not be easily assessed using current techniques (and thus be tagged as SLE), but this does not prevent that innovative means would be defined in the future (which means that it is an SLO, not an SLE anymore).

* We are artificially adding extra complexity for the modelling part as service requirement will need to be classified based as SLO or SLEs.

We can branch this off on a separate thread if everyone thinks there is any merit to follow up on this topic.

Kind Regards

Gyan


_________________________________________________________________________________________________________________________

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.