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

[Gyan Mishra <[e-mail]>]

Adrian

I agree 4.1.2 is sufficient.   No need to add any additional verbiage.
Sorry I had accidentally missed reading that section.

Thanks

Gyan
On Fri, Mar 25, 2022 at 5:45 PM John E Drake <[e-mail]> wrote:

> I think the current description of SLEs is just fine.
>
> Sent from my iPhone
>
> On Mar 25, 2022, at 5:32 PM, Gyan Mishra <[e-mail]> wrote:
>
> 
>
> [External Email. Be cautious of content]
>
>
> H Adrian,
>
> The example Joel gave is the perfect one which made me think maybe help
> make the verbiage clearer maybe using the word like Network parameter,
> feature or option.
>
>  A Service Level Expectation (SLE) is an expression of an  unmeasurable
> service-related request that may consist of various network parameters,
> features or options that a customer of an IETF Network Slice makes of the
> provider.
>
> How does that sound?
>
> Gyan
> On Fri, Mar 25, 2022 at 5:21 PM Adrian Farrel <[e-mail]> wrote:
>
>> I'd be happy to clarify the verbiage, but re-reading, I can't reach the
>> conclusion that Gyan does. That makes it hard to find other words that
>> convey the meaning more clearly.
>>
>> Obviously, the quoted text (from 4.1) is far briefer than the description
>> in 4.1.2 and reading that might help understanding the concepts.
>>
>> Cheers,
>> Adrian
>>
>> -----Original Message-----
>> From: Joel M. Halpern <[e-mail]>
>> Sent: 25 March 2022 19:52
>> To: Gyan Mishra <[e-mail]>
>> Cc: TEAS WG <[e-mail]>; [e-mail]
>> Subject: Re: [Teas] What SLOs and SLEs should be in the Slicing Service
>> Model?
>>
>> Sounds like we need to clarify the verbiage.  SLEs are, as I understand
>> it, indeed non-measurables.  But they are not the legal translation of
>> the SLOs.  They are expression of customer expectations that are not
>> directly observable or measurable.  The example I have the easiest time
>> understanding is that the customer expects the operator to encrypt the
>> traffic across the service.
>>
>> Yours,
>> Joel
>>
>> On 3/25/2022 3:07 PM, Gyan Mishra wrote:
>> > Hi Med & Joel
>> >
>> > I reread section 4.1 of the slice draft and to me it seems that SLO is
>> > from provider POV measurable indicators and SLE is the is unmeasurable
>> > expectations which is makes up the customer fulfillment of obligations
>> > by the provider which would be like taking the tangible measurement
>> > characteristics from the SLO and translation into legal obligation
>> > fulfillment verbiage that goes into the service agreement.  So as the
>> > SLE is not tangible but just a translation of SLO metrics into legal
>> > verbiage my thoughts are that the framework as well as Yang model need
>> > only focus on the SLO tangible metrics and leave the intangible for the
>> > lawyers writing the customer agreement.
>> >
>> >
>> > 4.1
>> > <
>> https://datatracker.ietf.org/doc/html/draft-ietf-teas-ietf-network-slices-09#section-4.1
>> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-teas-ietf-network-slices-09*section-4.1__;Iw!!NEt6yMaO-gk!VyA-wdultN0v5bUcPbYNYtkg4CAz4hFShL7abxoSjFBoKcNTm1gVTNXMwZlkgrU$>>.
>>
>> > Objectives for IETF Network Slices
>> >
>> >     An IETF Network Slice service is defined in terms of quantifiable
>> >     characteristics known as Service Level Objectives (SLOs) and
>> >     unquantifiable characteristics known as Service Level Expectations
>> >     (SLEs).  SLOs are expressed in terms Service Level Indicators
>> (SLIs),
>> >     and together with the SLEs form the contractual agreement between
>> >     service customer and service provider known as a Service Level
>> >     Agreement (SLA).
>> >
>> >     The terms are defined as follows:
>> >
>> >     *  A Service Level Indicator (SLI) is a quantifiable measure of an
>> >        aspect of the performance of a network.  For example, it may be a
>> >        measure of throughput in bits per second, or it may be a measure
>> >        of latency in milliseconds.
>> >
>> >     *  A Service Level Objective (SLO) is a target value or range for
>> the
>> >        measurements returned by observation of an SLI.  For example, an
>> >        SLO may be expressed as "SLI <= target", or "lower bound <= SLI
>> <=
>> >        upper bound".  A customer can determine whether the provider is
>> >        meeting the SLOs by performing measurements on the traffic.
>> >
>> >     *  A Service Level Expectation (SLE) is an expression of an
>> >        unmeasurable service-related request that a customer of an IETF
>> >        Network Slice makes of the provider.  An SLE is distinct from an
>> >        SLO because the customer may have little or no way of determining
>> >        whether the SLE is being met, but they still contract with the
>> >        provider for a service that meets the expectation.
>> >
>> >
>> >
>> > On Thu, Mar 24, 2022 at 10:36 AM <[e-mail]
>> > <mailto:[e-mail]>> wrote:
>> >
>> >     Re-,
>> >
>> >     They shouldn't!
>> >
>> >     This is why I'm suggesting to not have that tagging frozen in the
>> >     model. We can simply have a provision for a set of parameters. These
>> >     parameters will be included to characterize the service with a
>> >     service assurance component that will call out the identity of the
>> >     subset of parameters that will be used as committed ones. That
>> >     component will also include other data to ensure the same based used
>> >     for assessment, etc.
>> >
>> >     Cheers,
>> >     Med
>> >
>> >      > -----Message d'origine-----
>> >      > De : Joel M. Halpern <[e-mail]
>> >     <mailto:[e-mail]>>
>> >      > Envoyé : jeudi 24 mars 2022 15:29
>> >      > À : BOUCADAIR Mohamed INNOV/NET <[e-mail]
>> >     <mailto:[e-mail]>>
>> >      > Cc : 'TEAS WG' <[e-mail] <mailto:[e-mail]>>;
>> >     [e-mail] <mailto:[e-mail]>
>> >      > Objet : Re: [Teas] What SLOs and SLEs should be in the Slicing
>> >     Service
>> >      > Model?
>> >      >
>> >      > If the others are best effort, why would they be included in the
>> SLO?
>> >      > (We do not assume that every IETF network slice service will
>> >     specify all
>> >      > possible parameters.)
>> >      >
>> >      > Yours,
>> >      > Joel
>> >      >
>> >      > On 3/24/2022 10:20 AM, [e-mail]
>> >     <mailto:[e-mail]> wrote:
>> >      > > 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 <[e-mail]
>> >     <mailto:[e-mail]>> Envoyé : jeudi 24 mars
>> >      > >> 2022 15:07 À : BOUCADAIR Mohamed INNOV/NET
>> >      > >> <[e-mail]
>> >     <mailto:[e-mail]>> Cc : 'TEAS WG' <
>> [e-mail]
>> >     <mailto:[e-mail]>>;
>> >      > >> [e-mail] <mailto:[e-mail]> 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, [e-mail]
>> >     <mailto:[e-mail]> 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 <[e-mail]
>> >     <mailto:[e-mail]>> Envoyé : jeudi 24 mars
>> >      > >>>> 2022 14:52 À : BOUCADAIR Mohamed INNOV/NET
>> >      > >>>> <[e-mail]
>> >     <mailto:[e-mail]>>; [e-mail]
>> >     <mailto:[e-mail]>; 'TEAS WG'
>> >      > >>>> <[e-mail] <mailto:[e-mail]>> 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, [e-mail]
>> >     <mailto:[e-mail]> 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 <[e-mail]
>> >     <mailto:[e-mail]>> De la part de Adrian Farrel
>> >      > >>>>>> Envoyé
>> >      > >>>>>> : mercredi 23 mars 2022 14:47 À : 'TEAS WG' <
>> [e-mail]
>> >     <mailto:[e-mail]>> 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
>> >      > >>>>>> [e-mail] <mailto:[e-mail]>
>> >      > >>>>>> https://www.ietf.org/mailman/listinfo/teas
>> <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!VyA-wdultN0v5bUcPbYNYtkg4CAz4hFShL7abxoSjFBoKcNTm1gVTNXMxfvzL-o$>
>> >     <https://www.ietf.org/mailman/listinfo/teas
>> <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!VyA-wdultN0v5bUcPbYNYtkg4CAz4hFShL7abxoSjFBoKcNTm1gVTNXMxfvzL-o$>
>> >
>> >      > >>>>>
>> >      > >>>>>
>> >     __________________________________________________________________
>> >      > >>>>> __ __ ___________________________________________________
>> >      > >>>>>
>> >      > >>>>> 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
>> <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!VyA-wdultN0v5bUcPbYNYtkg4CAz4hFShL7abxoSjFBoKcNTm1gVTNXMxfvzL-o$>
>> >     <https://www.ietf.org/mailman/listinfo/teas
>> <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!VyA-wdultN0v5bUcPbYNYtkg4CAz4hFShL7abxoSjFBoKcNTm1gVTNXMxfvzL-o$>
>> >
>> >      > >>>
>> >      > >>>
>> >     ____________________________________________________________________
>> >      > >>> __ ___________________________________________________
>> >      > >>>
>> >      > >>> 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.
>> >      > >
>> >
>> >
>>  _________________________________________________________________________________________________________________________
>> >
>> >     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
>> <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!VyA-wdultN0v5bUcPbYNYtkg4CAz4hFShL7abxoSjFBoKcNTm1gVTNXMxfvzL-o$>
>> >     <https://www.ietf.org/mailman/listinfo/teas
>> <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!VyA-wdultN0v5bUcPbYNYtkg4CAz4hFShL7abxoSjFBoKcNTm1gVTNXMxfvzL-o$>
>> >
>> >
>> > --
>> >
>> > <http://www.verizon.com/
>> <https://urldefense.com/v3/__http://www.verizon.com/__;!!NEt6yMaO-gk!VyA-wdultN0v5bUcPbYNYtkg4CAz4hFShL7abxoSjFBoKcNTm1gVTNXMJg9VpsI$>
>> >
>> >
>> > *Gyan Mishra*
>> >
>> > /Network Solutions A//rchitect /
>> >
>> > /Email [e-mail] <mailto:[e-mail]>//
>> > /
>> >
>> > /M 301 502-1347
>> >
>> > /
>> >
>> >
>>
>> --
>
>
> <https://urldefense.com/v3/__http://www.verizon.com/__;!!NEt6yMaO-gk!VyA-wdultN0v5bUcPbYNYtkg4CAz4hFShL7abxoSjFBoKcNTm1gVTNXMJg9VpsI$>
>
> *Gyan Mishra*
>
> *Network Solutions A**rchitect *
>
> *Email [e-mail] <[e-mail]>*
>
>
>
> *M 301 502-1347 *
>
> _______________________________________________
> Teas mailing list
> [e-mail]
>
>
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!VyA-wdultN0v5bUcPbYNYtkg4CAz4hFShL7abxoSjFBoKcNTm1gVTNXMxfvzL-o$
>
> --

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [e-mail] <[e-mail]>*



*M 301 502-1347*