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

Re-, 

Some services may be sensitive to delay for example but the slice service request may include (for whatever reason) not only the delay, but also other attributes that are currently listed as SLOs in the draft. The provider is requested to only commit on the delay and best effort for the other attributes.                                

Cheers,
Med

> -----Message d'origine-----
> De : Joel M. Halpern <jmh@joelhalpern.com>
> Envoyé : jeudi 24 mars 2022 15:07
> À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com>
> Cc : 'TEAS WG' <teas@ietf.org>; adrian@olddog.co.uk
> Objet : Re: [Teas] What SLOs and SLEs should be in the Slicing Service
> Model?
> 
> Interesting.  If they are indeed not coupled, then you are clearly correct
> about representation.
> 
> Can you give an example so I can understand when they would not be coupled.
> I had leapt to the (quite possibly incorrect) conclusion that the two sets
> of properties went together.
> 
> Thank you,
> Joel
> 
> On 3/24/2022 10:03 AM, mohamed.boucadair@orange.com wrote:
> > Hi Joel,
> >
> > It is.
> >
> > As mentioned below, this should be covered as part of service
> assurance/fulfillment/reporting parameters. Which parameters to put there
> is deployment-specific. Not all parameters tagged as SLO in the framework
> will end up as part of the assurance/fulfillment/reporting.
> >
> > Cheers,
> > Med
> >
> >> -----Message d'origine-----
> >> De : Joel M. Halpern <jmh@joelhalpern.com> Envoyé : jeudi 24 mars
> >> 2022 14:52 À : BOUCADAIR Mohamed INNOV/NET
> >> <mohamed.boucadair@orange.com>; adrian@olddog.co.uk; 'TEAS WG'
> >> <teas@ietf.org> Objet : Re: [Teas] What SLOs and SLEs should be in
> >> the Slicing Service Model?
> >>
> >> Isn't it important to distinguish between "these are things I expect
> >> you to do, measure, and report" and "these are things I would like
> >> you to do even though they are not measurable or reportable"?
> >>
> >> Yours,
> >> Joel
> >>
> >> On 3/23/2022 10:08 AM, mohamed.boucadair@orange.com wrote:
> >>> Hi all,
> >>>
> >>> This message actually triggers a companion comment I have on the
> >>> SLO/SLE
> >> taxonomy. From the service modeling standpoint, I suggest that we
> >> don't inherit that taxonomy for various reasons:
> >>>
> >>> * 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.
> >>>
> >>> * I remember that Kiran agreed at least to not import that taxonomy
> >>> into
> >> the data model when we were discussing the call for adoption of the
> >> slice
> >> definition:
> >>>
> >>> ==(the full message from Kiran can be found in the archives)===
> >>> "However, it should not imply that NBI models are required to have
> >> SLE/SLO indicators and I totally agreed with your comments on
> >> draft-wd- teas-ietf-network-slice-nbi-yang-03"
> >>> ==
> >>>
> >>> Cheers,
> >>> Med
> >>>
> >>>> -----Message d'origine-----
> >>>> De : Teas <teas-bounces@ietf.org> De la part de Adrian Farrel
> >>>> Envoyé
> >>>> : mercredi 23 mars 2022 14:47 À : 'TEAS WG' <teas@ietf.org> Objet :
> >>>> [Teas] What SLOs and SLEs should be in the Slicing Service Model?
> >>>>
> >>>> Hi,
> >>>>
> >>>> Sorry for my audio being a mess in TEAS today.
> >>>>
> >>>> I believe I heard the discussion between Kireeti and Reza
> >>>> correctly, and there was some follow-up in the chat.
> >>>>
> >>>> I agree that "Protection" is a realisation feature and so it
> >>>> qualifies as an SLE, if at all.
> >>>> But "Reliability" is clearly an SLO. Usually expressed as maximum
> >>>> down- time per unit of time, or maximum lost traffic.
> >>>>
> >>>> There was one thing that I *think* I heard. This was Reza saying
> >>>> that the service YANG model was only including the SLOs and SLEs
> >>>> noted in the framework. Maybe I misheard "only" because I think
> >>>> that might be a mistake.
> >>>> The YANG model should certainly be interested in what the framework
> >>>> says, but it is not a requirement that all SLOs and SLEs in the
> >>>> framework be in the model if the authors find that there is no
> >>>> interest in implementing them, and there should certainly be no
> >>>> limitation about including additional SLOs or SLEs in the YANG model.
> >>>> Indeed, the SLOs and SLEs listed in the framework are presented as
> >> examples.
> >>>>
> >>>> Cheers,
> >>>> Adrian
> >>>>
> >>>> _______________________________________________
> >>>> Teas mailing list
> >>>> Teas@ietf.org
> >>>> 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.
> >>>
> >>> _______________________________________________
> >>> Teas mailing list
> >>> Teas@ietf.org
> >>> 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.
> >

_________________________________________________________________________________________________________________________

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.