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

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 23 Mar 2022 13:46:54 -0000

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

---

From: <[email-masked]>
Date: Wed, 23 Mar 2022 14:08:11 +0000

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 <[email-masked]> De la part de Adrian Farrel
> Envoyé : mercredi 23 mars 2022 14:47
> À : 'TEAS WG' <[email-masked]>
> Objet : [Teas] What SLOs and SLEs should be in the Slicing Service
> Model?
> 
> Hi,
> 
> 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
> 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
> [email-masked]
> 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.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 24 Mar 2022 09:51:49 -0400

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

---

From: <[email-masked]>
Date: Thu, 24 Mar 2022 14:03:48 +0000

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

> De : Joel M. Halpern <[email-masked]>
> Envoyé : jeudi 24 mars 2022 14:52
> À : BOUCADAIR Mohamed INNOV/NET <[email-masked]>;
> [email-masked]; 'TEAS WG' <[email-masked]>
> 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
> 
> > 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:
> >
> > "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
> >
> >> De : Teas <[email-masked]> De la part de Adrian Farrel Envoyé
> >> : mercredi 23 mars 2022 14:47 À : 'TEAS WG' <[email-masked]> Objet :
> >> [Teas] What SLOs and SLEs should be in the Slicing Service Model?
> >>
> >> Hi,
> >>
> >> 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.
> >>
> >> 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.
> >> 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
> >>
> > ______________________________________________________________________
> > ___________________________________________________
> >
> > 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.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 24 Mar 2022 10:06:33 -0400

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

---

From: <[email-masked]>
Date: Thu, 24 Mar 2022 14:20:23 +0000

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

> Envoyé : jeudi 24 mars 2022 15:07
> À : BOUCADAIR Mohamed INNOV/NET <[email-masked]>
> Cc : 'TEAS WG' <[email-masked]>; [email-masked]
> 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
> 
> > 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
> >
> >> De : Joel M. Halpern <[email-masked]> Envoyé : jeudi 24 mars
> >> 2022 14:52 À : BOUCADAIR Mohamed INNOV/NET
> >> <[email-masked]>; [email-masked]; 'TEAS WG'
> >> <[email-masked]> 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
> >>
> >> taxonomy. From the service modeling standpoint, I suggest that we
> >> don't inherit that taxonomy for various reasons:
> >>>
> >> 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.
> >>>
> >> 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).
> >>>
> >> SLE/SLO indicators and I totally agreed with your comments on
> >> draft-wd- teas-ietf-network-slice-nbi-yang-03"
> >>> ==
> >>>
> >>> Cheers,
> >>> Med
> >>>
> >>>> Envoyé
> >>>> I believe I heard the discussion between Kireeti and Reza
> >>>> correctly, and there was some follow-up in the chat.
> >>>>
> >>>> 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.
> >>> ____________________________________________________________________
> >>> __ ___________________________________________________
> >>>
> >>> 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
> >>> 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.
> >>>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 24 Mar 2022 10:28:46 -0400

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

---

From: <[email-masked]>
Date: Thu, 24 Mar 2022 14:35:46 +0000

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

> Envoyé : jeudi 24 mars 2022 15:29
> > 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
> >
> >> 2022 15:07 À : BOUCADAIR Mohamed INNOV/NET
> >> <[email-masked]> Cc : 'TEAS WG' <[email-masked]>;
> >> [email-masked] Objet : Re: [Teas] What SLOs and SLEs should be
> >> in the Slicing Service Model?
> >>
> coupled.
> >> I had leapt to the (quite possibly incorrect) conclusion that the two
> >> sets of properties went together.
> >>
> >> Thank you,
> >> Joel
> >>
> >> 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
> >>>
> >>>> 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
> >>>>
> >>>> 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).
> >>>>>
> >>>>>> 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.
> >>>>> __________________________________________________________________
> >>>>> __ __ ___________________________________________________
> >>>>>
> >>>> d'alteration, Orange decline toute responsabilite si ce message a
> >>>> ete altere, deforme ou falsifie. Merci.
> >>>>>

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 25 Mar 2022 15:07:49 -0400

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>.
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 <[email-masked]> 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
>
> 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,
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 25 Mar 2022 15:52:20 -0400

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 
> 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>. 
> On Thu, Mar 24, 2022 at 10:36 AM <[email-masked] 
> <mailto:[email-masked]>> 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
> 
>      > De : Joel M. Halpern <[email-masked]
>     <mailto:[email-masked]>>
>      > À : BOUCADAIR Mohamed INNOV/NET <[email-masked]
>     <mailto:[email-masked]>>
>      > Cc : 'TEAS WG' <[email-masked] <mailto:[email-masked]>>;
>     [email-masked] <mailto:[email-masked]>
>      > On 3/24/2022 10:20 AM, [email-masked]
>     <mailto:[email-masked]> wrote:
>      > > Re-,
>      > >
>      > >> De : Joel M. Halpern <[email-masked]
>     <mailto:[email-masked]>> Envoyé : jeudi 24 mars
>      > >> <[email-masked]
>     <mailto:[email-masked]>> Cc : 'TEAS WG' <[email-masked]
>     <mailto:[email-masked]>>;
>      > >> [email-masked] <mailto:[email-masked]> Objet : Re:
>      > >> On 3/24/2022 10:03 AM, [email-masked]
>     <mailto:[email-masked]> wrote:
>      > >>> Hi Joel,
>      > >>>
>      > >>> It is.
>      > >>>
>      > >>>> De : Joel M. Halpern <[email-masked]
>     <mailto:[email-masked]>> Envoyé : jeudi 24 mars
>      > >>>> <[email-masked]
>     <mailto:[email-masked]>>; [email-masked]
>     <mailto:[email-masked]>; 'TEAS WG'
>      > >>>> <[email-masked] <mailto:[email-masked]>> Objet : Re: [Teas]
>     What SLOs and SLEs should be in
>      > >>>> On 3/23/2022 10:08 AM, [email-masked]
>     <mailto:[email-masked]> wrote:
>      > >>>>> Hi all,
>      > >>>>>
>      > >>>>> This message actually triggers a companion comment I have
>     on the
>      > >>>>> SLO/SLE
>      > >>>> whether it is
>     quantified/quantitative/qualitative/measurable/etc.
>      > >>>> the data model when we were discussing the call for adoption
>     of the
>      > >>>> slice
>      > >>>> definition:
>      > >>>>>
>      > >>>>>> De : Teas <[email-masked]
>     <mailto:[email-masked]>> De la part de Adrian Farrel
>      > >>>>>> Envoyé
>      > >>>>>> : mercredi 23 mars 2022 14:47 À : 'TEAS WG' <[email-masked]
>     <mailto:[email-masked]>> Objet :
>      > >>>>>> Indeed, the SLOs and SLEs listed in the framework are
>     presented
>      > >>>>>> as
>      > >>>> examples.
>      > >>>>>>
>      > >>>>>> Cheers,
>      > >>>>>> Adrian
>      > >>>>>>
>      > >>>>>> [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/teas>
>      > >>>>>
>      > >>>>>
>      > >>>>> privileged information that may be protected by law; they
>     should
>      > >>>>> not be
>      > >>>>> [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/teas>
>      > >>>
>      > >>>
>      > >>> privileged information that may be protected by law; they
>     should not
>      > >>> be
>     diffuses,
>      > > If you have received this email in error, please notify the
>     sender and
>      > > As emails may be altered, Orange is not liable for messages
>     that have
>     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,
>     privileged information that may be protected by law;
>     and delete this message and its attachments.
>     have been modified, changed or falsified.
>     Thank you.
> 
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/teas>
> 
> -- 
> 
> /Network Solutions A//rchitect /
> 
> /Email [email-masked] <mailto:[email-masked]>//
> /
> 
> /M 301 502-1347
> 
> /
> 
>

---

From: "Jalil, Luay" <[email-masked]>
Date: Fri, 25 Mar 2022 20:09:51 +0000

Agree with Joel. Providers can look at SLOs & SLEs and decide what goes in
the SLA (legal agreement)

Regards,
Luay

On Fri, Mar 25, 2022, 7:52 PM Joel M. Halpern <[email-masked]> wrote:

> > <
> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dietf-2Dteas-2Dietf-2Dnetwork-2Dslices-2D09-23section-2D4.1&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=k0DrrBeS0St-D1jEwNQ_u1ZyHQXQly5fgCsWF0VTh7o&m=J9C0uO0pyymUD5TiJjBzWVIBLtm6tjJWU_KbStCzl45FBHTa6b70W0rrKaqLhnKA&s=_9k1Nl-OUCyzLyrk4L_1Zs3rtdk6_Z_-D0_pTvR6Fko&e=
> >.
> >      > >>>>> * We are artificially adding extra complexity for the
> modelling
> >      > >>>>> part as
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_teas&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=k0DrrBeS0St-D1jEwNQ_u1ZyHQXQly5fgCsWF0VTh7o&m=J9C0uO0pyymUD5TiJjBzWVIBLtm6tjJWU_KbStCzl45FBHTa6b70W0rrKaqLhnKA&s=UtvLV-EiyvqFiTqhgtj81sOzi0cgp2N7loVPcL_2FN0&e=
> >     <
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_teas&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=k0DrrBeS0St-D1jEwNQ_u1ZyHQXQly5fgCsWF0VTh7o&m=J9C0uO0pyymUD5TiJjBzWVIBLtm6tjJWU_KbStCzl45FBHTa6b70W0rrKaqLhnKA&s=UtvLV-EiyvqFiTqhgtj81sOzi0cgp2N7loVPcL_2FN0&e=
> >
> >      > >>>>>
> >      > >>>>>
> >     sender
> >     that
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_teas&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=k0DrrBeS0St-D1jEwNQ_u1ZyHQXQly5fgCsWF0VTh7o&m=J9C0uO0pyymUD5TiJjBzWVIBLtm6tjJWU_KbStCzl45FBHTa6b70W0rrKaqLhnKA&s=UtvLV-EiyvqFiTqhgtj81sOzi0cgp2N7loVPcL_2FN0&e=
> >     <
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_teas&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=k0DrrBeS0St-D1jEwNQ_u1ZyHQXQly5fgCsWF0VTh7o&m=J9C0uO0pyymUD5TiJjBzWVIBLtm6tjJWU_KbStCzl45FBHTa6b70W0rrKaqLhnKA&s=UtvLV-EiyvqFiTqhgtj81sOzi0cgp2N7loVPcL_2FN0&e=
> >
> >      > >>>
> >      > >>>
> >     sender
> that
> >     should not be
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_teas&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=k0DrrBeS0St-D1jEwNQ_u1ZyHQXQly5fgCsWF0VTh7o&m=J9C0uO0pyymUD5TiJjBzWVIBLtm6tjJWU_KbStCzl45FBHTa6b70W0rrKaqLhnKA&s=UtvLV-EiyvqFiTqhgtj81sOzi0cgp2N7loVPcL_2FN0&e=
> >     <
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_teas&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=k0DrrBeS0St-D1jEwNQ_u1ZyHQXQly5fgCsWF0VTh7o&m=J9C0uO0pyymUD5TiJjBzWVIBLtm6tjJWU_KbStCzl45FBHTa6b70W0rrKaqLhnKA&s=UtvLV-EiyvqFiTqhgtj81sOzi0cgp2N7loVPcL_2FN0&e=
> >
> >
> > --
> >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_teas&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=k0DrrBeS0St-D1jEwNQ_u1ZyHQXQly5fgCsWF0VTh7o&m=J9C0uO0pyymUD5TiJjBzWVIBLtm6tjJWU_KbStCzl45FBHTa6b70W0rrKaqLhnKA&s=UtvLV-EiyvqFiTqhgtj81sOzi0cgp2N7loVPcL_2FN0&e=
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 25 Mar 2022 21:21:41 -0000

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 <[email-masked]> 
Sent: 25 March 2022 19:52
To: Gyan Mishra <[email-masked]>
Cc: TEAS WG <[email-masked]>; [email-masked]
Subject: Re: [Teas] What SLOs and SLEs should be in the Slicing Service Model?

Yours,
Joel

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 25 Mar 2022 17:31:42 -0400

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 <[email-masked]> 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
>
> https://datatracker.ietf.org/doc/html/draft-ietf-teas-ietf-network-slices-09#section-4.1>.
>

*Gyan Mishra*

*M 301 502-1347*

---

From: John E Drake <[email-masked]>
Date: Fri, 25 Mar 2022 21:45:40 +0000

I think the current description of SLEs is just fine.

Sent from my iPhone

On Mar 25, 2022, at 5:32 PM, Gyan Mishra <[email-masked]> 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 <[email-masked]<mailto:[email-masked]>> 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.

Cheers,
Adrian

-----Original Message-----
From: Joel M. Halpern <[email-masked]<mailto:[email-masked]>>
Sent: 25 March 2022 19:52
To: Gyan Mishra <[email-masked]<mailto:[email-masked]>>
Cc: TEAS WG <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Teas] What SLOs and SLEs should be in the Slicing Service Model?

Yours,
Joel

On 3/25/2022 3:07 PM, Gyan Mishra wrote:
> <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$>>.
> On Thu, Mar 24, 2022 at 10:36 AM <[email-masked]<mailto:[email-masked]>
> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>
>     Re-,
>
>     They shouldn't!
>
>      > De : Joel M. Halpern <[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>>
>      > À : BOUCADAIR Mohamed INNOV/NET <[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>>
>      > Cc : 'TEAS WG' <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>;
>     [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>      > On 3/24/2022 10:20 AM, [email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>> wrote:
>      > > Re-,
>      > >
>      > >> De : Joel M. Halpern <[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>> Envoyé : jeudi 24 mars
>      > >> <[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>> Cc : 'TEAS WG' <[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>>;
>      > >> [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>> Objet : Re:
>      > >> On 3/24/2022 10:03 AM, [email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>> wrote:
>      > >>> Hi Joel,
>      > >>>
>      > >>> It is.
>      > >>>
>      > >>>> De : Joel M. Halpern <[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>> Envoyé : jeudi 24 mars
>      > >>>> <[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>>; [email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>; 'TEAS WG'
>      > >>>> <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>> Objet : Re: [Teas]
>      > >>>> On 3/23/2022 10:08 AM, [email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>> wrote:
>      > >>>>> Hi all,
>      > >>>>>
>      > >>>>>> De : Teas <[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>> De la part de Adrian Farrel
>      > >>>>>> Envoyé
>      > >>>>>> : mercredi 23 mars 2022 14:47 À : 'TEAS WG' <[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>> Objet :
>      > >>>>>> [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>      > >>>>>> 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$>>
>      > >>>>>
>      > >>>>>
>      > >>>>> [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>      > >>>>> 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$>>
>      > >>>
>      > >>>
>     [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>     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*
>
> /Email [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>//
> /
>
> /M 301 502-1347
>
> /
>
>

--

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<https://urldefense.com/v3/__http://www.verizon.com/__;!!NEt6yMaO-gk!VyA-wdultN0v5bUcPbYNYtkg4CAz4hFShL7abxoSjFBoKcNTm1gVTNXMJg9VpsI$>

Gyan Mishra

Network Solutions Architect

Email [email-masked]<mailto:[email-masked]>

M 301 502-1347

_______________________________________________
Teas mailing list
[email-masked]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!VyA-wdultN0v5bUcPbYNYtkg4CAz4hFShL7abxoSjFBoKcNTm1gVTNXMxfvzL-o$

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 25 Mar 2022 17:52:22 -0400

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 <[email-masked]> wrote:

>> 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$>>.
>>
>> <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$>
>> >
>> >      > >>>>>
>> >      > >>>>>
>> <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$>
>> >
>> >      > >>>
>> >      > >>>
>> <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*
>> >
> <https://urldefense.com/v3/__http://www.verizon.com/__;!!NEt6yMaO-gk!VyA-wdultN0v5bUcPbYNYtkg4CAz4hFShL7abxoSjFBoKcNTm1gVTNXMJg9VpsI$>
>
> *Gyan Mishra*
>
> *M 301 502-1347 *

*Gyan Mishra*

*M 301 502-1347*

---

From: John E Drake <[email-masked]>
Date: Fri, 25 Mar 2022 21:54:58 +0000

Did we not make it clear that SLOs and SLEs are used to create an SLA?

Yours Irrespectively,

John

Juniper Business Use Only

> From: Teas <[email-masked]> On Behalf Of Joel M. Halpern
> Sent: Friday, March 25, 2022 3:52 PM
> Cc: [email-masked]; TEAS WG <[email-masked]>
> 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
> 
> > only focus on the SLO tangible metrics and leave the intangible for
> > the lawyers writing the customer agreement.
> >
> >
> > 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!VrEVB46KF20816iW_4FlbM4JGWGSLyFu-vk4PGWX_-
> LiOR92MnzCJzyL9ESsViw$ >.
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;!!N
> Et6yMaO-gk!VrEVB46KF20816iW_4FlbM4JGWGSLyFu-vk4PGWX_-
> LiOR92MnzCJzyLzCREI4M$
> >
> <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;!!
> NEt6yMaO-gk!VrEVB46KF20816iW_4FlbM4JGWGSLyFu-vk4PGWX_-
> LiOR92MnzCJzyLzCREI4M$ >
> >      > >>>>>
> >      > >>>>>
> >
> >      > >>>>> __ __
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;!!N
> Et6yMaO-gk!VrEVB46KF20816iW_4FlbM4JGWGSLyFu-vk4PGWX_-
> LiOR92MnzCJzyLzCREI4M$
> >
> <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;!!
> NEt6yMaO-gk!VrEVB46KF20816iW_4FlbM4JGWGSLyFu-vk4PGWX_-
> LiOR92MnzCJzyLzCREI4M$ >
> >      > >>>
> >      > >>>
> >
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;!!N
> Et6yMaO-gk!VrEVB46KF20816iW_4FlbM4JGWGSLyFu-vk4PGWX_-
> LiOR92MnzCJzyLzCREI4M$
> >
> > <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/tea
> > s__;!!NEt6yMaO-gk!VrEVB46KF20816iW_4FlbM4JGWGSLyFu-vk4PGWX_-
> LiOR92MnzC
> > JzyLzCREI4M$ >
> >
> > --
> >
> > <https://urldefense.com/v3/__http://www.verizon.com/__;!!NEt6yMaO-gk!V
> > rEVB46KF20816iW_4FlbM4JGWGSLyFu-vk4PGWX_-LiOR92MnzCJzyLqOCoT3c$
> >
> >
> > *Gyan Mishra*
> >
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;!!N
> Et6yMaO-gk!VrEVB46KF20816iW_4FlbM4JGWGSLyFu-vk4PGWX_-
> LiOR92MnzCJzyLzCREI4M$

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 25 Mar 2022 20:16:37 -0400

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***

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

On Fri, Mar 25, 2022 at 5:55 PM John E Drake <[email-masked]> wrote:

> it, indeed
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-
> > >      > request may include (for whatever reason) not only the delay,
> but
> > >     also
> > >      > provider is requested to only commit on the delay and best
> effort
> > >     for the
> > >      > other attributes.
> > >      > >
> > >      > > Cheers,
> > >      > > Med
> > >      > >
> > >      > >> there is deployment-specific. Not all parameters tagged as
> SLO
> > >     in the
> > >      > >>>>> * What we may tag as an SLE today because of the
> technology
> > >      > >>>>> limitations,
> > >      > >>>>>> [Teas] What SLOs and SLEs should be in the Slicing
> Service
> > >     Model?
> > >      > >>>>>>
> > >      > >>>>>> Hi,
> > >      > >>>>>>
> > >      > >>>>>> certainly be no limitation about including additional
> SLOs
> > >     or SLEs
> > >      > in the YANG model.
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;
> !!
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;
> !!
> > >      > >>> diffuses, exploites ou copies sans autorisation. Si vous
> avez
> > >     recu

-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: John E Drake <[email-masked]>
Date: Sat, 26 Mar 2022 15:35:35 +0000

Hi,

Comments inline below.

Yours Irrespectively,

John

Juniper Business Use Only
From: Gyan Mishra <[email-masked]>
Sent: Friday, March 25, 2022 8:17 PM
To: John E Drake <[email-masked]>
Cc: Joel M. Halpern <[email-masked]>; [email-masked]; TEAS WG <[email-masked]>
Subject: 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.

[JD]  Protection is actually a technique that a service provider may use to provide reliability

[JD]  Do you have any in mind?

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

[JD]  Correct.  I think this argues against a characteristic that can be both an SLO and an 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.

[JD]  I would love to hear of a characteristic which is both.  If we find any we can deal with them

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.

[JD]  That's fine, but  1) there was never any intention to enumerate all possible characteristics, which is probably impossible, and tag each as either an SLO or an SLE and 2)  the set of SLOs and SLEs negotiated between a customer and its service provider(s) is ultimately a matter between them;  i.e., it is not a matter in which we are involved

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

[JD]  See above

[JD]  I agree with the second statement, above, but since we are simply trying to introduce the concepts of SLO and SLE, which are clearly different, and not enumerate all possible characteristics and tag each as being either an SLO or an SLE, I think it's largely irrelevant

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

On Fri, Mar 25, 2022 at 5:55 PM John E Drake <[email-masked]<mailto:[email-masked]>> wrote:
Did we not make it clear that SLOs and SLEs are used to create an SLA?

Yours Irrespectively,

John

> From: Teas <[email-masked]<mailto:[email-masked]>> On Behalf Of Joel M. Halpern
> Cc: [email-masked]<mailto:[email-masked]>; TEAS WG <[email-masked]<mailto:[email-masked]>>
> > <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft->
> >      > À : BOUCADAIR Mohamed INNOV/NET
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;!!N<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!N>
> <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;>!!
> >     avez recu
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;!!N<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!N>
> <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;>!!
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;!!N<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!N>
> > <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/tea<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/tea>
> > <https://urldefense.com/v3/__http://www.verizon.com/__;!!NEt6yMaO-gk!V<https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!V>
> [email-masked]<mailto:[email-masked]>
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;!!N<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!N>

--

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!RvVLz0GpjIyf2oVvTxnMgHzO5_TsnvXLYRGzpTsQSjwAIOP5-Q9vlZiJlwa0Nuw$>

Gyan Mishra

M 301 502-1347

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 26 Mar 2022 15:18:41 -0400

Hi John

Comments in-line

Kind Regards

Gyan

On Sat, Mar 26, 2022 at 11:35 AM John E Drake <[email-masked]> wrote:

> *From:* Gyan Mishra <[email-masked]>
> *Sent:* Friday, March 25, 2022 8:17 PM
> *To:* John E Drake <[email-masked]>
> *Cc:* Joel M. Halpern <[email-masked]>; [email-masked]; TEAS WG
> <[email-masked]>
> *Subject:* Re: [Teas] What SLOs and SLEs should be in the Slicing Service
> Model?
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> John / All
>
>
>
> *[JD]  Protection is actually a technique that a service provider may use
> to provide reliability*
>
>
>
     Gyan>  I think most of the SLEs are options or parameters that are
provisioned and realized by the provider.

> *[JD]  Do you have any in mind?*
>
>  Gyan> After thinking about it further the definitions of SLE and SLO is
> very clear and I think one key point is that SLO is “directly” measurable
> as which more a L1 characteristic of the slice where the ones which I might
> think maybe in that gray area are not directly measurable for example
> protection.  Protection during a failure the result on the 1+1 protected
> link is 0 packet loss which is realized by the provider and that
> realization is in the SLE description.  So the definition is very clear.
>
> *[JD]  Correct.  I think this argues against a characteristic that can be
> both an SLO and an SLE *
>
>  Gyan> I completely agree it’s impossible for characteristic to be both an
> SLO and SLE
>
> *[JD]  I would love to hear of a characteristic which is both.  If we find
> any we can deal with them *
>
>  Gyan> Agreed.  I think the directly measurable and being a “L1
> characteristic” it is crystal clear and that does make it quite clear and
> in my mind difficult to find one but as you stated we can deal with them if
> it comes up.
>
> *[JD]  That’s fine, but  1) there was never any intention to enumerate all
> possible characteristics, which is probably impossible, and tag each as
> either an SLO or an SLE and 2)  the set of SLOs and SLEs negotiated between
> a customer and its service provider(s) is ultimately a matter between
> them;  i.e., it is not a matter in which we are involved*
>
>  Gyan> Understood and agreed.  The key is defining what an SLO and SLE is
> utmost importance over listing an exhaustive list.  With the clear
> definition gives the reader of the specification a solid understanding so
> no room for misinterpretation.  I believe the we have all done a excellent
> job many thanks to the WG!
>
> *[JD]  See above*

     Gyan> Agreed on this point

> may not stay as such forever.
>
     Gyan> I think this is doubtful to happen but if it does we can deal
with it at that time

> 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).
>
     Gyan> With the definition of SLO being directly measurable and a L1
slice characteristic there are only so many today and the common ones which
seems to be the current exhaustive are already listed.  I guess it’s
possible with a new technology could yield a new type of L1 slice
characteristic that is measurable and then that SLE would become an SLO.
It’s possible.  I don’t think that impacts the draft in any way and SLOs
and SLE can in theory slide back and forth based on our definition and that
is not an issue in my mind.

> *[JD]  I agree with the second statement, above, but since we are simply
> trying to introduce the concepts of SLO and SLE, which are clearly
> different, and not enumerate all possible characteristics and tag each as
> being either an SLO or an SLE, I think it’s largely irrelevant*
>
>  Gyan> Agreed
>
>  Gyan> I am all set.  Thanks!
>
> Kind Regards
>
>
>
> Gyan
>
>
>
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft->
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!N>
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;>
> !!
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!N>
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;>
> !!
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!N>
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/tea>
> <https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!V>
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!N>
> <https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!RvVLz0GpjIyf2oVvTxnMgHzO5_TsnvXLYRGzpTsQSjwAIOP5-Q9vlZiJlwa0Nuw$>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: John E Drake <[email-masked]>
Date: Sat, 26 Mar 2022 19:59:40 +0000

Gyan,

You are most welcome, a very thoughtful email exchange.

Yours Irrespectively,

John

Juniper Business Use Only
From: Gyan Mishra <[email-masked]>
Sent: Saturday, March 26, 2022 3:19 PM
To: John E Drake <[email-masked]>
Cc: Joel M. Halpern <[email-masked]>; TEAS WG <[email-masked]>; [email-masked]
Subject: Re: [Teas] What SLOs and SLEs should be in the Slicing Service Model?

Hi John

Comments in-line

Kind Regards

Gyan

On Sat, Mar 26, 2022 at 11:35 AM John E Drake <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Comments inline below.

Yours Irrespectively,

John

Juniper Business Use Only
From: Gyan Mishra <[email-masked]<mailto:[email-masked]>>
Sent: Friday, March 25, 2022 8:17 PM
To: John E Drake <[email-masked]<mailto:[email-masked]>>
Cc: Joel M. Halpern <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; TEAS WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Teas] What SLOs and SLEs should be in the Slicing Service Model?

John / All

     Gyan>  I think most of the SLEs are options or parameters that are provisioned and realized by the provider.
I wonder if there could be characteristics that could be both SLO & SLE?

[JD]  Do you have any in mind?
 Gyan> After thinking about it further the definitions of SLE and SLO is very clear and I think one key point is that SLO is "directly" measurable as which more a L1 characteristic of the slice where the ones which I might think maybe in that gray area are not directly measurable for example protection.  Protection during a failure the result on the 1+1 protected link is 0 packet loss which is realized by the provider and that realization is in the SLE description.  So the definition is very clear.
The term measurable  & unmeasurable realization feature really helps define what characteristics define an SLO or SLE.

[JD]  Correct.  I think this argues against a characteristic that can be both an SLO and an SLE
 Gyan> I completely agree it's impossible for characteristic to be both an SLO and 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.

[JD]  I would love to hear of a characteristic which is both.  If we find any we can deal with them
 Gyan> Agreed.  I think the directly measurable and being a "L1 characteristic" it is crystal clear and that does make it quite clear and in my mind difficult to find one but as you stated we can deal with them if it comes up.
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.

[JD]  That's fine, but  1) there was never any intention to enumerate all possible characteristics, which is probably impossible, and tag each as either an SLO or an SLE and 2)  the set of SLOs and SLEs negotiated between a customer and its service provider(s) is ultimately a matter between them;  i.e., it is not a matter in which we are involved
 Gyan> Understood and agreed.  The key is defining what an SLO and SLE is utmost importance over listing an exhaustive list.  With the clear definition gives the reader of the specification a solid understanding so no room for misinterpretation.  I believe the we have all done a excellent job many thanks to the WG!
Flip side of that is maybe to only spell out the concrete ones that will never change sides.

[JD]  See above

* What we may tag as an SLE today because of the technology limitations, may not stay as such forever.
     Gyan> I think this is doubtful to happen but if it does we can deal with it at that time
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).
     Gyan> With the definition of SLO being directly measurable and a L1 slice characteristic there are only so many today and the common ones which seems to be the current exhaustive are already listed.  I guess it's possible with a new technology could yield a new type of L1 slice characteristic that is measurable and then that SLE would become an SLO.  It's possible.  I don't think that impacts the draft in any way and SLOs and SLE can in theory slide back and forth based on our definition and that is not an issue in my mind.

Gyan

Yours Irrespectively,

John

--

Gyan Mishra

M 301 502-1347

--

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!Xcw8Y3LhBrObKR1EoaHhYpDarWgI4ni7wjPQNo0ArSfU3POeOS1IWUObQBJjUeQ$>

Gyan Mishra

M 301 502-1347

---

From: Greg Mirsky <[email-masked]>
Date: Sat, 26 Mar 2022 13:28:09 -0700

Hi Gyan, et al.,
I want to share my view on one example that is often used in the discussion
of ETF Network Slice SLO/SLE - the protection. I can agree that in a
contract between a client and the service provider protection can be listed
as SLE with its set of parameters that characterize guaranteed failure
detection time and the efficiency of the service switchover (number of
services to be switched over within guaranteed time interval after the
failure detection). At the same time, all that might be left to the service
provider choice as part of the mechanism to deliver service with below the
contracted packet loss ratio SLO. The provider then decides which
protection method to use and how to tune the parameters.
On a side note. DetNet's PREOF guarantees zero packet loss because the
Elimination function accepts all copies of a packet. In the traditional 1+1
protection (circuit or path), the receiver accepts flow only from the
working circuit/path. In the case of failure, it would take some time for
the receiver to detect it and switch to the backup source. Thus, even in
1+1 protection, there will be a non-zero packet loss resulting from a
working path failure that is determined by the failure detection time.

Regards,
Greg

On Sat, Mar 26, 2022 at 12:19 PM Gyan Mishra <[email-masked]> wrote:

>> *Cc:* Joel M. Halpern <[email-masked]>; [email-masked]; TEAS
>> WG <[email-masked]>
>> *Subject:* Re: [Teas] What SLOs and SLEs should be in the Slicing
>> Service Model?
>>
>>
>>
>> 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.
>>
>>
>>
> The term measurable  & unmeasurable realization feature really helps
>> define what characteristics define an SLO or SLE.
>>
>>
>>
>>  Gyan> I completely agree it’s impossible for characteristic to be both
>> an SLO and SLE
>>
>> *[JD]  I would love to hear of a characteristic which is both.  If we
>> find any we can deal with them *
>>
>> *[JD]  That’s fine, but  1) there was never any intention to enumerate
>> all possible characteristics, which is probably impossible, and tag each as
>> > >      > >> I had leapt to the (quite possibly incorrect) conclusion
>> that
>> > >     the two
>> > >      > >>>>> * Things would be much simpler if we just focus on
>> service
>> > >      > >>>>> requirements
>> > >      > >>>> 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
>> > >      > >>>>> "However, it should not imply that NBI models are
>> required
>> > >     to have
>> > >      > >>>>>> But "Reliability" is clearly an SLO. Usually expressed
>> as
>> > >     maximum
>> > >      > >>>>>> There was one thing that I *think* I heard. This was
>> Reza
>> > >     saying
>> > >      > >>>>>> noted in the framework. Maybe I misheard "only" because
>> I
>> > >     think
>> > >      > >>>>>> that might be a mistake.
>> > >      > >>>>> ce message par erreur, veuillez le signaler a
>> l'expediteur
>> > >     et le
>> > >      > >>>>> detruire ainsi que
>> > >      > > par erreur, veuillez le signaler a l'expediteur et le
>> detruire
>> > >     ainsi que
>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/tea
>> https://urldefense.com/v3/__http://www.verizon.com/__;!!NEt6yMaO-gk!V

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 26 Mar 2022 18:04:05 -0400

Hi Greg

Very nicely stated on the protection caveats which historically optical
networks optical bypass UPSR BLSR APS switching from working to protect
yields a 50ms has always been the bogie number as well for RSVP-TE FRR that
within that contracted packet loss ratio SLO for TDM optical and Unified
Transport GMPLS optical yielding the same non zero SLO between 0-50ms.

Very good point on the DETNET PREOF function  yields 0 packet loss
guarantee.

Are you aware of any implementations of DETNET PREOF as that would be a
tremendous benefit for operators and Network slicing as well?

Many Thanks

Gyan

On Sat, Mar 26, 2022 at 4:28 PM Greg Mirsky <[email-masked]> wrote:

> Hi Gyan, et al.,
> I want to share my view on one example that is often used in the
> discussion of ETF Network Slice SLO/SLE - the protection. I can agree that
> in a contract between a client and the service provider protection can be
> listed as SLE with its set of parameters that characterize guaranteed
> failure detection time and the efficiency of the service switchover (number
> of services to be switched over within guaranteed time interval after the
>>> *[JD]  Protection is actually a technique that a service provider may
>>> use to provide reliability*
>>>
>>>
>>>
>>> *[JD]  Correct.  I think this argues against a characteristic that can
>>> be both an SLO and an SLE *
>>>
>>>  Gyan> Understood and agreed.  The key is defining what an SLO and SLE
>>> is utmost importance over listing an exhaustive list.  With the clear
>>> > >      > >> assurance/fulfillment/reporting parameters. Which
>>> parameters
>>> > >     to put
>>> > >      > >>>>>> noted in the framework. Maybe I misheard "only"
>>> because I
>>> > >     think
>>> > >      > >>>>>> that might be a mistake.
>>> they
>>> l'expediteur et le
>>> > > /Email [email-masked] <mailto:[email-masked]
>>> >//
>>> > > /
>>> > >
>>> > > /M 301 502-1347
>>> > >
>>> > > /
>>> > >
>>> > >
>>> >
-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: Greg Mirsky <[email-masked]>
Date: Sat, 26 Mar 2022 15:45:42 -0700

Hi Gyan, et al.,
firstly, need to correct my statement regarding the PREOF. By itself, PREOF
does not guarantee zero packet loss as that requires additional mechanisms
of reception acknowledgment and [packet re-transmission. PREOF helps to
minimize packet loss.
As for the existing implementations, I need to check and will get back to
you.
You've mentioned the 50 ms switchover benchmark that, as I understand it,
is what protection mechanisms are measured by even today. Interestingly, 50
ms is in addition to the 10 ms failure detection guarantee. That might have
been an acceptable time decades ago but now might be it is time to expect a
smaller interval? (Yes, that would require shorter intervals for
protocols like BFD). What are your thoughts? What do other operators think?

Regards,
Greg

On Sat, Mar 26, 2022 at 3:04 PM Gyan Mishra <[email-masked]> wrote:

>>>>  Gyan> After thinking about it further the definitions of SLE and SLO
>>>> is very clear and I think one key point is that SLO is “directly”
>>>> measurable as which more a L1 characteristic of the slice where the ones
>>>> which I might think maybe in that gray area are not directly measurable for
>>>> example protection.  Protection during a failure the result on the 1+1
>>>> protected link is 0 packet loss which is realized by the provider and that
>>>> * What we may tag as an SLE today because of the technology
>>>> limitations, may not stay as such forever.
>>>>
>>>> *[JD]  I agree with the second statement, above, but since we are
>>>> simply trying to introduce the concepts of SLO and SLE, which are clearly
>>>> > >      > Objet : Re: [Teas] What SLOs and SLEs should be in the
>>>> Slicing
>>>> > >     Service
>>>> > >      > Model?
>>>> > >      >
>>>> > >      > request may include (for whatever reason) not only the
>>>> delay, but
>>>> > >     also
>>>> > >      > >> there is deployment-specific. Not all parameters tagged
>>>> as SLO
>>>> > >     in the
>>>> > >      > >>>> taxonomy. From the service modeling standpoint, I
>>>> suggest
>>>> > >     that we
>>>> > >      > >>>> would be defined in the future (which means that it is
>>>> an
>>>> > >     SLO, not
>>>> > >      > >>>> an SLE
>>>> > >      > >> anymore).
>>>> > >      > >>>>>
>>>> > >      > >>>>>> But "Reliability" is clearly an SLO. Usually
>>>> expressed as
>>>> > >     maximum
>>>> > >      > >>>>>> that the service YANG model was only including the
>>>> SLOs
>>>> > >     and SLEs

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 26 Mar 2022 19:55:59 -0400

Hi Greg, et al.,

As the lowest common denominator for MetroE WAN is the physics involved in
an optical bypass switchover from working to protect DWDM Ring topologies I
don’t think there is any way to get around that even with DETNET PREOF.  I
think PREOF is good for BFD enabled IP failover on dark fiber or LAN links
you can achieve the 0 packet loss but for WAN due to the physics of optics
it’s not possible.  DWDM linear circuits that only have working and no
protect path can use BFD and IP failover could take advantage of PREOF.

Kind Regards

Gyan
On Sat, Mar 26, 2022 at 6:45 PM Greg Mirsky <[email-masked]> wrote:

> Hi Gyan, et al.,
> firstly, need to correct my statement regarding the PREOF. By itself,
> PREOF does not guarantee zero packet loss as that requires additional
> mechanisms of reception acknowledgment and [packet re-transmission. PREOF
> helps to minimize packet loss.
>>>>> *Cc:* Joel M. Halpern <[email-masked]>; [email-masked];
>>>>> TEAS WG <[email-masked]>
>>>>> 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.
>>>>>
>>>>>
>>>>>
>>>>>  Gyan> I completely agree it’s impossible for characteristic to be
>>>>> both an SLO and SLE
>>>>>
>>>>> 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
>>>>> * 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.
>>>>> assurance/fulfillment can be part of the slice service definition itself.
>>>>>
>>>>
>>>>      Gyan> With the definition of SLO being directly measurable and a
>>>> L1 slice characteristic there are only so many today and the common ones
>>>> which seems to be the current exhaustive are already listed.  I guess it’s
>>>>> * We are artificially adding extra complexity for the modelling part
>>>>> as service requirement will need to be classified based as SLO or SLEs.
>>>>>
>>>>>
>>>>>
>>>>> > >      > > Some services may be sensitive to delay for example but
>>>>> the
>>>>> > >     slice service
>>>>> > >      > >>>> service requirement will need to be classified based
>>>>> as SLO
>>>>> > >     or SLEs.
>>>>> > >      > >>>>>
>>>>> > >      > >>>>>> certainly be no limitation about including
>>>>> additional SLOs
>>>>> > >     or SLEs
>>>>> > >      > in the YANG model.
>>>>> pas etre
>>>>> > >      > >>> diffuses, exploites ou copies sans autorisation. Si
>>>>> vous avez
>>>>> > >     recu

*Gyan Mishra*

*M 301 502-1347*

---

From: <[email-masked]>
Date: Mon, 28 Mar 2022 05:56:10 +0000

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

John / All

Kind Regards

Gyan