Subject: Re: [Teas-ns-dt] draft-nsdt-teas-transport-slice-definition-02-comments

From: Eric Gray <[email-masked]>
Date: Wed, 13 May 2020 13:40:48 +0000

Authors/Editors of draft-nsdt-teas-transport-slice-definition-02:

              Please consider the attached revised and annotated version of your -02 version of this draft.

              This version shows markup for removing or modifying some highly contentious or questionable text and sections - including annotations as to why this text should be removed.

              It also includes comments and questions about other text that may not be necessary, or should be reworded.

              One section (section 4.1.1) is shown as removed, but Jari had made a couple of other suggestions about that text immediately prior to the last meeting.  I do not recall if there was any decision about these alternatives and I could not track down the meeting notes from that meeting.

              A key observation about this draft is that it is supposed to be a definitions draft - i.e. - it defines the terminology we are using or expect to use in other drafts related to this work.

              There is some danger in having the ambition to see "definition" as something we can stretch to encompass "specification" in this draft.

              It is important also to realize that the parameters and objectives of transport slice services listed in this draft are explicitly intended to be representative examples, rather than an exhaustive list - hence it is not necessary to include any for which there is no consensus to include.

--
Eric

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 15 May 2020 17:39:53 -0700

Hi Erik, et al.,
thank you for all the comments and suggestions to strengthen the document.
I want to touch on the use of the term "availability" (with updates you've
proposed):

o Availability: concerns with how often a service is lost (or degraded to
the point of unacceptable performance) due to a fault, and how quickly the
lost service network becomes available after a fault. The requirements are
specified through mean time between failures (MTBF), and mean time to
repair (MTTR) to acquire availability metrics.

I agree with you that availability is affected by both network failures and
network performance degradation below a certain threshold. Then, if I
follow that definition, the way of measuring or calculating the
availability noted in the second sentence does not appear to be accurate as
it only includes failure and does not consider periods of performance
degradation. Since this draft, as I understand, is intended to provide the
definitions to be used throughout other TS drafts, perhaps leaving in the
definition will be sufficient, while the availability
measurement/calculation method will be outside the scope of the document.
What do you think?

Regards,
Greg

On Wed, May 13, 2020 at 6:41 AM Eric Gray <eric.gray=
[email-masked]> wrote:

>               This version shows markup for removing or modifying some
> highly contentious or questionable text and sections – including
> annotations as to why this text should be removed.
>
>
>
>               It also includes comments and questions about other text
> that may not be necessary, or should be reworded.
>
>
>
>               One section (section 4.1.1) is shown as removed, but Jari
> had made a couple of other suggestions about that text immediately prior to
> the last meeting.  I do not recall if there was any decision about these
> alternatives and I could not track down the meeting notes from that meeting.
>
>
>
>               A key observation about this draft is that it is supposed to
> be a definitions draft – i.e. – it defines the terminology we are using or
> expect to use in other drafts related to this work..
>
>
>
>               There is some danger in having the ambition to see
> “definition” as something we can stretch to encompass “specification” in
> this draft.
>
>
>
>               It is important also to realize that the parameters and
> objectives of transport slice services listed in this draft are explicitly
> intended to be representative examples, rather than an exhaustive list –
> hence it is not necessary to include any for which there is no consensus to
> include.
>
>
>
> --
>
> Eric
> --
> Teas-ns-dt mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teas-ns-dt
>

---

From: Eric Gray <[email-masked]>
Date: Mon, 18 May 2020 12:35:38 +0000

Greg,

              In this context, “failure” includes any form of service loss.

              Performance degradation beyond acceptability is definitely a form of service loss.

              In some cases, this is explicitly forced by terminating the service – but (even when this is not the case) the fact that the service is no longer delivering on commitment means that the service provider is no longer entitled to claim that it is “available.”

              If I were a service provider, given the choice between  wasting resources in an attempt to mis-deliver a service (and possibly being “caught out” in an apparent effort to charge for it anyway) or taking the service down (making it obviously the case that the service is not available), I would elect to do the latter.

              In traditional (or “legacy”) services, reaching a degradation point was reported as a service failure and service was not considered “restored” until the service performance had improved to the point where the threshold was no longer a factor – for some well-defined period of time.

--
Eric

From: Teas-ns-dt <[email-masked]> On Behalf Of Greg Mirsky
Sent: Friday, May 15, 2020 8:40 PM
To: Eric Gray <eric.gray=[email-masked]>
Cc: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>; [email-masked]; Luis M. Contreras <[email-masked]>; Jari Arkko <[email-masked]>; Shunsuke Homma <[email-masked]>; Kiran Makhijani <[email-masked]>; Shunsuke Homma <[email-masked]>; Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>
Subject: Re: [Teas-ns-dt] draft-nsdt-teas-transport-slice-definition-02-comments

Hi Erik, et al.,
thank you for all the comments and suggestions to strengthen the document. I want to touch on the use of the term "availability" (with updates you've proposed):
o Availability: concerns with how often a service is lost (or degraded to the point of unacceptable performance) due to a fault, and how quickly the lost service network becomes available after a fault. The requirements are specified through mean time between failures (MTBF), and mean time to repair (MTTR) to acquire availability metrics.
I agree with you that availability is affected by both network failures and network performance degradation below a certain threshold. Then, if I follow that definition, the way of measuring or calculating the availability noted in the second sentence does not appear to be accurate as it only includes failure and does not consider periods of performance degradation. Since this draft, as I understand, is intended to provide the definitions to be used throughout other TS drafts, perhaps leaving in the definition will be sufficient, while the availability measurement/calculation method will be outside the scope of the document.
What do you think?

Regards,
Greg

On Wed, May 13, 2020 at 6:41 AM Eric Gray <eric.gray=[email-masked]<mailto:[email-masked]>> wrote:
Authors/Editors of draft-nsdt-teas-transport-slice-definition-02:

              This version shows markup for removing or modifying some highly contentious or questionable text and sections – including annotations as to why this text should be removed.

              A key observation about this draft is that it is supposed to be a definitions draft – i.e. – it defines the terminology we are using or expect to use in other drafts related to this work..

              There is some danger in having the ambition to see “definition” as something we can stretch to encompass “specification” in this draft.

              It is important also to realize that the parameters and objectives of transport slice services listed in this draft are explicitly intended to be representative examples, rather than an exhaustive list – hence it is not necessary to include any for which there is no consensus to include.

--
Eric
--
Teas-ns-dt mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/teas-ns-dt

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 18 May 2020 12:42:26 -0700

Hi Haomian,
thank you for pointing to the only, AFAIK, accepted in the
telecommunication industry source of the definition of error performance
parameters - availability period, unavailability period, and respective
ratios. You're absolutely correct, G.826 and G.827 are the documents we can
use when discussing error performance measurement (ERM) OAM for TS. As Joel
pointed earlier, the definition of availability/unavailability for a PSN is
a challenging subject and several SDOs had tried but have not produced
anything that will be as simple as G.827/G.828. I believe that it is not
because of a lack of effort but because of the difference between the
constant bit-rate communication and PSN. MEF, as was mentioned, settled for
the unavailability period being measured based on the trouble ticketing
system. We may re-use that or try to come with one of our own. It would be
great if we define it in generic terms that be applicable to PSN.

Regards,
Greg

On Sun, May 17, 2020 at 6:09 PM Zhenghaomian <[email-masked]>
wrote:

> FYI, some description about the (un)availability in ITU-T, refer to G.827
> section 6.1 as follow:
>
>
>
> *The term "availability" refers to the availability ratio (AR), which is
> the proportion of time that a path is in the available state during an
> observation period. AR is calculated by dividing the total available time
> during the observation period by the duration of the observation period. *
>
> *The converse of AR, the unavailability ratio (UR), is the proportion of
> time that an end-to-end path is in the unavailable state during an
> observation period. UR is calculated by dividing the total unavailable time
> during the observation period by the duration of the observation period.   *
>
> *AR + UR = 1 *
>
> *The observation period is recommended to be one year.  *
>
>
>
> Regarding the text so far, we miss the characteristic about the ‘ratio’,
> which specified the measurement is based on time; and we also have not
> indicated whether a ‘degradation’ should be counted as ‘available’ or
> ‘unavailable’, as Greg proposed. Personally I slightly prefer the
> degradation to be available.
>
>
>
> My 2 cents,
>
> Haomian
>
>
>
> *发件人:* Teas-ns-dt [mailto:[email-masked]] *代表 *Greg Mirsky
> *发送时间:* 2020年5月16日 8:40
> *收件人:* Eric Gray <eric.gray=[email-masked]>
> *抄送:* LUIS MIGUEL CONTRERAS MURILLO <
> [email-masked]>; [email-masked]; Luis M.
> Contreras <[email-masked]>; Jari Arkko <[email-masked]>;
> Shunsuke Homma <[email-masked]>; Kiran Makhijani <
> [email-masked]>; Shunsuke Homma <[email-masked]>; Rokui,
> Reza (Nokia - CA/Ottawa) <[email-masked]>
> *主题:* Re: [Teas-ns-dt]
> draft-nsdt-teas-transport-slice-definition-02-comments
>
>
>
> Hi Erik, et al.,
>
> I agree with you that availability is affected by both network failures
> and network performance degradation below a certain threshold. Then, if I

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 18 May 2020 12:52:47 -0700

Hi Eric,
I agree with you that from an operational perspective degradation of
service performance below a certain threshold is equal to the failure. But,
AFAIK, that is not the interpretation of "Failure" in "Mean Time Between
Failures" (MTBF). ITU-T, as I understand, interprets "failure of a service"
as the inability to communicate whereas "service degradation" is pointing
to the worsening of the quality of the service while still maintaining
communication between endpoints. If we adopt these interpretations, then
MTBF should be complemented or replaced with something that also reflects
the acceptable level of the service quality.
What do you think?

Regards,
Greg

On Mon, May 18, 2020 at 5:35 AM Eric Gray <[email-masked]> wrote:

>               In some cases, this is explicitly forced by terminating the
> service – but (even when this is not the case) the fact that the service is
> no longer delivering on commitment means that the service provider is no
> longer entitled to claim that it is “available.”
>
>
>
>               If I were a service provider, given the choice between
> wasting resources in an attempt to mis-deliver a service (and possibly
> being “caught out” in an apparent effort to charge for it anyway) or taking
> the service down (making it obviously the case that the service is not
> available), I would elect to do the latter.
>
>
>
>               In traditional (or “legacy”) services, reaching a
> degradation point was reported as a service failure and service was not
> considered “restored” until the service performance had improved to the
> point where the threshold was no longer a factor – for some well-defined
> period of time.
>
>
>
> --
>
> Eric
>
>
>
> *From:* Teas-ns-dt <[email-masked]> *On Behalf Of *Greg
> Mirsky
> *Sent:* Friday, May 15, 2020 8:40 PM
> *To:* Eric Gray <eric.gray=[email-masked]>
> *Cc:* LUIS MIGUEL CONTRERAS MURILLO <
> *Subject:* Re: [Teas-ns-dt]