[ippm] Fw: I-D Action: draft-ietf-ippm-connectivity-monitoring-02.txt

gregory.mirsky@ztetx.com Tue, 13 July 2021 02:50 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 1A92C3A0D4B; Mon, 12 Jul 2021 19:50:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 tuVuI53GnXOl; Mon, 12 Jul 2021 19:50:31 -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 D2DFB3A0D42; Mon, 12 Jul 2021 19:50:30 -0700 (PDT)
Received: from mse-us.zte.com.cn (unknown [10.36.11.29]) by Forcepoint Email with ESMTPS id 4AD2F5CD6B269DAEA54E; Tue, 13 Jul 2021 10:50:28 +0800 (CST)
Received: from mgapp01.zte.com.cn ([10.36.9.142]) by mse-us.zte.com.cn with SMTP id 16D2oOu0050171; Tue, 13 Jul 2021 10:50:24 +0800 (GMT-8) (envelope-from gregory.mirsky@ztetx.com)
Received: from mapi (mgapp02[null]) by mapi (Zmail) with MAPI id mid81; Tue, 13 Jul 2021 10:50:24 +0800 (CST)
Date: Tue, 13 Jul 2021 10:50:24 +0800 (CST)
X-Zmail-TransId: 2afa60ecff7014a580f2
X-Mailer: Zmail v1.0
Message-ID: <202107131050240681761@zte.com.cn>
References: 162610119941.11527.1274204599359954796@ietfa.amsl.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 16D2oOu0050171
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/JsNqoPFHWRen-WkEA6dChMdCfdM>
Subject: [ippm] =?utf-8?q?Fw=3A_I-D_Action=3A_draft-ietf-ippm-connectivit?= =?utf-8?q?y-monitoring-02=2Etxt?=
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: Tue, 13 Jul 2021 02:50:35 -0000

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