Re: [ippm] Fw: I-D Action: draft-ietf-ippm-connectivity-monitoring-02.txt Wed, 14 July 2021 02:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E914A3A145B; Tue, 13 Jul 2021 19:43:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xzZWK1vGHrt9; Tue, 13 Jul 2021 19:43:41 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D351C3A1458; Tue, 13 Jul 2021 19:43:39 -0700 (PDT)
Received: from (unknown []) by Forcepoint Email with ESMTPS id 81A9CA2A38729E4877CD; Wed, 14 Jul 2021 10:43:38 +0800 (CST)
Received: from ([]) by with SMTP id 16E2hYbN038775; Wed, 14 Jul 2021 10:43:34 +0800 (GMT-8) (envelope-from
Received: from mapi (mgapp02[null]) by mapi (Zmail) with MAPI id mid81; Wed, 14 Jul 2021 10:43:34 +0800 (CST)
Date: Wed, 14 Jul 2021 10:43:34 +0800 (CST)
X-Zmail-TransId: 2afa60ee4f566d794643
X-Mailer: Zmail v1.0
Message-ID: <>
In-Reply-To: <FR2P281MB061139577FD19287EAA252909C149@FR2P281MB0611.DEUP281.PROD.OUTLOOK.COM>
References:,, FR2P281MB061139577FD19287EAA252909C149@FR2P281MB0611.DEUP281.PROD.OUTLOOK.COM
Mime-Version: 1.0
From: <>
To: <>
Cc: <>, <>
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: 16E2hYbN038775
Archived-At: <>
Subject: Re: [ippm] =?utf-8?q?Fw=3A_I-D_Action=3A_draft-ietf-ippm-connectivit?= =?utf-8?q?y-monitoring-02=2Etxt?=
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: Wed, 14 Jul 2021 02:43:46 -0000

Hi Rudiger,
thank you for explaining the goal of this work in great detail; much appreciated. It could be that there's some similarity between the purpose of this draft and what we're trying to quantify in The availability/unavailability metric, defined for the constant-rate media, is applied to the packet-switched network in that draft. 
I agree with you that there's a need for a single metric that combines performance metrics measured for the particular path with the Loss of the Path Continuity state. I think that, as services set forth different QoS requirements (Service Level Objectives), such SLOs play a significant role in determining the resulting metric.
I greatly appreciate it if you can share your thoughts and comments on the approach in general and the proposed measurement method discussed in Error Performance Measurement draft.

Greg Mirsky
Sr. Standardization Expert
预研标准部/有线研究院/有线产品经营部  Standard Preresearch Dept./Wireline Product R&D Institute/Wireline Product Operation Division
------------------Original Mail------------------
To: gregory mirsky10211915;
Date: 2021/07/12 23:19
Subject: AW: Fw:[ippm] I-D Action: draft-ietf-ippm-connectivity-monitoring-02.txt
Hi Greg,
Thanks. I'm open to terminology changes. I'll use connectivity for now and I mean ability to forward packets from A to B. My thoughts so far (well written text needs to be added)
- find a metric, which is deterministic in expressing no forwarding / no connectivity
- for an interface connecting A and B, that's simple if Adj-SIDs are applied: packets are dropped.
- in most core nets, a path will be re-routed. Delay often changes, but there are cases, when one can't rely on that. So I stopped working on a delay based connectivity metric.
- Using Node-SIDs with a loss based metric is an option too - Adj-SIDs are the better choice if links connecting neighbors are monitored (text will have to express that).
- Defining loss of connectivity I'll end up with something similar to routing/BFD but here 3 different measurement loops indicate loss (in the end, 3 dropped packets within one evaluation interval, are the minimum criterium, that's the similarity, but here meaning one of each measurement loop).
- To continue that analogy, regarding timing issues: if each measurement loop forwards one packet every 60 ms, 6 measurement loops send one packet each within 50 ms. That's the worst case temporal distance which two or three of the measurement loops are apart. Then that determines speed of decision (at the sender....measurement loop delays can be different, depending on the kind of sub-path monitored and that may have an impact).
I've added more statements than you've asked for, just to indicate that there's a concept for the missing metrics. I didn't have time to work out good text, as I figured out how to proceed within the last days only.
-----Ursprüngliche Nachricht-----
Von: <>
Gesendet: Dienstag, 13. Juli 2021 04:50
An: Geib, Rüdiger <>
Betreff: Fw:[ippm] I-D Action: draft-ietf-ippm-connectivity-monitoring-02.txt
Hi Rudiger,
thank you for the extensive and beneficial updates to the document.
I have a question about the use of the term "connectivity" in the draft. As I understand, as you've referenced earlier IETF document RFC 2678, "connectivity" is interpreted as an ability to transport a packet from one system to another. I agree that interpretation is often used in IETF documents. At the same time, in the field of fault management OAM, e.g., Ethernet CFM, we know of two mechanisms - Continuity Check (CC) and Connectivity Verification (CV). To illustrate the difference between them, I'll use the analogy of electrical wires. Then, CC verifies that a wire that connects circuits A and B exists and is operational. CV function is similar, but it verifies that if nodes are connected by red, blue, and orange wires, the red circuit receives electric current only from the red wire. If that is not the case and that state persists over a pre-defined number of consecutive checks, the state of misconnection is determined, and, usually, an alarm is raised.
As it appears to me, the term "connectivity" in the draft is not used in the same context as in the FM OAM. I think we can find a better term to characterize the metric discussed in the document.
Greg Mirsky
Sr. Standardization Expert
预研标准部/有线研究院/有线产品经营部  Standard Preresearch Dept./Wireline Product R&D Institute/Wireline Product Operation Division
------------------Original Mail------------------
To: ;
Date: 2021/07/12 07:47
Subject: [ippm] I-D Action: draft-ietf-ippm-connectivity-monitoring-02.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Performance Measurement WG of the IETF.
Title           : A Connectivity Monitoring Metric for IPPM
Author          : Ruediger Geib
Filename        : draft-ietf-ippm-connectivity-monitoring-02.txt
Pages           : 25
Date            : 2021-07-12
Within a Segment Routing domain, segment routed measurement packets can be sent along pre-determined paths.  This enables new kinds of measurements.  Connectivity monitoring allows to supervise the state and performance of a connection or a (sub)path from one or a few central monitoring systems.  This document specifies a suitable type-P connectivity monitoring metric.
The IETF datatracker status page for this draft is:
There is also an htmlized version available at:
A diff from the previous version is available at:
Internet-Drafts are also available by anonymous FTP at:
ippm mailing list