Re: [ippm] draft-ietf-ippm-connectivity-monitoring-02.txt and draft-mirsky-ippm-epm

gregory.mirsky@ztetx.com Sun, 25 July 2021 02:34 UTC

Return-Path: <gregory.mirsky@ztetx.com>
X-Original-To: ippm@ietfa.amsl.com
Delivered-To: ippm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72A863A0FC4; Sat, 24 Jul 2021 19:34:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.893
X-Spam-Level:
X-Spam-Status: No, score=-1.893 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_FACE_BAD=0.001, HTML_MESSAGE=0.001, 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vpljSrA3waug; Sat, 24 Jul 2021 19:34:07 -0700 (PDT)
Received: from mxus.zteusa.com (mxus.zteusa.com [4.14.134.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 525143A0FC2; Sat, 24 Jul 2021 19:34:06 -0700 (PDT)
Received: from mse-us.zte.com.cn (unknown [10.36.11.29]) by Forcepoint Email with ESMTPS id CA10293B06570F991490; Sun, 25 Jul 2021 10:34:05 +0800 (CST)
Received: from mgapp01.zte.com.cn ([10.36.9.142]) by mse-us.zte.com.cn with SMTP id 16P2Y1LJ086970; Sun, 25 Jul 2021 10:34:01 +0800 (GMT-8) (envelope-from gregory.mirsky@ztetx.com)
Received: from mapi (mgapp01[null]) by mapi (Zmail) with MAPI id mid81; Sun, 25 Jul 2021 10:34:01 +0800 (CST)
Date: Sun, 25 Jul 2021 10:34:01 +0800
X-Zmail-TransId: 2af960fccd99567922d7
X-Mailer: Zmail v1.0
Message-ID: <202107251034013792684@zte.com.cn>
In-Reply-To: <FR2P281MB0611C9FE3B8F0A9726615DFD9C139@FR2P281MB0611.DEUP281.PROD.OUTLOOK.COM>
References: FR2P281MB0611C9FE3B8F0A9726615DFD9C139@FR2P281MB0611.DEUP281.PROD.OUTLOOK.COM
Mime-Version: 1.0
From: gregory.mirsky@ztetx.com
To: Ruediger.Geib@telekom.de
Cc: ippm@ietf.org, ippm-chairs@ietf.org
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-us.zte.com.cn 16P2Y1LJ086970
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/EJK_nXUDvsidfi-sXQtiGJUlHJ8>
Subject: Re: [ippm] draft-ietf-ippm-connectivity-monitoring-02.txt and draft-mirsky-ippm-epm
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ippm/>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 25 Jul 2021 02:34:13 -0000

Hi Ruediger,

I much appreciate you sharing your thoughts on draft-mirsky-ippm-epm. I will be taking your suggestions and questions to work on. In the meantime, I have a question about the interpretation of the terms "connectivity" and "loss of connectivity" in draft-ietf-ippm-connectivity-monitoring. In the Introduction, it is noted that:


a packet not reaching a destination indicates a loss of connectivity

Should a reader assume that that the connectivity is restored when a packet reaches the destination? What if that is the very next packet? And then, that process of lost/received packets continues. OSS/BSS I am familiar with detecting the network failure, and thus entering the Loss of Connectivity (or Continuity) state triggers an Alarm. And when the state is cleared, i.e., the continuity of the monitored path is restored according to FM OAM protocol, the Alarm is cleared. Should we assume that the same operational procedure can be applied to a system based on draft-ietf-ippm-connectivity-monitoring?








Regards,


Greg Mirsky






Sr. Standardization Expert
预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R&D Institute/Wireline Product Operation Division









E: gregory.mirsky@ztetx.com 
www.zte.com.cn






Original Mail



Sender: Ruediger.Geib@telekom.de
To: gregory mirsky10211915;
CC: ippm@ietf.org;ippm-chairs@ietf.org;
Date: 2021/07/14 01:28
Subject: draft-ietf-ippm-connectivity-monitoring-02.txt and draft-mirsky-ippm-epm


Hi Greg,
 
I've read draft-mirsky-ippm-epm and I don't object to proposals transferring existing standards and definitions of other SDOs to the Internet, if organized well and in consensus. Monitoring availability of a physical connection or some other resource which is either UP or DOWN is simple, and then also Connectivity,  Severely Errored Seconds or Availability respectively can be defined easily. Once we move from links to routes between nodes, like sub-paths or terminals connected by e.g. TCP transport, these metrics and lightweight and useful ways to measure them require careful thought.
 
To go to detail: the metrics proposed by draft-ietf-ippm-connectivity can be used to determine Severely Errored Seconds, meaning high packet drop ratios. Especially a single random packet loss (without congestion or a behaviour lasting long enough to cause queuing or a drop of a second packet passing the same sub-path) can't be assigned to a particular monitored sub-path. In that case, it's unclear which of the sub-paths monitored has created the Errored Second. On the other hand, draft-ietf-ippm-connectivity allows to detect congestion without applying packet loss as the criterium. To me, that's a relevant point, if metrics are to characterize network behaviour above transmission layer. Added latency caused by a queue or counting ECN marks serve to indicate congestion faster and more reliable, than loss based metrics. Congestion aware transport usually limits loss to low single digit percentages under congestion, maybe even less. Reliably deciding on an Errored Second by a loss based metric under congestion requires creation and capturing of a high number of successfully exchanged packets to detect a low packet loss ratio during an evaluation interval.  
 
While the metrics (or parameters) of ITU-T are quite comprehensible, capturing them at layers 2 and above may cause some effort (I think to understand, that the approach chosen by draft-mirsky-ippm-epm prefers a connection oriented network design).
 
Regards,
 
Rüdiger
 
 
-----Ursprüngliche Nachricht-----
Von: gregory.mirsky@ztetx.com <gregory.mirsky@ztetx.com>  
Gesendet: Mittwoch, 14. Juli 2021 04:44
An: Geib, Rüdiger <Ruediger.Geib@telekom.de> 
Cc: ippm@ietf.org; ippm-chairs@ietf.org
Betreff: Re:AW: Fw:[ippm] I-D Action: draft-ietf-ippm-connectivity-monitoring-02.txt
 
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 https://datatracker.ietf.org/doc/draft-mirsky-ippm-epm/. 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.
 
Regards,
Greg Mirsky
Sr. Standardization Expert
预研标准部/有线研究院/有线产品经营部  Standard Preresearch Dept./Wireline Product R&D Institute/Wireline Product Operation Division
E: gregory.mirsky@ztetx.com
www.zte.com.cn
------------------Original Mail------------------
Sender: Ruediger.Geib@telekom.de
To: gregory mirsky10211915;
CC: ippm@ietf.org;ippm-chairs@ietf.org;
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.
Regards,
Rüdiger
-----Ursprüngliche Nachricht-----
Von: gregory.mirsky@ztetx.com <gregory.mirsky@ztetx.com> 
Gesendet: Dienstag, 13. Juli 2021 04:50
An: Geib, Rüdiger <Ruediger.Geib@telekom.de> 
Cc: ippm@ietf.org; ippm-chairs@ietf.org
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.
Regards,
Greg Mirsky
Sr. Standardization Expert
预研标准部/有线研究院/有线产品经营部  Standard Preresearch Dept./Wireline Product R&D Institute/Wireline Product Operation Division
E: gregory.mirsky@ztetx.com
www.zte.com.cn
------------------Original Mail------------------
Sender: internet-drafts@ietf.org
To: i-d-announce@ietf.org ;
CC: ippm@ietf.org;
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
Abstract:
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:
https://datatracker.ietf.org/doc/draft-ietf-ippm-connectivity-monitoring/
There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-ippm-connectivity-monitoring-02
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-connectivity-monitoring-02
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
_______________________________________________
ippm mailing list
ippm@ietf.org
https://www.ietf.org/mailman/listinfo/ippm