Re: [ippm] Fwd: New Version Notification for draft-mhmcsfh-ippm-pam-03.txt

[[e-mail]]

Dear Greg,

Thanks a lot. I also reviewed draft-ietf-teas-ietf-network-slices in the meanwhile.

I understood that draft-mhmcsfh-ippm-pam is basically the technical implementation of section 4.1 of draft-ietf-teas-ietf-network-slices (https://datatracker.ietf.org/doc/html/draft-ietf-teas-ietf-network-slices-16#section-4.1), which describes very well the different aspects.

What I miss is the error budget, burn rate aspect though. It is usually defined in the alert/notification policy. I would be interested to understand in which model this would be reflected.

Apart of the slightly misaligned terminology compared other SDO's, all components are there to maintain proper SLO.

Looking forward to your reply.

Best wishes
Thomas

From: Greg Mirsky <[e-mail]>
Sent: Friday, December 2, 2022 10:24 PM
To: Graf Thomas, INI-NET-TCZ-ZH1 <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: Re: [ippm] Fwd: New Version Notification for draft-mhmcsfh-ippm-pam-03.txt

Hi Thomas,
thank you for your kind words and support of our work on the precision availability metrics. You bring up very good points, and I'll follow up with detailed responses before the winter holidays (the next week is taken by the BBF meeting). In the meantime, here are some thoughts:

  *   I see it beneficial to use terminology defined for IETF Network Slicing. We can add text explaining and mapping dictionaries if there are differences in interpretation across SDOs.
  *   I absolutely agree with your vision that we must develop a YANG model(s) that can configure, maintain, and operate PAM-based policies for communication services (using a bit of 3GPP terminology). This is identified as the work item for the future. How far away is it? It can be started as the PAM document progresses.
Best regards,
Greg

On Thu, Dec 1, 2022 at 8:13 AM <[e-mail]<mailto:[e-mail]>> wrote:
Dear Greg,

First of all, thank you very much for picking up this important topic. I think this is very valuable.

I would welcome the distinction between the SRE terms SLI (Service Level Indicator) and SLO (Service Level Objective) and apply the SLI to both packet loss and delay for a specific flow.

To my understanding, section 3.1 (https://datatracker.ietf.org/doc/html/draft-mhmcsfh-ippm-pam#section-3.1<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-mhmcsfh-ippm-pam%23section-3.1&data=05%7C01%7CThomas.Graf%40swisscom.com%7C29c1545fdb474c95e98408dad4ab85ac%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C638056130382160072%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=bMvXs52Fii3FsGjFBuQXxSVTbJUpHE4Pon2j9LUfXiE%3D&reserved=0>) describes the SLI. Defining the upper and lower bounds of the bucketing for VI and SVI.

For the SLO definition, what is missing is the burn rate which defines the time range and the VI / SVI count. The notification should not immediately happen at every VI and SVI violation, it should happen with a delay when the VI / SVI burn rate is violated. That delay can be defined for different criticality.

For the semantics I suggest to be guided, inspired by OpenSLO (https://openslo.com/<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fopenslo.com%2F&data=05%7C01%7CThomas.Graf%40swisscom.com%7C29c1545fdb474c95e98408dad4ab85ac%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C638056130382315698%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=DLZXabm0j9ICQJLaz7vdz%2BvRqphQahGtdaRq%2F9pRSd8%3D&reserved=0>, https://github.com/openslo/openslo<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenslo%2Fopenslo&data=05%7C01%7CThomas.Graf%40swisscom.com%7C29c1545fdb474c95e98408dad4ab85ac%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C638056130382315698%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=PaIuRdYuhGYMb0RmVVkKd48e0nyUjEnXrtG3qrKI4GU%3D&reserved=0>). This is widely adopted in the industry already.

Regarding section 6. In my opinion, the end goal of this document should be that an SLO and SLI for a network service intent (https://datatracker.ietf.org/doc/html/rfc9316#section-6.2<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc9316%23section-6.2&data=05%7C01%7CThomas.Graf%40swisscom.com%7C29c1545fdb474c95e98408dad4ab85ac%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C638056130382315698%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=wUb6kvLriUStsAvOMHdRxDPnx0UDV%2BjOv3UAE1PTDZs%3D&reserved=0>) is defined in a YANG module and the SLI can be applied to a flow, which is actively being generated and measured by a probe or the flow is passively/hybrid being measured by a transit node. I gladly contribute to the document and I am looking forward to the working group adoption.

>From a data mesh architecture (https://www.datamesh-architecture.com/<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.datamesh-architecture.com%2F&data=05%7C01%7CThomas.Graf%40swisscom.com%7C29c1545fdb474c95e98408dad4ab85ac%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C638056130382315698%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=XkZ%2BKnZ0dRSCu1WnRM8aHI3MbK9K%2B7EVlwRZz0uc%2Ftk%3D&reserved=0>) perspective, the delay and loss measured measurements are operational metrics. The SLI, VI and SVI count, are analytical metrics.

Best wishes
Thomas

From: ippm <[e-mail]<mailto:[e-mail]>> On Behalf Of Greg Mirsky
Sent: Monday, November 7, 2022 12:21 PM
To: IETF IPPM WG <[e-mail]<mailto:[e-mail]>>; IPPM Chairs <[e-mail]<mailto:[e-mail]>>
Cc: TEAS WG <[e-mail]<mailto:[e-mail]>>
Subject: [ippm] Fwd: New Version Notification for draft-mhmcsfh-ippm-pam-03.txt

Dear All,
as we were suggested by the IPPM WG Chairs, the new version of the Precision Availability Metrics draft includes updates addressing comments received in the course of the IPPM WG AP.

The authors allways welcome and greatly appreciate your comments, questions, and suggestions.

Best regards,
Greg (on behalf of the Authors)
---------- Forwarded message ---------
From: <[e-mail]<mailto:[e-mail]>>
Date: Mon, Nov 7, 2022 at 11:17 AM
Subject: New Version Notification for draft-mhmcsfh-ippm-pam-03.txt
To: Alexander Clemm <[e-mail]<mailto:[e-mail]>>, Greg Mirsky <[e-mail]<mailto:[e-mail]>>, Jerome Francois <[e-mail]<mailto:[e-mail]>>, Joel Halpern <[e-mail]<mailto:[e-mail]>>, John Strassner <[e-mail]<mailto:[e-mail]>>, Xiao Min <[e-mail]<mailto:[e-mail]>>



A new version of I-D, draft-mhmcsfh-ippm-pam-03.txt
has been successfully submitted by Greg Mirsky and posted to the
IETF repository.

Name:           draft-mhmcsfh-ippm-pam
Revision:       03
Title:          Precision Availability Metrics for SLO-Governed End-to-End Services
Document date:  2022-11-07
Group:          Individual Submission
Pages:          13
URL:            https://www.ietf.org/archive/id/draft-mhmcsfh-ippm-pam-03.txt<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-mhmcsfh-ippm-pam-03.txt&data=05%7C01%7CThomas.Graf%40swisscom.com%7C29c1545fdb474c95e98408dad4ab85ac%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C638056130382315698%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=JGFxwVRfgV2CBggs13VX4ABfAsueE%2FSdNP9cwLG89lY%3D&reserved=0>
Status:         https://datatracker.ietf.org/doc/draft-mhmcsfh-ippm-pam/<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-mhmcsfh-ippm-pam%2F&data=05%7C01%7CThomas.Graf%40swisscom.com%7C29c1545fdb474c95e98408dad4ab85ac%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C638056130382315698%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=IXOuVRc1bMmsQ14dCkCa5BdV8l4IAI2tnU3uUFh%2FNYY%3D&reserved=0>
Html:           https://www.ietf.org/archive/id/draft-mhmcsfh-ippm-pam-03.html<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-mhmcsfh-ippm-pam-03.html&data=05%7C01%7CThomas.Graf%40swisscom.com%7C29c1545fdb474c95e98408dad4ab85ac%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C638056130382315698%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=uvZnVto8eN6%2FR%2BWAufFk87TEtLY7iaoRLz0lT80a0Zc%3D&reserved=0>
Htmlized:       https://datatracker.ietf.org/doc/html/draft-mhmcsfh-ippm-pam<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-mhmcsfh-ippm-pam&data=05%7C01%7CThomas.Graf%40swisscom.com%7C29c1545fdb474c95e98408dad4ab85ac%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C638056130382315698%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=hKEjO1H7Q%2FB4HPwPg35Me%2Bo6j204Zik78q2eQ1z5Gy4%3D&reserved=0>
Diff:           https://www.ietf.org/rfcdiff?url2=draft-mhmcsfh-ippm-pam-03<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-mhmcsfh-ippm-pam-03&data=05%7C01%7CThomas.Graf%40swisscom.com%7C29c1545fdb474c95e98408dad4ab85ac%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C638056130382315698%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=CYYbVayzKxNEyORVhIaWvc9bXp07JcFIiZNAuHrX1NI%3D&reserved=0>

Abstract:
   This document defines a set of metrics for networking services with
   performance requirements expressed as Service Level Objectives (SLO).
   These metrics, referred to as Precision Availability Metrics (PAM),
   are useful for defining and monitoring of SLOs.  Specifically, PAM
   can be used by providers and/or users of the Network Slice service to
   assess whether the service is provided in compliance with its
   specified quality, i.e., in accordance with its defined SLOs.




The IETF Secretariat