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

Ruediger.Geib@telekom.de Wed, 14 July 2021 08:28 UTC

Return-Path: <Ruediger.Geib@telekom.de>
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 BFFCA3A185B; Wed, 14 Jul 2021 01:28:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.847
X-Spam-Level:
X-Spam-Status: No, score=-4.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de
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 OsPPSeKPWsE0; Wed, 14 Jul 2021 01:28:28 -0700 (PDT)
Received: from mailout41.telekom.de (mailout41.telekom.de [194.25.225.151]) (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 BEF1E3A185A; Wed, 14 Jul 2021 01:28:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1626251308; x=1657787308; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=ODOEzlDPajyGQ3XwnLvFICiv1/lHkUhXfBOZQ7QjPUg=; b=uGp7+2xRU+bVzKLEQjEQiXIHpyaNYvRsutH/GuRM268X1+JiQhW9un3L wcuuV65RlQaQghsKz9ci4EpHoBAI24/Ey66cWKkuoTaetQkAIcc+wAF7q I9cUsd+qy2gIm7zMqSgCWLBxvAddONT/QJbkT/tuKT+MvY6j0VDwqylm2 KSGNsX9jVIFiRx2yFKEOjV81jabvag4ShxhJfEQd3k0SGrHbI8L4d7/1U 0myUEGneHVqCL0y3v0CQKvioroQqj3Lo7UUodaxi+YmLa6s7/aBl2aVHm GtPKsR9fI0UJYzRm1QA9sVboMxCEvJLtGC0k5/9AJh7YAeLZjlRLbDXLe A==;
IronPort-SDR: +8pp2698eDRgx2Bknwlxpi/OGROM/McUyINLNGi/OCdqzBGPwipCPlXsCGSYRPb/566gjHWYeY oNZZwlOzv6ew==
IronPort-HdrOrdr: A9a23:qSEYVK5C3aEFyzXXBgPXwUaBI+orL9Y04lQ7vn2ZFiYlEPBwxvre/8jziyWVtN9IYgBepTiBUJPwOE80hqQFn7X5Wo3SHTUO2VHYYr2KgrGSvgEIdxeOkdK12J0KT0EcMqyxMbEZt7eH3ODQKb9JrLbokdHM9IPjJh9WPFtXgspbnn9E43OgYzdLrX59dOEE/fSnl6x6TjybE0j/jP7XOlA1G8z44/HbnpPvZhALQzQ97hOVsD+u4LnmVzCFwxY3SVp0sPQf2FmAtza8yrSosvm9xBOZ/XTU9Y5qlNzozcYGLNCQi/ISNi7nhm+TFcZcsvy5zXUISdOUmREXeer30lEd1gNImirsl1SO0F/QMs/boW4TAjHZuASlaDDY0L3ErXoBerp8bMRiA0bkAgMbzaJB+bMO0GSDu5VNCxTc2Cz7+tjTThlv0lG5uHw4jIco/jZiuKYlGfdsRLYkjQho+VY7bVXHwZFiFPMrANDX5f5Qf1/fZ3fFvnN3yNjpWngoBB+JTkULp8TQilFt7TxE5lpdwNZakmYL9Zo7RZUB7+PYMr5wnLULSsMNd6pyCOoIXMPyAG3QRhDHNn6UPD3cZew60rL22tfKCZAOla6XkbAzve4PcaX6ISVlXDQJCjDT4OW1rel2ziw=
Received: from qdefcs.de.t-internal.com ([10.171.254.41]) by MAILOUT41.dmznet.de.t-internal.com with ESMTP/TLS/ECDHE-RSA-AES128-GCM-SHA256; 14 Jul 2021 10:28:24 +0200
IronPort-SDR: ik/ZvOzH4TzlUhQfxJDSjIwPFJZQ1jhwb6RTKSe/G5q6/CqUfJLXBHgxkcPwZE1Uk0y236DtWj w36jsdyketUM8ClRzAk5EuHl0KuovYnn0=
X-IronPort-AV: E=Sophos;i="5.84,238,1620684000"; d="scan'208";a="362929994"
X-MGA-submission: MDG5w04Qt83h2OOE43xtsSlnGXfuS6DKn9dzPVL2mno6CYMwyPm2JzStwC8JouYgPlZIdXZRuD0/Q6vUnCzA10yRMpwK2FOxy268ZJHzM3GHKSAhpsOnHaD0NuOuW1yf6wyOK3cWzRxV31KvMPYCDty53RRRgynjdJoNphoEig7VGA==
Received: from he105715.emea1.cds.t-internal.com ([10.169.118.51]) by QDEFCV.de.t-internal.com with ESMTP/TLS/ECDHE-RSA-AES128-SHA256; 14 Jul 2021 10:28:22 +0200
Received: from HE105715.EMEA1.cds.t-internal.com (10.169.118.51) by HE105715.emea1.cds.t-internal.com (10.169.118.51) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Wed, 14 Jul 2021 10:28:21 +0200
Received: from HE104164.emea1.cds.t-internal.com (10.171.40.35) by HE105715.EMEA1.cds.t-internal.com (10.169.118.51) with Microsoft SMTP Server (TLS) id 15.0.1497.18 via Frontend Transport; Wed, 14 Jul 2021 10:28:21 +0200
Received: from DEU01-FR2-obe.outbound.protection.outlook.com (104.47.11.168) by O365mail06.telekom.de (172.30.0.233) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Wed, 14 Jul 2021 10:28:06 +0200
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KeBJ4uxl+ttMSAf+zdCGCCFadt1oxv2fnq/5iwlShLWRZlAGxwTfJbyawUaOf6RxanjwqCVQMHijjL3as4fTUveMkmBU5hFYiaeRHNC+o6E5yq/gLvNxoPIGpNJWYKsW8L042r+bJm4LAzzh7LKtoDlfbHLYtZ/a3Tpe+qB+Wf4sw4cHO+mYQnn9PgR+VcpLBSHEX0+QP4NGbYhd5KKFNA7izKWyPGE4SxLqr+K2Rnom+zd0hJgr+O+nWzX9gTwjvKXvK4QBj/ewlpCThL+fiAVwC7uxF0f0iTxc/37DcWMPvHkbNhk6sE7cZ8k9TKTPCEwxBLuJ98E+U6DN9Z75sQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ODOEzlDPajyGQ3XwnLvFICiv1/lHkUhXfBOZQ7QjPUg=; b=RqbfU41xgPbNblS86xuhOK7Y1ms/k2HMHtQkRdK0Lb6yvKM0xlqr0+NJ/Uj3tfB1RdFwnrBCDGyXz04EDvv5f9/8/YqiYRH8iAUwTXvjM8ozpeJ7fVNaj0KDKeWi28CBEB8GyWXblcY5Y2jbr99nfhugxieV8LZhQp3ZOeSncXGszwPrzq+9mBRiIO0FyLvl6BFGSNQ073kM+QsvXS7OQSlgUjtVnAw73Va5w+deEwSUZ1Q1qnAV/VzNh7EY+pOOP5ZcbsWp7u++iXb9KF/DoZ6o1ZPYGtwAuHNN2a/6bB6vx6W2ASrT+NGO/9CzVxcbU1Q0+IsXxRQL62nPkM192g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=telekom.de; dmarc=pass action=none header.from=telekom.de; dkim=pass header.d=telekom.de; arc=none
Received: from FR2P281MB0611.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:2c::12) by FR2P281MB0218.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:10::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4331.12; Wed, 14 Jul 2021 08:28:06 +0000
Received: from FR2P281MB0611.DEUP281.PROD.OUTLOOK.COM ([fe80::7caa:6e40:842c:2546]) by FR2P281MB0611.DEUP281.PROD.OUTLOOK.COM ([fe80::7caa:6e40:842c:2546%9]) with mapi id 15.20.4331.022; Wed, 14 Jul 2021 08:28:06 +0000
From: Ruediger.Geib@telekom.de
To: gregory.mirsky@ztetx.com
CC: ippm@ietf.org, ippm-chairs@ietf.org
Thread-Topic: draft-ietf-ippm-connectivity-monitoring-02.txt and draft-mirsky-ippm-epm
Thread-Index: Add4fDpnnNaOKHbESHyi9BUx3LfX4g==
Date: Wed, 14 Jul 2021 08:28:06 +0000
Message-ID: <FR2P281MB0611C9FE3B8F0A9726615DFD9C139@FR2P281MB0611.DEUP281.PROD.OUTLOOK.COM>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: ztetx.com; dkim=none (message not signed) header.d=none;ztetx.com; dmarc=none action=none header.from=telekom.de;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 0063884e-fc5f-4775-440b-08d946a14e4d
x-ms-traffictypediagnostic: FR2P281MB0218:
x-microsoft-antispam-prvs: <FR2P281MB021813BCE55343E0D0CF3CD79C139@FR2P281MB0218.DEUP281.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:8273;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: frvEalrqR3NWoNdm/8Dj8eWLr3e0xFqRbBBR2QSC27RdMg3jGwkE16d/ZASBle4qEzPG/kjuNqKErElT69fM1xBbh+nQDTLUZJ6oDrLNysqxc1XQh9uLmOd6K9i0wfki98cxxvzZMbXymxEC2Y7rBqJegxGUG1wc9foauyILjdRGgfdzPU8dAoX+2zMzP78DeGMwzo5eUiSvIjioMjxx4CzRC4qFAGt6520UsmPkzoc5jomEivSyMNIg3AzeiZI+Pa2/ywKklL/2veDlWBpRDKgDmCnRQADPtPSZwcD+q/JOeEep6NQUncN45aL7BWPC5+uIuGu3pjTiYm8mqeiQMuotHJG380z4DZ078H7YjNxRYdrKg3+Dq44t6i4tWHmCVRf6neHq6GKTF12pT9ZT7Sb/F7hgWByBQ6xTgKfTQtH+cpZBU4M/5f7eS2HG3kvkOZjnD7xgkLTu+NdtyT9So9hhtLPbSiVuaX7Au6oUL14As1wowYt4GqZ+IeQq2CAHIrXsX9Ov6ekkc4FPKPEZYiTI5QminAe6WBmur94aTMEpgJaCqLgCIQKtT84RGAE6YOXbbh4Kith2YNh7+ZDZxYCAYDbfSgDImf+V8G7y96ozgVCuAIcys1CkCbVEPK+OjHgJY8VpFf1XpfTbEtido6HCU0NhXFrqNDEIMmx01bwWATIrePopiQoW1MAOIvSQrqQXzsq6HzcE+hOPr9WoFDc9rWOWHeyoRP6DxGEfgoeS/89L40OlvTLNmEbG7v9qBGmIE2kyUEHvwbADC+d245wGJRtDhyx6QfVqS4Amj6k=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:FR2P281MB0611.DEUP281.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(366004)(396003)(136003)(39860400002)(346002)(376002)(5660300002)(71200400001)(15974865002)(85182001)(38100700002)(966005)(478600001)(122000001)(33656002)(6506007)(83380400001)(76116006)(26005)(7696005)(85202003)(54906003)(316002)(4326008)(8936002)(6916009)(86362001)(52536014)(66446008)(66556008)(66946007)(66574015)(186003)(8676002)(9686003)(55016002)(64756008)(66476007)(2906002)(38070700004); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: SH2uVF7xH/+WwFOjwxv4wS0+fmxJIrN6J4nLrrakhpnvqvypABGSXXI8L+E3sId9HdbomZktrg8meenhRa3NarK4lZXMxndDnJ973ZGfaXZqcchDeaZk/rhofG7G9v7XWQOkMQBDKKHy4+TzNfgSYBIGd7Icltuga3nW9vH3np01bMtsvYXtEP+sfA1MuDrMYDl6UfmoG+gpBBO1Ka4nkuT1RJ+Izp7BezKGc1zBS/Urj0ghAZJJutrRQIevJUZ3239dqXaBzPh5Z0Fyd0eie1b1N/NNPre0wmlGj7a/PI3cQgPwwAxps8c+cpFtq03pGNukN1cGj2DVkkfH5LDKU+ydWyXxR2Bp+TLh/j2I+s4c6c4Gjs+Cjum94hjcUzg4vq8cBT1U5xI4dSlvHNio+swRR4Nub/+xChh/zhpocOZ4gJD5DsOiFWbiRB+gXNIJPBVDsKtz5se8SeanvKRED2ytcna/8tJqP4ymhoL8SX/EhwGcZK4e6djLMEfahak1uecdD8mTVsMldhNv4E9crMS67naQdrSjASbEbeomLZjk03MvZ4t7/nG7Wnbqy7PCAgLbeZqbDpyWZ1CuyIuGdXKxE27zhfJ2un581TyirW4P+Bqsx4i9brevXmjFuVH/em2soLGPdK2hNh2QC7NSVG1DpNh1uwEfQ0mkyqZ0LuQNdF8bc9HHRUjwgGm2aP/e4rxjlHkHikyFLYo/Z7Fia2mwRyDfCymcBP7JTFcbCKpaCJ1rWl0W5Z8YOnwFjOqJWv4Dim/56+uAQ9IiZUvxAm824HoYE24Atr+Pu9j1OQfg3t4gBySEW3SDF6OhlB6Z2DhoRdR93JeLYLaG4lmjedMaOOa6BWaR3oYC9ksZuW2b+4EtVa2bcOQFFSBriwvH/+fuuApGGRPDa2AaKKtE71O1ZtkdMdcYxNWEpfxEV8vcuaNFxrLuXxjsW3viLK6asu4s+ct4SE1B7LakKbqSVO6F5oFF33LhyzCWO+My5K4Wt2VrBjuNeuthNQ2Kwv1i+hks/2j4jrCw/U5zQHdLkkqz93hbxruteFJcIUVZNqjxqbmEOnjOpaS8xwVPN5scWH7q+H5pd8zp0Chd992r81CHoa92+VLwDhu69N+1uZSTndCnCtXZcn+puk7U4JAH4kcOTlV9pz5AmcoAWUSYWcKOGezlq6FcDJ5JiD5U3cCcC7ZrwZDeKv1/y07Fj9Zv3KJs9ccMVucmotA/q3WS+dLoxCGUqRu4fRlOY99C8kWhXOBk/hk+C+Dxg7IcEGsV36RtpS57wKM3hLcJVabrsRWLrzUinDW5It9FuBCOt1A=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: FR2P281MB0611.DEUP281.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: 0063884e-fc5f-4775-440b-08d946a14e4d
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jul 2021 08:28:06.6598 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: gROnadPqrPbI4yxsjb8sZR7u5tLUOx9CFYjeS1w4eoyYgluu/eUz6ATmqan0BnsGiiMnuWGvWumzqP4D3X8roYQJORG+CLOlbR74DDg7Nv0=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: FR2P281MB0218
X-OriginatorOrg: telekom.de
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/0QpMehhbFFLEcU-eVC2EGTyrKn8>
Subject: [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: Wed, 14 Jul 2021 08:28:34 -0000

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