From nobody Thu Nov 19 07:16:18 2020 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 945B03A0A26; Thu, 19 Nov 2020 07:16:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.597 X-Spam-Level: X-Spam-Status: No, score=-9.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=MBmJpvkk; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=kmEPn5ip 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 1TPe4BD8434m; Thu, 19 Nov 2020 07:16:08 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4429F3A09CC; Thu, 19 Nov 2020 07:16:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=87550; q=dns/txt; s=iport; t=1605798966; x=1607008566; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=j8bQafjxvdYlFUTeyXmxR96+i4P5WYOogPn8Tv9N1IU=; b=MBmJpvkkT98/1JKoyuu+bXwVftaO+9QkdKbkPaMzJDZrE1Md7L6VALtB G54wmPi6D0Zbm7VOsg4sVEXEBVKcyIFB44ZdvRquur3NJFfPkN0oSdIwU QER2taFYCCmvhqu3KueA7Gxxl/GmuFVeUaXOTrrbn10K94wJfB6GOTmVQ g=; X-IPAS-Result: =?us-ascii?q?A0DmAQBbi7Zf/4wNJK1iGwEBAQEBAQEBBQEBARIBAQEDA?= =?us-ascii?q?wEBAUCBT4EjLyMuB3RZLy4Kh3wDjVyKFY5ugUKBEQNPBQsBAQENAQEYAQwIA?= =?us-ascii?q?gQBAYRKAoIpAiU4EwIDAQEBAwIDAQEBAQUBAQECAQYEcYVhDIVyAQEBBAEBE?= =?us-ascii?q?AgBAiMBASUHBAcBDwIBCBABAwEBASEBBgchBgsUCQgCBAENBQgMBweDBYF+V?= =?us-ascii?q?wMuAQ6kIwKBPIhodIE0gwQBAQWBMwEDAg5BgxENC4IQAwaBOIJzgmZOgUiBP?= =?us-ascii?q?oQTG4FBP4EQAUOCTz6CG0IBAQIBAYEhBQESASMFGQYHCQKDEoIskB8CEgYMC?= =?us-ascii?q?SmCOIdbgyqYdwkvVQqCbYkShmSGEYU1gxqKF4VMjn+TVIsBgm6ONIFOgmgCB?= =?us-ascii?q?AIEBQIOAQEFgWsjZ3BwFTuCNQEBMlAXAg2OHwwXFIM6hRSFQwF0AjUCBgoBA?= =?us-ascii?q?QMJfIw7ATFfAQE?= IronPort-PHdr: =?us-ascii?q?9a23=3AbAdaSB8a97lXjv9uRHGN82YQeigqvan1NQcJ65?= =?us-ascii?q?0hzqhDabmn44+7ZRKN5ehkk1LIG47c7qEMh+nXtvXmXmoNqdaEvWsZeZNBHx?= =?us-ascii?q?kClY0NngMmDcLEbC+zLPPjYyEgWsgXUlhj8iK7LEFKFce4bFrX8TW+6DcIEU?= =?us-ascii?q?D5Mgx4bu3+Bo/ViZGx0Oa/s53eaglFnnyze7R3eR63tg7W8MIRhNhv?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.77,490,1596499200"; d="scan'208,217";a="586894189" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 19 Nov 2020 15:15:33 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by alln-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id 0AJFFTbe007790 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 19 Nov 2020 15:15:31 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 19 Nov 2020 09:15:30 -0600 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 19 Nov 2020 10:15:29 -0500 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 19 Nov 2020 10:15:29 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RX4CDgg/Z3CLs9dBeuID/2dXiXMqVsfxQ4C2bS9k7hi94uCPx5YtZaNjWGqglImu1xHB9RV4bvpc+Wo8Thp0x2u8S1SO7OYzoi7SQ8pDsDJ0yh29tZdEdlY5jdclpw+yWzXpZcChhcHR7eApOySSXopdfAK1X9ft0zaJRwEsLswIWFUucFcA4bVFlB7NfkqtRX3limYJ0p7vn3UjxSIC4L5UicQju4CU6Lcy9zp9SDt9X2exmt11xuR2Gx8v5voEQlizkyplpxiS3V+YgC4YrjNtp9BnrRSF+JdZcxVNoghc3ksYuBiXoiLi57rn6CjgbMIV3zjovig726YKA2hqbw== 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=xwADS3b0YQzFfh90jE6YIf5JKg7YtV5OplyUqV/Ab0E=; b=SthC3Qxr6S/es4bAAydl40G52u5cMsABqXNQW+gdrAUc0C0UkKBaojUhDI2kD/oDzUKOS5hkv0ukcGlHxxxUKqDF7IJ+Yh+ORKhRiOQtNhpQiR1g2sIKAWVc80IMl4eAaZ3TUmiKB+Ngc+bigTi1f/TnEvw9ZhXGsnAxeBLs6Hk9dYEuG1QdFgoanKZJj4FqhUWFOUJIp1D8nZZf68kqdvwO+6ku42PeRoOUGn0ULU/pLnBxIdFtMafs4R3OARhJM0nQlAPY1bCQtCBi7YIe3jjv+T8x3DbxDeR0qhHInIKytXlkBXerDMZeFIE8Wd7RcChS3uIrPI+Jd96D/1OFCg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xwADS3b0YQzFfh90jE6YIf5JKg7YtV5OplyUqV/Ab0E=; b=kmEPn5ipvat6upFmF/4FzuaNyTcw/FSyKxnL8PX3V+Oo43ROiWTkQEmAVdb5MOiEldCJjtcr+OS9Ni4bFlA443OU3POmeaUYTmbSPkmmg0cPG41V9oF/7TOPX3xE0s2Ab9B2jxIkRz+5GK4bnKLM+Npbc0D+fZozXjeauckgMJY= Received: from DM6PR11MB3115.namprd11.prod.outlook.com (2603:10b6:5:66::33) by DM6PR11MB2683.namprd11.prod.outlook.com (2603:10b6:5:c6::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.22; Thu, 19 Nov 2020 15:15:27 +0000 Received: from DM6PR11MB3115.namprd11.prod.outlook.com ([fe80::d503:17c8:a0f6:199e]) by DM6PR11MB3115.namprd11.prod.outlook.com ([fe80::d503:17c8:a0f6:199e%6]) with mapi id 15.20.3564.031; Thu, 19 Nov 2020 15:15:27 +0000 From: "Rakesh Gandhi (rgandhi)" To: Mach Chen , Tianran Zhou , Greg Mirsky CC: spring , IPPM Chairs , "spring-chairs@ietf.org" , Tommy Pauly , "IETF IPPM WG (ippm@ietf.org)" Thread-Topic: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and draft-gandhi-ippm-stamp-srpm Thread-Index: AQHWrutqxCpe6zKAOkqELdQ0D7z91KnAEieAgAGGXIqABKdzAIAEHsI6gAAB1ACAAqNDgIAAE4+WgAH1xICAACO6gIAAfByt Date: Thu, 19 Nov 2020 15:15:26 +0000 Message-ID: References: , , In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-CA X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [174.112.172.213] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c5d6c633-297a-4cb5-e7b8-08d88c9df204 x-ms-traffictypediagnostic: DM6PR11MB2683: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: XRGPAiQZDcgVbD0hkOFXT2mWrtPbnBuNSGty8FmmU1FNlwCMT80trevwm0mdEGdlNyN1Sl/5OLHaP32f1HLwhuI5UzurLNfUqYmTBASf2yZQzYlG66LK1mCqL8uis5Eka6yPfysYTTzWIOh53nHL7Dp5Zb1pTqqzdo/uHk3bJduv1zi2Ts/ZadOQK5+ZWWuGb0yarC0AWBJHN+Jl9QjpC1BHJxofr3UvvZ+JyJx0CkupZ2Hqd1WcgTAEgNXSwKbBHP7kxByP4XXgaHsY8H7Q3TLfsLbtaF8ISSP1gJ5l8LSUP2S970EpN6npjLwgxIvsaIDvgFe1fw6uL2n5jDDEqmoiX8JYdcuSvE8xJ4lH8iw0tMDEjET29GGqhOQC3f0o2jEBO+PQ7RNSuQF09qe/nA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR11MB3115.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(136003)(376002)(396003)(366004)(39860400002)(52536014)(966005)(110136005)(55016002)(478600001)(2906002)(30864003)(86362001)(9686003)(5660300002)(4326008)(71200400001)(8936002)(8676002)(83380400001)(6506007)(53546011)(54906003)(33656002)(7696005)(66946007)(316002)(26005)(186003)(166002)(76116006)(66556008)(64756008)(19627235002)(66476007)(91956017)(66446008)(559001)(579004); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: LtMcWKm3u7z76YTEBxmp+TqxPOGYiZvlXWFuz9mlWhxsDtWNpb7BlzMOuiuQKSHvge44UiIxqlc6BAA5iyGWz53OCoAtQYjCUSsE84mMBFmZV9OUmo5gcm5g9/SpX3bEo+SC3aKS1mfQruiK3vm8fv34D5e+6grAHTDPF2ZgbH+ksPoL2FfHN1AcLoMlfyLr9EN5LU76nZLax6xKfthL9PCkORI9Lpz2eqGYQRWO+JwrATXbisHAUPu9rasi69v8Isvyf57ccPypad/WJ6nfiTyhWEppknxCDGaV6sGILlfmYPl0DLPTA614LESYL7O4WlJNW9+8wRiPS+PUbAmR34remCkFdvNZr/ubXI49Qi+iWIXkKUSPT5MNnMuih/MQXF7iDxdgrtoDCE1T8KnRkX/lKlkjB2TaBxSgYUogUB/T2/OHbYOSt+m7a8dzjxOPAHm+aJ3reyUHRCugpD9dllFgg6ePY41H75o4wedHZSctUSpaUkxlzRoMWpyvPvmSqhwZnRWX5q6MiSkbxqF/nUI2JV3GcdHEq6FTCQexDSJOsNtKrsvLr1U1PrjXt8nnghGfu4kQ6Dn/nKyRLbI8P90+jR0a4heD3GIzZe6cOk2YQfJR0hWQLRNRXhk+6UiJFPd60RnHqWQJd8w1CSZnWBuCLJ/szt0rrgfw2E/JeCYgpg1Gs48k2gRo9ig9+unvoy9F9vIFbBmsXQbXy67tQdMj7mZU9wAI5Ou3v7bqyClhETl0MwA/HrzlkKsmY/vLUeNVX/9n7HnvfH7qIcSJMp2J/WoaKoiGlLf0Pg2uprNYPWiW6cPQsQVIGT+V8TLOTgVhibLsItRMrqwtjbIbHRmAsg3g+5bmV8vfZBMeJI3gEbtweHbgDaq7etoYL9LVYJCauvL88p871MOSZQfWZw== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR11MB31159A70B271EDD1D7F9201FBFE00DM6PR11MB3115namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR11MB3115.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: c5d6c633-297a-4cb5-e7b8-08d88c9df204 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Nov 2020 15:15:26.9814 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: qyXoWsHcgO33u2MHyjGZs7zCNN5AVTyJpB/mXDzdJ3UTR2LSedNxOVNUANZ09Pp0qZz5l5uxReRk6mIImZS5EQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB2683 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com X-Outbound-Node: alln-core-7.cisco.com Archived-At: Subject: Re: [spring] [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and draft-gandhi-ippm-stamp-srpm X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 15:16:13 -0000 --_000_DM6PR11MB31159A70B271EDD1D7F9201FBFE00DM6PR11MB3115namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thank you Mach and Tianran for your review comments. Please see inline reply with =85 From: Mach Chen Date: Thursday, November 19, 2020 at 2:41 AM To: Tianran Zhou , Rakesh Gandhi (rgandhi) , Greg Mirsky Cc: spring , IPPM Chairs , spring-ch= airs@ietf.org , Tommy Pauly , IET= F IPPM WG (ippm@ietf.org) Subject: RE: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and dra= ft-gandhi-ippm-stamp-srpm Hi Tianran, Rakesh and Greg, Please see some responses inline with [Mach]=85 From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Tianran Zhou Sent: Thursday, November 19, 2020 1:33 PM To: Rakesh Gandhi (rgandhi) ; Greg Mi= rsky Cc: spring ; IPPM Chairs ; spring-ch= airs@ietf.org; Tommy Pauly ; IETF IPPM= WG (ippm@ietf.org) Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and dra= ft-gandhi-ippm-stamp-srpm Hi Rakesh and Greg, I may not very clear about the context. Please allow me to jump in. It seems both of you make some valid point. Please see in line with . Cheers, Tianran From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Rakesh Gandhi (r= gandhi) Sent: Wednesday, November 18, 2020 7:41 AM To: Greg Mirsky > Cc: spring >; IPPM Chairs >; spring-chairs@ietf.org; Tommy Pauly >; IETF IPPM WG (ippm@ietf.org) > Subject: Re: [spring] [ippm] Call for adoption: draft-gandhi-ippm-twamp-srp= m and draft-gandhi-ippm-stamp-srpm Hi Greg, Thank you for your review and discussions on the drafts. This will help imp= rove the work on this important work. Please see replies inline with .. From: Greg Mirsky > Date: Tuesday, November 17, 2020 at 5:27 PM To: Rakesh Gandhi (rgandhi) > Cc: Tommy Pauly >, IPPM Chairs >, spring-chairs@ietf.org >, IETF IPPM WG (ippm@ietf.o= rg) >, spring > Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and dra= ft-gandhi-ippm-stamp-srpm Hi Rakesh, WG Chairs, and All, I've read the responses to my detailed comments. I don't think that only ad= ding references will solve the problems with the documents. If authors are = interested in addressing my comments, we can start working on solving them = one by one. As mentioned in previous replies, we can add references for the well-k= nown terms =93Links=94, =93Congruent Paths=94, =93SR Path=94. If you prefer= , we can define them here. For Zero checksum field, we can add a reference = for the RFC 6936 in Security section and also add some text for it. Will be= happy to work with you to address these. But I am very much concerned with the technical value of these drafts. And = here's why I feel that the proposed documents don't provide a sound technic= al solution to the task of direct loss measurement. Please find my reasonin= g explaining my opinion of the *-twamp-srpm and *-stamp-srpm: * What is being proposed in these drafts? Drafts *-twamp-srpm and *-stamp-srpm propose a new protocol to support dire= ct packet loss measurements. Note, that RFC 6374 includes a method for dire= ct loss measurement in MPLS networks that is applicable to the SR-MPLS envi= ronment. Also, draft-ietf-ippm-stamp-option-tlv defines an extension to RFC= 8762 STAMP, the Direct Measurement TLV, that supports the direct packet lo= ss measurement. STAMP and all its extensions are applicable in IPv6 network= s and, thus, can be used in the SRv6 domain. As mentioned in previous replies, both RFC 6374 (in Section 4.2) and I= TU Y.1731 (in Section 8.1) define stand-alone messages for collecting TX an= d RX counters for direct-mode loss measurement. TWAMP/STAMP messages define= d in the drafts are equivalent of them that take advantage of the widely de= ployed TWAMP protocol and as well this same protocol can be deployed in IPv= 4/IPv6/MPLS/SRv6/EVPN/etc. networks. I think RFC6374 for MPLS and Y.1731 make some noise here. The point i= s if we need a new direct packet loss measurement for STAMP, when STAMP alr= eady defined a Direct Measurement TLV (https://datatracker.ietf.org/doc/dra= ft-ietf-ippm-stamp-option-tlv). If current Direct Measurement TLV cannot fu= lfill some use case requirement, then how about proposing a new TLV. [Mach] Given that TWAMP does not support TLV, I assume that the discussions= are mainly about draft*-stamp-srpm. [Mach] In the case of direct packet loss measurement, draft-gandhi-ippm-sta= mp-srpm assumes that marking-based solution (which can address the packet o= ut-ordering issue) is used, hence the block number is introduced. The block= number is used to correlate the counters from the sender and reflector. Th= e current direct loss measurement TLV may just apply to the scenario withou= t packet out-ordering. To further add to this, as TWAMP Light does not have a TLV, we need = to define a stand-alone message for direct-mode LM. STAMP is just the same = message but fixed length, so this way both can interoperate and also we can= leverage the message for both of these protocols. For STAMP direct-mode LM TLV approach, some technical details are in the dr= aft as well: The STAMP message with a TLV for "direct measurement" can be used for combined Delay + Loss measurement [I-D.ietf-ippm-stamp-option-tlv]. However, in order to use only for loss measurement purpose, it requires the node to support the delay measurement messages and support timestamp for these messages (which may also require clock synchronization for one-way delay). Furthermore, for hardware-based cou= nter collection for direct-mode loss measurement, the optional TLV based processing adds unnecessary overhead (as counters are not at well-known locations). [Mach] In addition, whether to keep it as current design or to define a new= TLV for direct loss measurement can be debatable. How the proposed method of direct packet loss is related to TWAMP light and= STAMP? There's no apparent technical relationship between *-twamp-srpm and TWAMP L= ight, or *-stamp-srpm drafts and STAMP. Drafts do not extend or re-use the = basic mechanisms defined for TWAMP-Test and/or STAMP in their respective s= pecifications. Rather than that, drafts introduce a new query-response mode= and new formats of test packets that are decisively different from the for= mats defined in respective specifications. As a result, the new protocols a= re required to use different from used by TWAMP Light tr STAMP test session= UDP port numbers on the responder. And that is another clear indication th= at the proposed mechanism represents a new protocol, neither extends TWAMP = Light and/or STAMP nor updates their specifications. As mentioned in previous replies, other than timestamp vs. counter and= it=92s format, the messages and processing of them are the same for delay = and direct-mode loss measurement. * Is there any advantage in introducing a dedicated packet format for t= he direct packet loss in STAMP comparing to using the Direct Measurement TL= V extension? Though it appears the using a dedicated packet format instead of TLV is mor= e efficient, but the dedicated for the direct loss measurement format is li= kely to precede one or even two TLVs, Node Address TLV and Path TLV, define= d in draft-gandhi-ippm-stamp-srpm. As a result, processing of the new packe= t with TLVs is unlikely to be more efficient and reduce the processing dela= y, than if using the Direct Measurement TLV as defined in draft-ietf-ippm-s= tamp-option-tlv. As mentioned in previous replies, this is explained in Section 1 of th= e draft-gandhi-spring-stamp-srpm. For link loss measurement (direct-mode), there is = no TLV required for example. For direct-mode loss measurement in SR network= s, it would typically be forward direction packet loss measurement (and not= bidirectional). * What are the potential benefits of specifying the return path in the = new test packet's Sender Control Code? Using the Sender Control Code may require the use of the additional TLV tha= t carries the return path information, Path TLV. If the ability to control = the return path is required that can be achieved by augmenting the STAMP YA= NG data model (draft-ietf-ippm-stamp-yang) rather than including the Path T= LV in each test packet. Hence, there seem no technical requirements to intr= oduce the Sender Control Code field in the Base STAMP format defined in RFC= 8762. Per session basis between different sender nodes and this reflector no= de, some senders will request the replies in-band (e.g. for two-way mode). = Sessions are provisioned on the Sender nodes and reflector simply reflects = based on the received test-packet (e.g. for a bidirectional SR path). This = is also similar to as described Section 3.1 in RFC 6374, top of page 22. Th= ere is no need to create a such state for each session on the reflector nod= e and create a scale limitation. Recall that we are trying to avoid the sca= le limitation by eliminating the Control protocol signaling. I find some value to include the path TLV in wire. As Rakesh mentione= d, this can reduce the reflector configuration. But I am not convinced to i= ntroduce the sender control code field. It seems to me, the presence of pat= h TLV indicates the bidirectional congruent path. Vise versa. [Mach] Regarding how to specify the return path, the draft defines two ways= to achieve that, one is to use control code to direct whether the reflecte= d Test should be along the reverse path of a bidirectional path, this appli= es to both TWAMP (no TLV mechanisms) and STAMP. At the same time, in the ca= se of STAMP, it also defines the return path TLV to explicitly specify the = return path, which bring more options to specify the return path. Therefore= , I see benefit of the two ways. To further add to this, the IPPM draft simply defines protocol extens= ions. The use-cases are there in the corresponding spring drafts. For examp= le, for links, no return Path TLV is used, etc. In other words, the use-cas= es are different for the two, and there is no TLV in TWAMP anyways. Thanks, Rakesh Best regards, Mach What is the relationship between the *-srpm drafts and BFD? Some text in the *-srpm drafts suggest that the proposed method can be used= to monitor for the loss of a path continuity. That may be viewed as an alt= ernative to the BFD protocol method for the detection of a network failure.= If the discussion of Loopback mode and monitoring of liveness remain in th= e drafts, it seems logical that the BFD WG and BFD WG's Chairs be made awar= e of the proposals. I didn't take the liberty of adding BFD WG or its Chair= s. I believe that decision to be made by the Chairs of IPPM And SPRING WGs. As mentioned in previous replies, STAMP/TWAMP test messages are also u= sed today for synthetic packet loss measurement which can be also used to d= etect/monitor connection loss (performance metric). The draft simply highli= ghts this obvious metric. This is also very similar to what is described in= ITU Y.1731, Section 7.1. Thanks, Rakesh Regards, On Sun, Nov 15, 2020 at 10:10 PM Greg Mirsky > wrote: Hi Rakesh, thank you for your prompt response, much appreciated. I'll carefully read y= our responses. Looking forward to the continued discussion. Regards, Greg On Sun, Nov 15, 2020 at 10:07 PM Rakesh Gandhi (rgandhi) > wrote: Hi Greg, Thank you for your review comments. As mentioned in the IPPM session today,= the email response was sent as attachments, see archive blow: https://mailarchive.ietf.org/arch/msg/ippm/J503n-B2yOxF0urcHtGQKnqCRDE/ I am attaching them in word documents for the convenience. We can address y= our comments below in the next revision of the document. Thanks, Rakesh From: Greg Mirsky > Date: Friday, November 13, 2020 at 10:09 AM To: Rakesh Gandhi (rgandhi) > Cc: Tommy Pauly >, IPPM Chairs >, spring-chairs@ietf.org >, IETF IPPM WG (ippm@ietf.org) > Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and dra= ft-gandhi-ippm-stamp-srpm Hi Rakesh, thank you for your response to my review. Please find my follow-up notes in= -lined below under the GIM>> tag. I hope you've found more detailed comments in the attachments (re-attached = for your convenience). I'm looking forward to reading your responses to the= detailed comments of all four drafts. Regards, Greg On Tue, Nov 10, 2020 at 8:11 AM Rakesh Gandhi (rgandhi) > wrote: Thank you Greg for taking time for thoroughly reviewing the documents and p= roviding the comments. Attached please find the email replies to your revi= ew sent earlier. The replies are copied inline below for convenience, tagg= ed with . From: ippm > Date: Monday, November 9, 2020 at 11:48 AM To: Tommy Pauly > Cc: IPPM Chairs >, spring= -chairs@ietf.org >, IETF IPPM WG (ippm@ietf.org) > Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm and dra= ft-gandhi-ippm-stamp-srpm Dear WG Chairs, Authors, and IPPM WG community, I've reviewed these drafts and have some comments to share. Below, please f= ind my thoughts on whether these drafts can be adopted. More specific comme= nts on each pair of drafts (TWAMP-related and STAMP-related draft and its a= ccompanying draft targetted to the SPRING WG) are in the attached documents= . Usually, the bar for the adoption of a document can be evaluated by answers= to these three questions: =95 Is the document(s) reasonably well-written I've got surprised that the drafts don't use the terminology from RFCs 4656= /5357 and RFC 8762, and introduce their own terminology for Session-Sender = and Session-Reflector. Also, many terms, e.g., Links, "congruent paths", ar= e used in the documents without proper definitions. Other than that both dr= afts are readable and reasonably well-written. We can change Sender to Session-Sender and Reflector to Session-Refl= ector if it helps. GIM>> I believe that the consistency in terminology between the core RFC an= d what is intended as its extension is not only helpful to a reader but, to= the best of my understanding, is required for IETF specifications. There are many existing RFCs that use term Link (e.g. RFC 5613, 5340= , 8330, etc.) and term Congruent Path (e.g. RFC 5921, 6669) without definin= g them. I suspect it is because these are well-known terms. Having said tha= t, we can add a reference for them if it helps. GIM>> Thank you for listing these RFCs. I think I need to clarify my questi= ons. While a reference to any of RFCs you've mentioned, I don't think that = will address my concern. In reviewed documents, "Link" is capitalized while= referenced RFCs used the lower case form for the term "link". Can these be= used interchangeably? Do they refer to the same network object? Now I'll try to illustrate my concern with using the term "congruent path" = in these drafts (using ASCII-art): C---------D / \ A----B E-----F \ / G------------H Consider an SR tunnel from A to F that traverses the network as A-B-C-D-E-F= . From the definition of "congruent" as "two figures or objects are congrue= nt if they have the same shape and size, or if one has the same shape and s= ize as the mirror image of the other", path A-B-G-H-E-F is congruent to the= SR tunnel. But a packet of an active OAM intended to monitor a flow over t= he SR tunnel is out-of-band and will not produce any meaningful measurement= . Of course, for the case of the extensions in drafts, direct loss measurem= ent can be performed, as information collected from node F. So, this exampl= e, in my opinion, illustrates two of my concerns: * using a congruent path for an active OAM protocol may produce informa= tion that does not reflect the condition experienced by the monitored flow.= It seems that the terminology should reflect the fundamental requirement f= or using active OAM to maintain the test packets in-band with the monitored= flow. * there are no technical requirements to justify using in-band active O= AM protocol for direct packet loss measurement. As demonstrated in this exa= mple, direct packet loss can be performed using an out-of-band mechanism, e= .g., SNMP queries, Netconf notifications based on YANG data model. =95 Does the document solve a real problem? No, it appears that both TWAMP and STAMP drafts define a new performance = measurement protocol for the purpose of combining OWAMP/TWAMP and STAMP fun= ctionality in the respective drafts, and adding the ability to collect coun= ters of "in-profile" packets. I couldn't find sufficient technical argument= s for using a PM protocol instead of, for example, extending the existing O= AM mechanisms like ICMP multi-part message extension per RFC 4884. There is a requirement to measure performance delay as well as synth= etic and direct-mode packet loss in segment-routing networks. OWAMP and TWA= MP protocols are widely deployed for performance delay and synthetic packet= loss measurement today. I am not sure extending ICMP for LM is a good opti= on here. GIM>> I agree with the requirements you've listed (though the SPRING WG OAM= requirements document has been abandoned and expired 3+ years ago). I believe th= at there's no sufficient technical reason to use OWAMP/TWAMP/STAMP for excl= usive direct packet loss measurement. =95 Is the proposed solution technically viable? There are too many unaddressed aspects, particularly the risk introduced by= the protocols on network security, to comprehensively evaluate the propose= d solutions. About your comment on zero checksum, this is described in Security s= ection in RFC 6936. We will add reference to this RFC in our Security Secti= on as well. This is only specific to the UDP port locally provisioned in th= e domain by the operator for STAMP or TWAMP Light. Other than this, I did n= ot find any other security related issue in your review. GIM>> I don't think that a mere reference sufficiently explains why the use= of zero UDP checksum in IPv6 header is not decremental, does not create a = security risk for the protocol. Thanks, Rakesh Regards, Greg On Fri, Oct 30, 2020 at 11:35 AM Tommy Pauly > wrote: Hello IPPM, For the past few meetings, we=92ve had updates on the work in the SPRING WG= that was using STAMP and TWAMP. Since those documents ended up making exte= nsions to the base protocols, the chairs of SPRING and IPPM decided that it= would be best to split the documents and track the IPPM extension work in = the IPPM WG. As such, we are starting a Working Group call for adoption for draft-gandhi= -ippm-twamp-srpm and draft-gandhi-ippm-stamp-srpm. The documents are here: https://tools.ietf.org/html/draft-gandhi-ippm-stamp-srpm-00 https://tools.ietf.org/html/draft-gandhi-ippm-twamp-srpm-00 The related SPRING documents are here: https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-03 https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 Please provide your feedback on these documents, and state whether or not y= ou believe the IPPM WG should adopt this work by replying to this email. Pl= ease provide your feedback by the start of the IETF 109 meeting week, on Mo= nday, November 16. Best, Tommy & Ian _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm --_000_DM6PR11MB31159A70B271EDD1D7F9201FBFE00DM6PR11MB3115namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Thank you Mach and Tia= nran for your review comments.

Please see inline repl= y with <RG2>=85

 

From: Mach Chen <mach.= chen@huawei.com>
Date: Thursday, November 19, 2020 at 2:41 AM
To: Tianran Zhou <zhoutianran@huawei.com>, Rakesh Gandhi (rgan= dhi) <rgandhi@cisco.com>, Greg Mirsky <gregimirsky@gmail.com> Cc: spring <spring@ietf.org>, IPPM Chairs <ippm-chairs@ietf= .org>, spring-chairs@ietf.org <spring-chairs@ietf.org>, Tommy Paul= y <tpauly@apple.com>, IETF IPPM WG (ippm@ietf.org) <ippm@ietf.org&= gt;
Subject: RE: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm = and draft-gandhi-ippm-stamp-srpm

Hi Tianran, Rakesh and Greg,

 

Please see some responses inline with [Mach]=85=

 

From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Tianran Zhou
Sent: Thursday, November 19, 2020 1:33 PM
To: Rakesh Gandhi (rgandhi) <rgandhi=3D40cisco.com@dmarc.ietf.org= >; Greg Mirsky <gregimirsky@gmail.com>
Cc: spring <spring@ietf.org>; IPPM Chairs <ippm-chairs@ietf= .org>; spring-chairs@ietf.org; Tommy Pauly <tpauly=3D40apple.com@dmar= c.ietf.org>; IETF IPPM WG (ippm@ietf.org) <ippm@ietf.org>
Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm = and draft-gandhi-ippm-stamp-srpm

 

Hi Rake= sh and Greg,

 <= /span>

I may n= ot very clear about the context. Please allow me to jump in.

It seem= s both of you make some valid point.

Please = see in line with <ZTR>.

 <= /span>

Cheers,=

Tianran=

 <= /span>

From: spring [mailto:sprin= g-bounces@ietf.org] On Behalf Of Rakesh Gandhi (rgandhi)
Sent: Wednesday, November 18, 2020 7:41 AM
To: Greg Mirsky <gregimi= rsky@gmail.com>
Cc: spring <spring@ietf.org>; IPPM Chairs <ippm-chairs@= ietf.org>; spring-chairs@ietf.org; Tommy= Pauly <tpauly=3D= 40apple.com@dmarc.ietf.org>; IETF IPPM WG (ippm@ietf.org) <ippm@ietf.o= rg>
Subject: Re: [spring] [ippm] Call for adoption: draft-gandhi-ippm-tw= amp-srpm and draft-gandhi-ippm-stamp-srpm

 

Hi Greg,

 

Thank you for your rev= iew and discussions on the drafts. This will help improve the work on this = important work.

Please see replies inl= ine with <RG>..

 

 

From: Greg Mirsky <gregimirsky@gmail.com>
Date: Tuesday, November 17, 2020 at 5:27 PM
To: Rakesh Gandhi (rgandhi) <rgandhi@cisco.com>
Cc: Tommy Pauly <tpauly=3D40apple.com@dmarc.ietf.org>, IPPM Chairs <ippm-chairs@ietf.org>, spring-chairs@ietf.org <spring-chairs@ietf.org>, IET= F IPPM WG (ippm@ietf.org) <ippm@ietf.org>, spring <spring@ietf.org>
Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm = and draft-gandhi-ippm-stamp-srpm

Hi Rakesh, WG Chairs, and All,

I've read the responses to my detailed comments. I d= on't think that only adding references will solve the problems with the doc= uments. If authors are interested in addressing my comments, we can start w= orking on solving them one by one.

 

<RG> As mentione= d in previous replies, we can add references for the well-known terms =93Li= nks=94, =93Congruent Paths=94, =93SR Path=94. If you prefer, we can define = them here. For Zero checksum field, we can add a reference for the RFC 6936 in Security section and also add some text for it. Will b= e happy to work with you to address these.

 

But I am very much concerned with the technical valu= e of these drafts. And here's why I feel that the proposed documents don't = provide a sound technical solution to the task of direct loss measurement.&= nbsp;Please find my reasoning explaining my opinion of the *-twamp-srpm and *-stamp-srpm:

  • What is being proposed in these drafts?

Drafts *-twamp-srpm and *-stamp-srpm propose a new p= rotocol to support direct packet loss measurements. Note, that RFC 6374 inc= ludes a method for direct loss measurement in MPLS networks that is applica= ble to the SR-MPLS environment. Also, draft-ietf-ippm-stamp-option-tlv defines an extension to RFC 8762 STAMP, t= he Direct Measurement TLV, that supports the direct packet loss measurement= . STAMP and all its extensions are applicable in IPv6 networks and, thus, c= an be used in the SRv6 domain.

 

<RG> As mentione= d in previous replies, both RFC 6374 (in Section 4.2) and ITU Y.1731 (in Se= ction 8.1) define stand-alone messages for collecting TX and RX counters fo= r direct-mode loss measurement. TWAMP/STAMP messages defined in the drafts are equivalent of them that take advantage = of the widely deployed TWAMP protocol and as well this same protocol can be= deployed in IPv4/IPv6/MPLS/SRv6/EVPN/etc. networks.

 

<ZTR> I think RFC6374 for MPLS and Y.1731 make= some noise here. The point is if we need a new direct packet loss measurem= ent for STAMP, when STAMP already defined a Direct Measurement TLV (http= s://datatracker.ietf.org/doc/draft-ietf-ippm-stamp-option-tlv). If current Direct Measurement TLV cannot fulfill some use case requirement= , then how about proposing a new TLV.

 = ;

[Mach= ] Given that TWAMP does not support TLV, I assume that the discussions are = mainly about draft*-stamp-srpm.

 = ;

[Mach= ] In the case of direct packet loss measurement, draft-gandhi-ippm-stamp-sr= pm assumes that marking-based solution (which can address the packet out-or= dering issue) is used, hence the block number is introduced. The block number is used to correlate the counters f= rom the sender and reflector. The current direct loss measurement TLV may j= ust apply to the scenario without packet out-ordering.

 = ;

<RG2> To further= add to this,  as TWAMP Light does not have a TLV, we need to define a stand-alone message f= or direct-mode LM. STAMP is just the same message but fixed length, so this= way both can interoperate and also we can leverage the message for both of= these protocols.

 

For STAMP direct-mode LM TLV approach, some t= echnical details are in the draft as well:

 

   The STAMP message with a TLV for "direct measurem= ent" can be used for

   combined Delay + Loss measurement [I-D.ietf-ippm-stamp-op= tion-tlv].

   However, in order to use only for loss measurement pur= pose, it

   requires the node to support the delay measurement mes= sages and

   support timestamp for these messages (which may also r= equire clock

   synchronization for one-way delay).  Furthermore,= for hardware-based counter collection=

   for direct-mode loss measurement, the optional TLV bas= ed processing

   adds unnecessary overhead (as counters are not at well= -known

   locations).<= /o:p>

 

 

 

[Mach= ] In addition, whether to keep it as current design or to define a new TLV = for direct loss measurement can be debatable.  

 

 

 = ;

How the proposed method of direct packet loss is rel= ated to TWAMP light and STAMP?

There's no apparent technical relationship between *= -twamp-srpm and TWAMP Light, or *-stamp-srpm drafts and STAMP. Drafts do no= t extend or re-use the basic mechanisms defined for  TWAMP-Test and/or= STAMP in their respective specifications. Rather than that, drafts introduce a new query-response mode and new forma= ts of test packets that are decisively different from the formats defined i= n respective specifications. As a result, the new protocols are required to= use different from used by TWAMP Light tr STAMP test session UDP port numbers on the responder. And that is= another clear indication that the proposed mechanism represents a new prot= ocol, neither extends TWAMP Light and/or STAMP nor updates their specificat= ions.

 

<RG> As mentione= d in previous replies, other than timestamp vs. counter and it=92s format, = the messages and processing of them are the same for delay and direct-mode = loss measurement.

  • Is there any advantage in introducing a dedicated packet format for the dir= ect packet loss in STAMP comparing to using the Direct Measurement TLV exte= nsion?

Though it appears the using a dedicated packet forma= t instead of TLV is more efficient, but the dedicated for the direct loss m= easurement format is likely to precede one or even two TLVs, Node Address T= LV and Path TLV, defined in draft-gandhi-ippm-stamp-srpm. As a result, processing of the new packet with TLVs is unlikely to be more= efficient and reduce the processing delay, than if using the Direct Measur= ement TLV as defined in draft-ietf-ippm-stamp-option-tlv.

 

<RG> As mentione= d in previous replies, this is explained in Section 1 of the draft-gandhi-spring-stamp-srpm. = For link loss measurement (direct-mode), there is no TLV required for examp= le. For direct-mode loss measurement in SR networks, it would typically be forward direction packet loss= measurement (and not bidirectional).

 

 

  • Using the Sender Control Code may require the use of= the additional TLV that carries the return path information, Path TLV. If = the ability to control the return path is required that can be achieved by = augmenting the STAMP YANG data model (draft-ietf-ippm-stamp-yang) rather than including the Path TLV in each te= st packet. Hence, there seem no technical requirements to introduce the Sen= der Control Code field in the Base STAMP format defined in RFC 8762.

     

    <RG> Per session= basis between different sender nodes and this reflector node, some senders= will request the replies in-band (e.g. for two-way mode). Sessions are pro= visioned on the Sender nodes and reflector simply reflects based on the received test-packet (e.g. for a bidirectiona= l SR path). This is also similar to as described Section 3.1 in RFC 6374, t= op of page 22. There is no need to create a such state for each session on = the reflector node and create a scale limitation. Recall that we are trying to avoid the scale limitation = by eliminating the Control protocol signaling.

     

    <ZTR> I find some value to include the path TL= V in wire. As Rakesh mentioned, this can reduce the reflector configuration= . But I am not convinced to introduce the sender control code field. It see= ms to me, the presence of path TLV indicates the bidirectional congruent path. Vise versa.

     = ;

    [Mach= ] Regarding how to specify the return path, the draft defines two ways to a= chieve that, one is to use control code to direct whether the reflected Tes= t should be along the reverse path of a bidirectional path, this applies to both TWAMP (no TLV mechanisms) and S= TAMP. At the same time, in the case of STAMP, it also defines the return pa= th TLV to explicitly specify the return path, which bring more options to s= pecify the return path. Therefore, I see benefit of the two ways.

     

    <RG2> To further= add to this, the IPPM draft simply defines protocol extensions. The use-ca= ses are there in the corresponding spring drafts. For example, for links, no return Path TLV is used, etc. In other = words, the use-cases are different for the two, and there is no TLV in TWAM= P anyways.

     

    Thanks,

    Rakesh

     

     = ;

     = ;

    Best = regards,

    Mach<= /span>

     = ;

    What is the relationship between the *-srpm drafts a= nd BFD?

    Some text in the *-srpm drafts suggest that the prop= osed method can be used to monitor for the loss of a path continuity. = That may be viewed as an alternative to the BFD protocol method for the det= ection of a network failure. If the discussion of Loopback mode and monitoring of liveness remain in the drafts, it seems= logical that the BFD WG and BFD WG's Chairs be made aware of the proposals= . I didn't take the liberty of adding BFD WG or its Chairs. I believe that = decision to be made by the Chairs of IPPM And SPRING WGs.

     

    <RG> As mentione= d in previous replies, STAMP/TWAMP test messages are also used today for synthetic packet loss measurement which can be also used to detect/m= onitor connection loss (performance metric). The draft simply highlights th= is obvious metric. This is also very similar to what is described in ITU Y.= 1731, Section 7.1.

     

    Thanks,

    Rakesh

     

    Regards,

     

     

    On Sun, Nov 15, 2020 at 10:10 PM Greg Mirsky <gregimirsky@gmail.c= om> wrote:

    Hi Rakesh,

    thank you for your prompt response, much apprec= iated. I'll carefully read your responses. Looking forward to the continued= discussion.

     

    Regards,

    Greg

     

    On Sun, Nov 15, 2020 at 10:07 PM Rakesh Gandhi (rgan= dhi) <rgandhi@cis= co.com> wrote:

    Hi Greg,

     

    Thank you for your review comments. As mentioned in the IPPM sessi= on today, the email response was sent as attachments, see archive blow:

    https://mailarchive.ietf.org/arch/msg/i= ppm/J503n-B2yOxF0urcHtGQKnqCRDE/

     

    I am attaching them in word documents for the convenience. We can = address your comments below in the next revision of the document.

     

    Thanks,

    Rakesh

     

     

    From: Greg Mirsky <gregimirsky@gmail.c= om>
    Date: Friday, November 13, 2020 at 10:09 AM
    To: Rakesh Gandhi (rgandhi) <rgandhi@cisco.com>
    Cc: Tommy Pauly <tpauly=3D40apple.com@dmarc.ietf.org>, IPPM Chairs &l= t;ippm-chairs@iet= f.org>, spring-chairs@i= etf.org <spring-chairs@ietf.org>, IETF IPPM WG (ippm@ietf.org) <ippm@ietf.org>
    Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm = and draft-gandhi-ippm-stamp-srpm

    Hi Rakesh,

    thank you for your response to my review. Please find my follow-up= notes in-lined below under the GIM>> tag.

    I hope you've found more detailed comments in the attachments (re-= attached for your convenience). I'm looking forward to reading your respons= es to the detailed comments of all four drafts.

     

    Regards,

    Greg

     

    On Tue, Nov 10, 2020 at 8:11 AM Rakesh Gandhi (rgandhi) <rgandhi@cisco.com> = wrote:

    Thank you Greg for taking time for t= horoughly reviewing the documents and providing the comments.  Attache= d please find the email replies to your review sent earlier.  The replies are copied inline below for convenience, t= agged with <RG00>.

     

     

    From: ippm <ippm-bounces@ietf.org&= gt;
    Date: Monday, November 9, 2020 at 11:48 AM
    To: Tommy Pauly <tpauly=3D40apple.com@dmarc.ietf.org>
    Cc: IPPM Chairs <ippm-chairs@ietf.org>, spring-chairs@i= etf.org <spring-chairs@ietf.org>, IETF IPPM WG (ippm@ietf.org) <ippm@ietf.org>
    Subject: Re: [ippm] Call for adoption: draft-gandhi-ippm-twamp-srpm = and draft-gandhi-ippm-stamp-srpm

    Dear WG Chairs, Authors, and IPPM WG community,

    I've reviewed these drafts and have some comments to share. Below,= please find my thoughts on whether these drafts can be adopted. More speci= fic comments on each pair of drafts (TWAMP-related and STAMP-related draft and its accompanying draft tar= getted to the SPRING WG) are in the attached documents.

     

    Usually, the bar for the adoption of a document can be evaluat= ed by answers to these three questions:

    =B7  Is the document(s) reasonably well-written

    I've got surprised that the drafts don't use the terminology f= rom RFCs 4656/5357 and RFC 8762, and introduce their own terminology for Session-Sender and Session-Reflector. Also, many terms= , e.g., Links, "congruent paths", are used in the documents witho= ut proper definitions. Other than that both drafts are readable and reasona= bly well-written.

     

    <RG00> We can change Sender to= Session-Sender and Reflector to Session-Reflector if it helps. 

    GIM>> I believe that the consistency in terminology between = the core RFC and what is intended as its extension is not only helpful to a= reader but, to the best of my understanding, is required for IETF specifications.

    <RG00> There are many existing= RFCs that use term Link (e.g. RFC 5613, 5340, 8330, etc.) and term Congrue= nt Path (e.g. RFC 5921, 6669) without defining them. I suspect it is because these are well-known terms. Having said that= , we can add a reference for them if it helps.

    GIM>> Thank you for listing these RFCs. I think I need to cl= arify my questions. While a reference to any of RFCs you've mentioned, I do= n't think that will address my concern. In reviewed documents, "Link" is capitalized while referenced RFCs = used the lower case form for the term "link". Can these be used i= nterchangeably? Do they refer to the same network object?

    Now I'll try to illustrate my concern with using the term "co= ngruent path" in these drafts (using ASCII-art):

                      &nb= sp;    C---------D

                      &nb= sp;  /                 \<= o:p>

                A----B    &nbs= p;              E-----F

                      &nb= sp;  \                  /=

                      &nb= sp;  G------------H

    Consider an SR tunnel from A to F that traverses the network as A-= B-C-D-E-F. From the definition of "congruent" as "two figure= s or objects are congruent if they have the same shape and size, or if one has the same shape and size as the mirror image of the= other", path A-B-G-H-E-F is congruent to the SR tunnel. But a packet = of an active OAM intended to monitor a flow over the SR tunnel is out-of-ba= nd and will not produce any meaningful measurement. Of course, for the case of the extensions in drafts, direct l= oss measurement can be performed, as information collected from node F. So,= this example, in my opinion, illustrates two of my concerns:

    • using a congruent path for an active OAM protocol may produce information t= hat does not reflect the condition experienced by the monitored flow. It se= ems that the terminology should reflect the fundamental requirement for usi= ng active OAM to maintain the test packets in-band with the monitored flow.
    • there are no technical requirements to justify using in-band active OAM pro= tocol for direct packet loss measurement. As demonstrated in this example, = direct packet loss can be performed using an out-of-band mechanism, e.g., S= NMP queries, Netconf notifications based on YANG data model.

     

    =B7  Does the document solve a real problem?

    No, it appears that  both TWAMP and STAMP drafts  d= efine a new performance measurement protocol for the purpose of combining OWAMP/= TWAMP and STAMP functionality in the respective drafts, and adding the abil= ity to collect counters of "in-profile" packets. I couldn't find = sufficient technical arguments for using a PM protocol instead of, for example, extending the existing OAM mechanisms= like ICMP multi-part message extension per RFC 4884.

     

    <RG00> There is a requirement = to measure performance delay as well as synthetic and direct-mode packet lo= ss in segment-routing networks. OWAMP and TWAMP protocols are widely deployed for performance delay and synthetic packet l= oss measurement today. I am not sure extending ICMP for LM is a good option= here.

    GIM>> I agree with the requirements you've listed (thou= gh the SPRING WG OAM requirements document has been abandoned and expired 3+ y= ears ago). I believe that there's no sufficient technical reason to us= e OWAMP/TWAMP/STAMP for exclusive direct packet loss measurement. 

     

    =B7  Is the proposed solution technically viable?

    There are too many unaddressed aspects, particularly the risk = introduced by the protocols on network security, to comprehensively evaluate the proposed solutions.

     

    <RG00> About your comment on z= ero checksum, this is described in Security section in RFC 6936. We will ad= d reference to this RFC in our Security Section as well. This is only specific to the UDP port locally provisioned in the = domain by the operator for STAMP or TWAMP Light. Other than this, I did not= find any other security related issue in your review.

    GIM>> I don't think that a mere reference sufficiently expla= ins why the use of zero UDP checksum in IPv6 header is not decremental, doe= s not create a security risk for the protocol.

     

    Thanks,

    Rakesh

     

     

    Regards,

    Greg

     

     

     

     

    On Fri, Oct 30, 2020 at 11:35 AM Tommy Pauly <tpauly=3D40apple.com@dmarc.= ietf.org> wrote:

    Hello IPPM,

     

    For the past few meetings, we=92ve had updates on the work in the = SPRING WG that was using STAMP and TWAMP. Since those documents ended up ma= king extensions to the base protocols, the chairs of SPRING and IPPM decided that it would be best to split the d= ocuments and track the IPPM extension work in the IPPM WG.

     

    As such, we are starting a Working Group call for adoption for&nbs= p;draft-gandhi-ippm-twamp-srpm and draft-gandhi-ippm-stamp-srpm.=

     

    Please provide your feedback on these documents, and state whether= or not you believe the IPPM WG should adopt this work by replying to this = email. Please provide your feedback by the start of the IETF 109 meeting week, on Monday, November 16.<= o:p>

     

    Best,

    Tommy & Ian

    _______________________________________________
    ippm mailing list
    ippm@ietf.org
    ht= tps://www.ietf.org/mailman/listinfo/ippm

--_000_DM6PR11MB31159A70B271EDD1D7F9201FBFE00DM6PR11MB3115namp_--