Re: [ippm] Fw: I-D Action: draft-ietf-ippm-connectivity-monitoring-02.txt
Ruediger.Geib@telekom.de Tue, 13 July 2021 06:19 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 724103A1911; Mon, 12 Jul 2021 23:19:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.546
X-Spam-Level:
X-Spam-Status: No, score=-2.546 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_BLOCKED=0.001, 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 6Y002s056CYL; Mon, 12 Jul 2021 23:19: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 344D13A190C; Mon, 12 Jul 2021 23:19: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=1626157167; x=1657693167; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=SQ8M8L1uAnEKzb7lTUbrv9iPTK8Ejrr1wQc4AjMaqsA=; b=Eh03xgHpMpA5IIpsyUa0woX1/BURCwfykFcuSBqidRW2suq6m37SFMFA Ho/SC/Uo1LMN15c09blt+nf0VJTUvLu1AT1GQlSJdFO3yb6EgsQ8mpi6p Oqk6o6wZhTpJ/Gcbh1Mj6aKynSv5sDvJVbMP0oOCt51ablu8uMfm5kne0 o8Lm4sEXEMRiUI4Bh5XRaFGeWOjqec+H5F5fW8Q7d875vGThGFS08XUXb w7goU+m8Qav1Ezj8ABitnpHCxGAsYf4RE+iu8f7xI3cf0U7z+oAKCPw9f dXoCv/UMBKjPu8YR0gAULcQUdDmtPN/KzzBD3kEKn2jAeEHUQbf2LI+Y4 g==;
IronPort-SDR: z2DPZAjKJavaWIOz7xPx0skOZwjEGeyndx1+4+moxT5gxgTszKrt/2yCQ6CQLdg0a1OADjRF2e izCrGz644cUA==
IronPort-HdrOrdr: A9a23:QUFdmamtDHX3GrzlFFHgrLdKJ7PpDfLq3DAbv31ZSRFFG/Fw9vrPoB1173XJYVoqNU3I+urgBEDjexzhHPdOiOF7AV7LZniBhILCFu9fBOXZrwHIKmnbzNdH1aF6c7VvYeeAaGSS9fyKgzWQIpIHx9Wc7abto/zSw2xLUQVgZ7oI1XYcNi+rVmtwSBNaA94eD5eR/e1aozGtYlgHc8ihAXEBNtKzwOEi3/rdEGc77mUcmWuzsQ8=
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; 13 Jul 2021 08:19:24 +0200
IronPort-SDR: o1OYiIuIA2dZxQJ2TLTGQlfKtWs6xbqf6XQacbdcbtVvip8OKCEyg95IEZpIybE1PkLwRkZl7v bQqAdcHRJYW5ayuqwhzKcjz7oH0LDrf4k=
X-IronPort-AV: E=Sophos;i="5.84,235,1620684000"; d="scan'208";a="362203483"
X-MGA-submission: MDF74kTmgLG/6Is9PBZa5VyS4KKJXkmaAgvZardv6VyS1X32d1mQQBuHKICsU6mgbURGQLKwxQ/4PuicB+D9gJ2Q73dclf/y4OLKzXeOMiMQrAkUJcTl45jxYe44Ct/Go4iavOwzr/IOUQBWUkDhJYKKwI36lEUi1R5DBq7850iLVw==
Received: from he199744.emea1.cds.t-internal.com ([10.169.119.52]) by QDEFCV.de.t-internal.com with ESMTP/TLS/ECDHE-RSA-AES128-SHA256; 13 Jul 2021 08:19:25 +0200
Received: from HE199745.EMEA1.cds.t-internal.com (10.169.119.53) by HE199744.emea1.cds.t-internal.com (10.169.119.52) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Tue, 13 Jul 2021 08:19:23 +0200
Received: from HE104162.emea1.cds.t-internal.com (10.171.40.37) by HE199745.EMEA1.cds.t-internal.com (10.169.119.53) with Microsoft SMTP Server (TLS) id 15.0.1497.18 via Frontend Transport; Tue, 13 Jul 2021 08:19:23 +0200
Received: from DEU01-BE0-obe.outbound.protection.outlook.com (104.47.7.174) by O365mail04.telekom.de (172.30.0.231) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Tue, 13 Jul 2021 08:19:23 +0200
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MqHcaZ4NAeHoP96xj98Kl9zO7T9f4Xxh97cAwYdbnnedXFRY2aZ3iy23hkKEF9Q/P4oTaF8/Nc6uIp46iHtGC1xT12EpdnOalcbGL8Tx6PtkurnLFYCuW3gwRMRRzgnR/Zvd147SwLV5qeslvb5IxyhqEQKpmamoMLJZoIYVyQs8gYZPYpE2ktUjKxry4zy8iT9XBquGeqTtTxPngOBrzL3NxMg+mVRzh5SOXmkSxmWG/OkyvRJaERewej5Z6mnRgwbtiM11qt8vDSdeSTbnKkipb959mKuB6a2uUMgKQR6GiXo6kWeBO1Jb1HM3AOpy37tEEj7kjjlLS4XcbemuCg==
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=SQ8M8L1uAnEKzb7lTUbrv9iPTK8Ejrr1wQc4AjMaqsA=; b=h3l3KbfhQp+HCFsBujdHeHzUhDfMoopGbtHa565CcqMQRy0yy/8Gi1Nf7bIgRlBFPXo1ZTqfgvOafagHbCHfhyKvYdC6AUJrfbXeJbOFUzlJdns1JySOnIwj41EI1urhO0QQt5WCXFMDBTVuPaAf3+4M2D+8CoBdWaJ69j9VzqeGhvrs0zXOFZOIrMp9z91yDX4ggesiHJzF2AQP9lkZiV4FOublaU4PO5cQcjqfu6rCL8lX4dsiGhd+TH3jpa8pU5ASq3Z6G9G+2IkyeSqdiZAo7u/OS4HEFjwiZk4nFmRzlLRFU+ULw6CmuwVU21ZjvqD9nT7zHBM2T90R5s57WQ==
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 FRYP281MB0287.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:6::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4331.10; Tue, 13 Jul 2021 06:19:23 +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.021; Tue, 13 Jul 2021 06:19:23 +0000
From: Ruediger.Geib@telekom.de
To: gregory.mirsky@ztetx.com
CC: ippm@ietf.org, ippm-chairs@ietf.org
Thread-Topic: Fw:[ippm] I-D Action: draft-ietf-ippm-connectivity-monitoring-02.txt
Thread-Index: AQHXd5Hcspm5BvUrIEerR/qzHVnO7atAZFyA
Date: Tue, 13 Jul 2021 06:19:22 +0000
Message-ID: <FR2P281MB061139577FD19287EAA252909C149@FR2P281MB0611.DEUP281.PROD.OUTLOOK.COM>
References: 162610119941.11527.1274204599359954796@ietfa.amsl.com <202107131050240681761@zte.com.cn>
In-Reply-To: <202107131050240681761@zte.com.cn>
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: f3b0bd83-8f52-44b3-8700-08d945c6283d
x-ms-traffictypediagnostic: FRYP281MB0287:
x-microsoft-antispam-prvs: <FRYP281MB0287B4F6F8201BDE3D2173849C149@FRYP281MB0287.DEUP281.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: KyeDJTHvYrVgg7+1jh+t8xMIlNJHIcx4vVFdw51+jjEhPY98tG3KXOJBB8VoWuVynecxaQMc/H1LwrztitogD44WTxzpZwOD9pvohTTAUfCck4nEVGKsy4jPa2W2+4cRzEoz3KlTg8A07c5ERpfs+QiDtFFyGrb5eU5RmQ2ma6WODVcKgOA7d2e8Wldwya0mOz25RiTqERg64Wp9CzQfNPeakS10P84Po66h+k1W9O6SatKsRpTUxJOyftVZqymte5r9VqFmNIU3TFKUKol2lEIEEg2wNhgNildAiamSaae5yOPJ2iGIv8h5NuYuin/3RzMlTz7N/Dmi88SRsdySrMvRqMln+TgP/6XwoVnvBjda0vnFe4T6nWLvKbQwbNgYsFb7FZDQ7q59zYlWl6ARnBvXol3oJioCvGpl7ld1Pd8En+jtzD6oqUvcU9PHYp28OqoZw1411GSNNiJIKQTLXbTPnVvn0vZ0V4NnyqH1k1unSFFL04QsY+Wplnlfi4VSvvQGwZhPaq9wzPj9p9CBHCv5oaPdOHBZPtmcGyxVdG6laA2PCzgPG/KoM2QJgjEp0bEQCkbyTO40TVkEh2vsVGIS4gQD9wjMa0/Ue7rUr0dQzRT1YAoeqPU7fnkcBXF4D2QTqYGESoWddnzx1W9+TSkUlxoD/4fgs8pBPNEh55/ZM4LR3OjPeM85tquvg0W9pFXmsTsGVm30xzV5marheOouL8NsJOWW3AK3jOwA2hQ=
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:(376002)(396003)(39860400002)(366004)(136003)(346002)(478600001)(33656002)(2906002)(8676002)(71200400001)(6506007)(85202003)(26005)(186003)(4326008)(15974865002)(66476007)(6916009)(122000001)(86362001)(9686003)(38100700002)(55016002)(7696005)(5660300002)(85182001)(52536014)(316002)(966005)(66574015)(76116006)(8936002)(64756008)(66556008)(66946007)(54906003)(66446008)(83380400001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: xHTppCHITZGeR5gRW0fWk+2zvcBC+RM5kdcEUBq7VFAT+BE/D/d+Opt1Z2jnBcxuUCc/lb8ZKT7oNRiX6F1J3xF130nPlKXz0fo22pMfB5hS+a2xgWQcQX7zv2ugoD85dG2oL1WP8rDDXfk0ryany3y6A1b0fhLRNJOOmJzRvktcKSC7gUU6vSlzrxGN/Bdk61ll3kOk5d2QYGcxW8aP9JTqQYGBw5F8UgkZQ8AHAx+NzISuTPiLx+8s+VyOtajFpWU3b0WhBmhJKaFEc89MWca5Ow4VKS7rr3YcVnyYvwricE5S1Kbb9EuRsNf+YL8t9m3rJ68I5UdvkK2m2c7AEG0k3phHY/vRBeUuulawXgpdeHQJYt8TADhtaJ3nsfVR03n4TBuUO/X45UpvO7Ow/tSboPXMklCFeuFqO/NoNcMCZV9WQSBDJca0M9vw8tO23gMP8E4tszyIJK4A3UH3PPLfEb7oyWBN4Bb8JIokDZf1/SLWL+60f/Ttw8RFEglO6cg95cHHftwwJQVGSXo15xFV693sVohnKKFy4BDbGhvu242f5PZ8Yv5YwpbpTJtFQggPyoq6hFUNc9Dswc8ZjMA7fDpMv84WulCFyDAfpQvHoMBsLQowUZ/wBh5VdgvOgXVUld8vPniMYBduB39t+fKi9TN85Cv3VDYMwvqmIFiIycgz62oIGHCvui5XQDAFzkCYeOE73j3I4j+NwzQC7IxYRoGd406UC4KOyWzG8fVbWfcj+e5aiArjbL1+APZkK3FG4nqPS3Ho7Uo40YCEpQStJeYAs3xJhU5u31wbXRhnrOCxyDBv1CPDvKgZhjwkjVQTzL5Gi1Xkt+i5mBqBwhCw6jPcM/j7RGccJET5AUknSzMnInpUbXaZwMVTvqEorLuZ/goB/nPHdhmbWoE9GVfTH/iDCmz155l3iJ+4giVnTdfpMV1j3dSrThUaxANGzthD9J4hDpQObvMlh7S8ahduKf/Bx32YZeKlwG8Dz4xVg0p8Sko9hwQypOuMnVVKPx1iEgL13MPsaO79SyUcYE5eKRlaajHauc1UKzV9hHXXy39BBueLxe8eBiMKW4/9NXG6eGilLdyHw5i6b8S1ZR7Ys6MqPTWoC/FhJYm0jTqSjXtKVOE1Qs6bucAnNB26hZeuvW89L7VrbN7pN2fqfo4aYGprZD/XOJFFRk7YPwjoMCAjXiTjr4b7TYvowtA5/1ROYOy0S6kaEcjkdA0nADTC+7sYhfmsozPJlY8diov+2FYbuDAgqux5QIBsFRqhje1A0lQOm+T/qfJGJdWnMikGTIRvgi4Xq8Xgq67RQcbR6fT6XWQr02fxrMserFVS
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: f3b0bd83-8f52-44b3-8700-08d945c6283d
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jul 2021 06:19:22.9527 (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: R75v5ZwaVXQAy9QR5ESf1pXbLFWY4WAktTnQKzMaJ0AQYsgBWuQVSZ9Cb9Jm7E4PP784kB+0XJ6EAomgWr3r/KjWVQnCMQ+bb9a3salTpDo=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: FRYP281MB0287
X-OriginatorOrg: telekom.de
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/fVY4KUn1txNMmx2_LJOlXW_0AwM>
Subject: Re: [ippm] Fw: I-D Action: draft-ietf-ippm-connectivity-monitoring-02.txt
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 06:19:34 -0000
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
- [ippm] I-D Action: draft-ietf-ippm-connectivity-m… internet-drafts
- [ippm] Fw: I-D Action: draft-ietf-ippm-connectivi… gregory.mirsky
- Re: [ippm] Fw: I-D Action: draft-ietf-ippm-connec… Ruediger.Geib
- Re: [ippm] Fw: I-D Action: draft-ietf-ippm-connec… gregory.mirsky