Subject: [ippm] Availability metrics in the IETF Network Slice

From: Greg Mirsky <[email-masked]>
Date: Mon, 4 Apr 2022 07:03:48 -0700

Hi Adrian, et al,
I've got a question about the relationship of performance metrics like
packet loss ratio, packet delay, packet delay variation of an IETF Network
Slice service (NSS), on one hand, and IETF NSS availability. I think that
Section 4.1.1.1 considers all these metrics as Directly Measurable SLOs. I
agree with such characterization in regard to loss and delay while I am not
sure that that applies to the availability. The issue I have is that, as
far as I know, there's no formal definition of the availability metric in
the document and it seems that we've been using it in a colloquial way. A
group of us started to work on a definition of the availability as a
performance metric for a multi-SLO service
<https://datatracker.ietf.org/doc/draft-mhmcsfh-ippm-pam/>. We had
discussed this work at the IPPM WG meeting at IETF-113. I think that this
work is relevant to the discussion of the IETF NSS availability. If that is
the case, perhaps the characterization of the availability in Section
4.1.1.1 can be further enhanced with the reference to
the draft-mhmcsfh-ippm-pam.
I greatly appreciate your comments, questions, and suggestions on our work
on Precision Availability Metrics.

Regards,
Greg

PS. Attached, please find the presentation slides from the IPPM WG meeting.

---

From: John E Drake <[email-masked]>
Date: Mon, 4 Apr 2022 14:52:27 +0000

Greg,

That sounds like a great idea.

Yours Irrespectively,

John

Juniper Business Use Only
From: ippm <[email-masked]> On Behalf Of Greg Mirsky
Sent: Monday, April 4, 2022 10:04 AM
To: Adrian Farrel <[email-masked]>; TEAS WG <[email-masked]>; IETF IPPM WG <[email-masked]>
Subject: [ippm] Availability metrics in the IETF Network Slice

[External Email. Be cautious of content]

Hi Adrian, et al,
I've got a question about the relationship of performance metrics like packet loss ratio, packet delay, packet delay variation of an IETF Network Slice service (NSS), on one hand, and IETF NSS availability. I think that  Section 4.1.1.1 considers all these metrics as Directly Measurable SLOs. I agree with such characterization in regard to loss and delay while I am not sure that that applies to the availability. The issue I have is that, as far as I know, there's no formal definition of the availability metric in the document and it seems that we've been using it in a colloquial way. A group of us started to work on a definition of the availability as a performance metric for a multi-SLO service<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-mhmcsfh-ippm-pam/__;!!NEt6yMaO-gk!THS33yjziPwDcoT1wn1gm-hvkwEU_Rq9HFUL-GDa57LhJWHD0uVygH0OV3TtD-w$>. We had discussed this work at the IPPM WG meeting at IETF-113. I think that this work is relevant to the discussion of the IETF NSS availability. If that is the case, perhaps the characterization of the availability in Section 4.1.1.1 can be further enhanced with the reference to the draft-mhmcsfh-ippm-pam.
I greatly appreciate your comments, questions, and suggestions on our work on Precision Availability Metrics.

Regards,
Greg

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 6 Apr 2022 14:55:12 -0700

Hi Med,
thank you for your comments and suggestions (the .doc version is attached).
I will discuss this with the authors and share updates addressing them.

Kind regards,
Greg

On Tue, Apr 5, 2022 at 12:07 AM <[email-masked]> wrote:

> Hi Greg,
>
>
>
> Sure. Feel free to forward the review to IPPM list as I’m not on that
> list.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* Greg Mirsky <[email-masked]>
> *Envoyé :* lundi 4 avril 2022 19:04
> *À :* BOUCADAIR Mohamed INNOV/NET <[email-masked]>
> *Objet :* Re: [Teas] Availability metrics in the IETF Network Slice
>
>
>
> Hi Med,
>
> thank you for your review and comments. Will review and discuss with the
> co-authors and be back with the proposed updates. I wonder if you would
> agree to sending references to your review on the mailing lists (IPPM would
> be especially helpful to progress this work). Much appreciate your help and
> support.
>
>
>
> Regards,
>
> Greg
>
>
>
> On Mon, Apr 4, 2022 at 7:17 AM <[email-masked]> wrote:
>
> Hi Greg,
>
>
>
> Thank you for sharing this work.
>
>
>
> As you are looking for comments on PAM, you may check
> https://mailarchive.ietf.org/arch/msg/teas/74p99UxkyxzPII92VVV6f9tSbYA/:
>
>
>
>    - pdf:
>    https://raw.githubusercontent.com/boucadair/IETF-Drafts-Reviews/master/draft-mhmcsfh-ippm-pam-00-rev%20Med.pdf
>    - doc:
>    https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-mhmcsfh-ippm-pam-00-rev%20Med.doc
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* Teas <[email-masked]> *De la part de* Greg Mirsky
> *Envoyé :* lundi 4 avril 2022 16:04
> *À :* Adrian Farrel <[email-masked]>; TEAS WG <[email-masked]>; IETF
> IPPM WG <[email-masked]>
> *Objet :* [Teas] Availability metrics in the IETF Network Slice
>
>
>
> Hi Adrian, et al,
>
> _________________________________________________________________________________________________________________________
>
>
>
> 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.
>
>