Re: [ippm] [Teas] Availability metrics in the IETF Network Slice Tue, 19 April 2022 01:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 37BDA3A1DAD; Mon, 18 Apr 2022 18:55:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.905
X-Spam-Status: No, score=-6.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CTE_8BIT_MISMATCH=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZZ1SNi7YEAXs; Mon, 18 Apr 2022 18:55:10 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3DEE03A1DAF; Mon, 18 Apr 2022 18:55:06 -0700 (PDT)
Received: from (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (FangMail) with ESMTPS id 4Kj6Lv5l5fz5B13Z; Tue, 19 Apr 2022 09:55:03 +0800 (CST)
Received: from ([]) by with SMTP id 23J1sdGu035900; Tue, 19 Apr 2022 09:54:39 +0800 (GMT-8) (envelope-from
Received: from mapi (njxapp04[null]) by mapi (Zmail) with MAPI id mid203; Tue, 19 Apr 2022 09:54:39 +0800 (CST)
Date: Tue, 19 Apr 2022 09:54:39 +0800 (CST)
X-Zmail-TransId: 2afc625e165fffffffff857-8526e
X-Mailer: Zmail v1.0
Message-ID: <>
In-Reply-To: <>
Mime-Version: 1.0
From: <>
To: <>
Cc: <>, <>, <>
Content-Type: text/plain; charset="UTF-8"
X-MAIL: 23J1sdGu035900
X-Fangmail-Gw-Spam-Type: 0
X-FangMail-Miltered: at cgslv5.04- with ID 625E1677.002 by FangMail milter!
X-FangMail-Envelope: 1650333303/4Kj6Lv5l5fz5B13Z/625E1677.002/[]/<>
X-Fangmail-Anti-Spam-Filtered: true
X-Fangmail-MID-QID: 625E1677.002/4Kj6Lv5l5fz5B13Z
Archived-At: <>
Subject: Re: [ippm] =?utf-8?q?=5BTeas=5D_Availability_metrics_in_the_IETF_Net?= =?utf-8?q?work_Slice?=
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 19 Apr 2022 01:55:14 -0000

Hi Greg,
Thank you for providing this draft on availability measurement, as an important measurable parameter of network slicing, support for measurement and implementation methods is helpful. For the measurement method mentioned in this draft is the use of the histogram method, it's very interesting.
>From my perspective, through the use of the histogram method, the threshold value of the availability rate, such as the maximum guarantee availability rate and the minimum guarantee availability rate, is obtained. Through the probability density of availability, it seems be more real-time and may be a better indicator of performance measurement. Compared with the traditional measurement method of availability this adds the maximum guaratee availability indentification but whether this is very necessary I would like leave this question to operators.
In addition, for IETF NSS, it is recommended to increase the measure of slice service availability, such as statistics based on slice instances or what else, when reusing existing slice instances or creating new slice instances, check whether slice availability meets the needs of slice customers.

Best regards,
收件人:Adrian Farrel;TEAS WG;IETF IPPM WG;
日 期 :2022年04月04日 22:04
主 题 :[Teas] Availability metrics in the IETF Network Slice
Teas mailing list

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 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. 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 can be further enhanced with the referen
 ce to the draft-mhmcsfh-ippm-pam.
I greatly appreciate your comments, questions, and suggestions on our work on Precision Availability Metrics.


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