[mpls] Re: Gunter Van de Velde's Discuss on draft-ietf-mpls-spring-inter-domain-oam-17: (with DISCUSS and COMMENT)
"Gunter van de Velde (Nokia)" <gunter.van_de_velde@nokia.com> Tue, 25 June 2024 07:29 UTC
Return-Path: <gunter.van_de_velde@nokia.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FB97C14F616; Tue, 25 Jun 2024 00:29:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.254
X-Spam-Level:
X-Spam-Status: No, score=-2.254 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.148, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nokia.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TZHutmzsFsfG; Tue, 25 Jun 2024 00:29:04 -0700 (PDT)
Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2068.outbound.protection.outlook.com [40.107.22.68]) (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 A8261C14F682; Tue, 25 Jun 2024 00:29:03 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=V0Iv7zotT0Tzxbg2k2LBPupSLWguyN7u17AoWQ725i36tKMhi0DcqlI0pceHLBNBkglGf+nLBdfKoTg7l6T9dIcbCOS7/8EEN6s3/R0gsXTba6KC9Y0flhtT2LUiplcOw3CvOuN8bm4c1Os2behVSAdH3+1i4N6fEPqLv0Po236ReYH5gjU1vtVMKvyXKYPTDiSquISyzmUOqlzz2Dxzjw0vCMXJ+zRmU9ZRhCHNWBXYjzL4et/nqUuRHcSyPSQvQ0dzPggZUPQ7Z4jaJnJ02+P0quBGTN4HkaBU3TrY9Sj855eFWRbfbd7ej/yOtyATdhlB5/OvlyxCyZIIro5s8A==
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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=+TZ0CIeePSumIla/dIQsGDz0oSzSh//leZpwSBm6lpY=; b=P6e3Z+THDWXdlygatl1/lB07dpEc6Xxvec0DwH0kdesbcn7Ru417RbTNhbAfCsf73jS8EkmWh93WcC2lGyaJAjz3d4GanLnFm22cA3VwYP6xEmPgcyCapUgViTHnEw0yedWQw2ukifPuxmL6o8qcb9ENTyooE2azNH4SYTBu6Lndy5tU2mtAdfVz+uUTBcibZPk+KOKNXxN70y8sDF/G+FNRbAdZ07X/B9nS0TBbd8/tHZ5nM2nntax/Bo0O0axP9EV1a5g5nFZA18V9n4nGJorSKsGDuIDnMqQo677HJX2+6lwAs/SWswL0kdE9iVtVmmDNhA1Trf4yJIj1kJpIvQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+TZ0CIeePSumIla/dIQsGDz0oSzSh//leZpwSBm6lpY=; b=bM+ogQf4rZmbFu0CIJ/k9LlaPCHnRadnqt9KFddDsksf1oLo4uo5DCPMEE1kbC/+F7WTf6NGhb/KQIJtRAqUjswCrXy5u1++to3jCYWgtkzMwpBazA1gBCT7AXon9wJLg2yBJCwCgKBgnH4d99lZgMaMJ5wQ38wk9yPQExhYdVsxOajxYIWD2r49RutjNKiuB+F9J799PSkTbLxwjC4sIiX3paKCrWACaOub6rzbz0GgUEGW1cRBR4RoSy4OJ4Xyq8/zVG0k1pH9BazFmDfwpSyq+cSCblma4Bpen0q23oJli06C1C+vV9oLzn+/StYro7Acf1BYsj8EGD8DXCuTlg==
Received: from AS1PR07MB8589.eurprd07.prod.outlook.com (2603:10a6:20b:470::16) by DB8PR07MB6457.eurprd07.prod.outlook.com (2603:10a6:10:132::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7719.20; Tue, 25 Jun 2024 07:28:59 +0000
Received: from AS1PR07MB8589.eurprd07.prod.outlook.com ([fe80::5ca6:f902:8e31:6f3e]) by AS1PR07MB8589.eurprd07.prod.outlook.com ([fe80::5ca6:f902:8e31:6f3e%3]) with mapi id 15.20.7698.025; Tue, 25 Jun 2024 07:28:59 +0000
From: "Gunter van de Velde (Nokia)" <gunter.van_de_velde@nokia.com>
To: Shraddha Hegde <shraddha@juniper.net>, The IESG <iesg@ietf.org>
Thread-Topic: Gunter Van de Velde's Discuss on draft-ietf-mpls-spring-inter-domain-oam-17: (with DISCUSS and COMMENT)
Thread-Index: AQHaxgOZ9Qs9Ac8enkuHs64/feMRbrHYEfSg
Date: Tue, 25 Jun 2024 07:28:59 +0000
Message-ID: <AS1PR07MB85894F64DA43AD002BD653A5E0D52@AS1PR07MB8589.eurprd07.prod.outlook.com>
References: <171769287435.48097.15762644519277768046@ietfa.amsl.com> <CO1PR05MB83146CB77C1A3D54BA405E57D5D42@CO1PR05MB8314.namprd05.prod.outlook.com>
In-Reply-To: <CO1PR05MB83146CB77C1A3D54BA405E57D5D42@CO1PR05MB8314.namprd05.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=827f5cd0-a278-497a-999b-78cd53a6f3f9;MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=0;MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true;MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard;MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755;MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2024-06-13T10:01:16Z;MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4;
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nokia.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: AS1PR07MB8589:EE_|DB8PR07MB6457:EE_
x-ms-office365-filtering-correlation-id: bd8dffc9-c40f-4d0e-d2e7-08dc94e87ac0
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230037|376011|366013|1800799021|38070700015;
x-microsoft-antispam-message-info: CT0OS0HbGoFsup/A76Yl1ZNF1STU1NCPi24szZ9cjqkA09AO4tScoOpxp97c4XFco9XOLQ+Jg8vDhgjyCK+QBMLpzeSmb7pioYrzEFikF5/elbP1t+BNG+wUxX8yom9i9dzfsqxrmpaWXEcfcsN2N14dxA8octkf2fTLCiGOPbttB+K4j1HMXKbo3M3DI9CYEgvDUEWjkgU5y5Ib2Q3JRPzXqO5h6X4A+gaLqVaPy6xHQQ8msvAYUVlCXOX8E1iSPcOT5FwerK1OKs4SYIrE+OQ8sS67eQc45BQ1GfqwXJf54fn/IG1ve5Y+01vRcmqwxD1RUKNFup0P0FLyY3EkrWLGkXTKvxyRidlX8O+hn9govyYBvcitPa5Rgj7Cjw8/AyOf0Oj+Lxao8MXKB1lwks7SvrCY6089bSyo+OyJiwBhNceVpYDH54BPuPoB59wPULLDcbNUXbPad0f8Sk+gvuc4BrcxlzrBXKO4NJxFzbaDn/AVnHY+GCv1WlZolHEYFE+DW5B64JAba9OY9CHKVHgF9n0ZTAcvX06AacoCdZ/0FD32PyRe+4ZePthY26DqDmFvzhG/Y08LrkGZOp0c9bKy+9c9K7dVAkyVU8rgkrqADkXHWsrJVjRjECTpnf+4cr2fyuknUOtUdopZ3ltHfjX0NJhCdEWjwTG5amFpnSF4U2BQ1lTcW5DV+1hRP4R3sd8Ja1bGrHlG0vIniopyzmtFYZ0JUrFYdWSWmGKiTusO2LEXFbfT62Cv5wD9vXZtmXksg42T377Lr+PynKL9omJpC+ysYF6D55ppQ3u7OckdtmuYtc3QOT7KcrUPUBySIwvEpbymkv9NGdqcuYTe5T87fY6IT7Ng5vuERyektTP6clwY1obDKZCnNJUZInOTSjbn9YJOHm4hOgjlB5xNpoZW9q6Yf+t6WTBpV8bFkk5dgKOupFRLS3b+T2zDsAQvT5NIi4jBbtFriQWac6lqlM+N9T+hHGPunCiqKC+uzfzYOOnrWcgyRJfdn9Am9klTX+GCErDOo04txq5qIsdFrCp4Sw93l5Gm7rzy8/xOna/2mjn+jR4eRc3r1NF/qQ84o1YzcRWzwSvz9pElXAmUdIhsKsIHPZPbjWAYb4yJ4sGzcF/BL0ly6nvp0hreGiEA54/BTacl7KVkw8HGHOB+j/Hb4cSzDy532RzUlJZ7BPsyuyIJiXQvgMFHYOSnN21Y+rOIRI3DXb43F2KGP1tXaFJ3EnNnjDfkx7gfKZG8DnbXXHHqIksq/xJ+oy8C9BGuXntxb2S0NSGgnFZF7GTHyAlU30xwFyjE3oigu4ybBvVoQvwSFob3WwNNe2aRDUaeKtC2Q3EjcajZ49ZXdmOjbBaxzlQP3rYFOdKVu7KywYA=
x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS1PR07MB8589.eurprd07.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230037)(376011)(366013)(1800799021)(38070700015);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: vyjB+5yJGcTGEj7C+siuyfYgX/yh2kUSTCJBcg3x/3bwXFNbD58/JdEpREHQvdLnMT8m8IBe65/F+C80tPkrwB1kUKIOTFnZC+9nC2H/bS0ZOTfGLAbI9nBAdQKfGwgajGCStMETgtsXee4KISqWd2h5Gl9RHxlSnpoFZJoGDov15DKJyrMjrobHyM2S2xvbjiQHCE5cbQH8GDJ3WO8NQw7VNkAMXnUJuqiCzp/TR7uJiFeReEBko4ZJ4tf/NYIl5Tw9decdgcz77Z696JZ5q+ltLEKWnAyAQdIL4I7b6A7TcOw9TnWKPHsEjZBpdKFABgw1Cj7c7XHgEtOM83jki467boJPMVaZZIXh37BqIvauRz/X8U9/E/YN++X3auHaJ+8u28TBJS5Gq6F+FzMepa3iFcjnekWPCsuE4gIisLVEZBmbWn7AgK80eshD64RkhtaMiOi9HDQMdDIZ/I2Mwvhq2u3t0NoVGIL0qnAwrKO/mlKd03mnbl6hKWecxv+xk5v//RCMwkhZf1PzloSRvfEwBUGJ2su4cHxUnndKKDySQAxJ3e8kCN6lONxBcMygfv4QB1jbzGbXdsSdmXx8d5jOE4K8bIqWfoiKxBOzO7Rpjfv5e7qErP7bL3rz813NRVPj3mtwmudGKRsKBvEWa1C49oOeOCZlgvpWQ3btrxJrs2V7D/asEQzzBXNkmGjdmMJfZSCLYYHQDxxgEyp1kpNGT0yNB0OFLLIybV+BQ/VMIqQxt35gdkhHHqDbbQIIypxzgiMzUP6+w7OUKevErChOYtU/awn+cKqBzRy1PSRWpr1XAd3+MYwsB4XjpcmHAPk6DvSVlNNQJh6jblgtPkYpfnuKoZ2oyNfNU5AzN/ILJAleo/w3oeiYAx86J7UTE1jLcT0jH2BJ0Cu4JgzwvfofIIwV7y/huZWzvGCn4lvGZ1ZfTJb3dQEzW1Bt7hSq38XA5gjGrFhNf2nfc6yvb+/9JxOE/atZAL8bTqMSMT8pxFMUu3b+6M2DgHSw+HpzrVHzHJmGhIzfqLnbFUYlcB8zrJ/796CEaNdoqVibCfS4OIDB9TSLGcl7IfXcDBE6iBWtRKoC2qBPvqj9URRLq+tFFvMc+FBQsA3ErSDk9R8NWW4dVf6/svUp1ew0GOvCELmlyQKjlqpvKymEa1nJo5suFIY5G6xCejD/50TMRU6s4x/TdlIJRUntqr7cocsUE3SSsTBi3KmKC1sdkkmS/zLMcqTeGWUbAThV7l8QdIPzIBuq1wPO8eO2wgS8FlOF6rvpcua/zDivonAWSoVoWcH+BheFAH+yKzcq2F36ksh9XSE12jbIyIC+MyXne9FY0IRvDxxw3iGlD6bFcKui9xVPlAsosKCzLNDBudNP71dmukW7Aqicwpp6p+/mJszmOLeJU7FwQMre9KIJgfTPROQe37VepjZx3LUVKc/6sciIwqU0h78qgr0eTvtMhnE7tZVMbWKkxziRskFhbo2XZu/hStyDn73MsLZ+/fUnmVTHb8+dqleTCqqT7L5JsNEmWMLZwu6VvMjcifrwdO7b3QThLool5eHX2ihAdDK3noZyBPvaziA+30aOk+qdZaUg8UDCAOHIrJnM4DhoAbJCIRS6fzThtGhSST5enS9VJ6WgmkTCs/mWqfPjapwXQnltojvj5Zsf4auJ0aaRFpDmmA==
Content-Type: text/plain; charset="utf-7"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AS1PR07MB8589.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: bd8dffc9-c40f-4d0e-d2e7-08dc94e87ac0
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jun 2024 07:28:59.2283 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: im0lctWc3RbGGAgPYQQwSzzKCZOZ01rxoPdr8RP9ync7z41JP7wkJvcC7F+pK17of4Dt0MVP80DSFuYKRrOdHAsRZ3Z969+TAvXlqySiFX4=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8PR07MB6457
Message-ID-Hash: YMLWCTVEEAUHLUH72UEOX6A2QLGVUR3S
X-Message-ID-Hash: YMLWCTVEEAUHLUH72UEOX6A2QLGVUR3S
X-MailFrom: gunter.van_de_velde@nokia.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-mpls.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: "draft-ietf-mpls-spring-inter-domain-oam@ietf.org" <draft-ietf-mpls-spring-inter-domain-oam@ietf.org>, "mpls-chairs@ietf.org" <mpls-chairs@ietf.org>, "mpls@ietf.org" <mpls@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [mpls] Re: Gunter Van de Velde's Discuss on draft-ietf-mpls-spring-inter-domain-oam-17: (with DISCUSS and COMMENT)
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/gBOX5OCjfkMe4b-j9MM--O1XkQk>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Owner: <mailto:mpls-owner@ietf.org>
List-Post: <mailto:mpls@ietf.org>
List-Subscribe: <mailto:mpls-join@ietf.org>
List-Unsubscribe: <mailto:mpls-leave@ietf.org>
Hi Shraddha, Thanks for looking into the discuss comments. Your answers and resolution address my discuss comments on the document. I will clear my discuss position. In addition, many thanks for looking through the list of detailed non-blocking comments. Please see inline: GV> -----Original Message----- From: Shraddha Hegde Sent: Monday, June 24, 2024 8:56 AM To: Gunter van de Velde (Nokia) ; The IESG Cc: draft-ietf-mpls-spring-inter-domain-oam@ietf.org; mpls-chairs@ietf.org; mpls@ietf.org; adrian@olddog.co.uk Subject: RE: Gunter Van de Velde's Discuss on draft-ietf-mpls-spring-inter-domain-oam-17: (with DISCUSS and COMMENT) CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. Hi Gunter, Thanks for the review and comments. Pls see inline for response. Ver -18 will address your comments Juniper Business Use Only -----Original Message----- From: Gunter Van de Velde via Datatracker <noreply@ietf.org> Sent: Thursday, June 6, 2024 10:25 PM To: The IESG <iesg@ietf.org> Cc: draft-ietf-mpls-spring-inter-domain-oam@ietf.org; mpls-chairs@ietf.org; mpls@ietf.org; adrian@olddog.co.uk; adrian@olddog.co.uk Subject: Gunter Van de Velde's Discuss on draft-ietf-mpls-spring-inter-domain-oam-17: (with DISCUSS and COMMENT) [External Email. Be cautious of content] Gunter Van de Velde has entered the following ballot position for draft-ietf-mpls-spring-inter-domain-oam-17: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!NEt6yMaO-gk!DDRHlr3LozgYc2SPH9ia7xvN_6lrrMs4BKzfdXkHRQCstSUMVNiYMjyJbIngQPDBPvxp9W1-wH_zxxhR$ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-mpls-spring-inter-domain-oam/__;!!NEt6yMaO-gk!DDRHlr3LozgYc2SPH9ia7xvN_6lrrMs4BKzfdXkHRQCstSUMVNiYMjyJbIngQPDBPvxp9W1-wBebGCnJ$ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- # Gunter Van de Velde, RTG AD, comments for draft-ietf-mpls-spring-inter-domain-oam-17 Please find https://urldefense.com/v3/__https://www.ietf.org/blog/handling-iesg-ballot-positions/__;!!NEt6yMaO-gk!DDRHlr3LozgYc2SPH9ia7xvN_6lrrMs4BKzfdXkHRQCstSUMVNiYMjyJbIngQPDBPvxp9W1-wJrxI8Fe$ documenting the handling of ballots. Many thanks for the RTG-DIR reviews from Stig Venaas and Michael Richardson and for the shepherd writeup by Adrian Farrel. Many thanks for this write-up. It is well written. I did find when reading the document that some constructs were presented more complex as necessary. Please find in this review three blocking DISCUSS observations, followed by non-blocking high-level observations. Additionally, there is a set of detailed comments categorized as [minor] and [major] observations, which I hope you will find useful for improving the document. #DISCUSS items #============= ##DISCUSS1 Why is there the A-flag? would the existence of an SR Algorithm in the TypeC/D subTLVs not be sufficient? It implicit suggests that there is an algorithm? <SH> The TLV definitions mimic the definitions in RFC 9256 section 4 and draft-ietf-idr-bgp-sr-segtypes-ext. Since Algorithm value 0 is also a valid algorithm, A flag was defined in draft-ietf-idr-bgp-sr-segtypes-ext GV> ack ##DISCUSS2 What should be done when, for Type-C and D, the encoded IP address does not match the encoded SID for the node or the correct algorithm for that node? Is there a validation process or error messaging in place? <SH> " When the SID field is present, it MUST be used for constructing the Reply Path." This above statement is there in the draft This means if SID is present it overrides IPv4 address. GV> ack. Would it make sense to suggest some form of notification that something funky/error'isch is going on? ##DISCUSS3 section 5.3 documents that "An MPLS packet is constructed with an echo reply where the top label MUST be constructed from the first segment from the Reply Path TLV while the remaining labels MUST follow the order from the Reply Path TLV". This text seems to allow that random segments can be inserted as long as the original ordering is kept. Is that intentional? <SH> No. Insertion of other segments are not allowed if yes, such prescribed behavior should be explicitly documented. If not allowed, then that should be included in formal procedure rules. <SH> below modified text " The top label MUST be constructed from the first segment of the Reply Path TLV. The remaining labels MUST be constructed by following the order of the segments from the Reply Path TLV. The MPLS header of the Echo Reply MUST be constructed from the segments in Reply Path TLV and MUST NOT add any other label." GV> thanks. This works for me. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- #GENERIC COMMENTS #================ ##There is some usage of RFC2119 normative language that may not be needed in some sections. Some have been flagged in the detail review ##The SID is encoded with only a label in the Type-A/C/D. SR also allows a SID to be an index instead of a label. Is there a reason why index was excluded? <SH> Index is not adding any additional value but SID as label has useful usecases. If SRGB is Not known then label cannot be derived with index. ##with the explanation of the Type-A/C/D subTLVs there was some duplicate text for explaining the fields. I would suggest to revise and the fields and the formal procedures only once per Type. Now some fields are described twice in the same section <SH>OK ##Section 6 details an example. Examples are not formal normative procedures. It seems more opportune to place the example in Appendix to reduce the formal part of the draft and to clearly identify it is informational. It makes the main part of the formal procedure of the RFC less long <SH> ok #DETAILED COMMENTS #================= ##classified as [minor] and [major] 26 domains. This document describes mechanisms to facilitate LSP ping 27 and traceroute in inter-AS and inter-domain SR-MPLS networks 28 efficiently with a simple Operations, Administration and Maintenance 29 (OAM) protocol extension which uses data plane forwarding alone for 30 forwarding echo replies on transit nodes. [minor] I got confused wit the wording of 'alone' and am not convinced it is used correctly. "This document outlines mechanisms to enable efficient LSP ping and traceroute in inter-AS and inter-domain SR-MPLS networks through a straightforward extension to the Operations, Administration, and Maintenance (OAM) protocol, relying solely on data plane forwarding for handling echo replies on transit nodes." <SH> ok 115 [RFC8660] specifies SR with an MPLS data plane. [RFC8402] describes 116 BGP peering SIDs, and [RFC9087] describes Egress Peer Engineering, [minor] s/BGP peering SIDs/BGP Peering Segments/ s/Egress Peer Engineering/Centralized BGP Egress Peer Engineering/ <SH> OK 117 which will help in steering packets from one AS to another. Using 118 the above SR capabilities, paths that span across multiple ASes can 119 be created. [minor] slight rewrite from readability perspective: "By utilizing these SR capabilities, it is possible to create paths that span multiple ASes." <SH> ok 192 SR label stack. The return path can either be derived by a smart 193 application or controller that has a full topology view. This 194 document also proposes mechanisms to derive the return path 195 dynamically during traceroute procedures. [major] I am not sure what is a 'smart' application or controller. <SH> centralized entity which is typically out of the box. Is a full topology view really required? a topology view of the network section being investigated seems sufficient, not? <SH>You are right, End-to-end view of a section of the topology will also do. I will update text. 197 The current document is focused on the inter-domain use case. 198 However, the protocol extensions described in this document may be 199 applied to indicate the return path for other use cases as well, 200 which are out-of-scope for this document and therefore not further 201 described in this document. SRv6 data plane is not in the scope of 202 this document. [minor] Why is the text seems complicated constructed. What about the following: "This document focuses on the inter-domain use case. The protocol extensions described may also indicate the return path for other use cases, which are outside the scope of this document and are not further detailed here. The SRv6 data plane is also not covered in this document." <SH> ok 204 1.1. Definition of Domain 206 The term domain used in this document implies an IGP domain where 207 every node is visible to every other node for shortest path 208 computation. The domain implies an IGP area or level. An AS 209 consists of one or more IGP domains. The procedures described in 210 this document apply to paths built across multiple domains which 211 include inter-area as well as inter-AS paths. The procedures and 212 deployment scenarios described in this document apply to inter-AS 213 paths where the participating ASes belong to closely coordinating 214 administrations or to single ownership. This document applies to SR- 215 MPLS networks where all nodes in each of the domains are SR capable. 216 It also applies to SR-MPLS networks where SR acts as an overlay 217 having SR-incapable underlay nodes. In such networks, the traceroute 218 procedure is executed only on the overlay SR nodes. [minor] I found this section hard to parse. The following text proposal processes slightly better: "In this document, the term "domain" refers to an IGP domain where every node is visible to every other node for the purpose of shortest path computation, implying an IGP area or level. An Autonomous System (AS) comprises one or more IGP domains. The procedures described herein are applicable to paths constructed across multiple domains, including both inter-area and inter-AS paths. These procedures and deployment scenarios are relevant for inter-AS paths where the participating ASes are under closely coordinating administrations or single ownership. This document pertains to SR-MPLS networks where all nodes within each domain are SR-capable. It also applies to SR-MPLS networks where SR functions as an overlay with SR-incapable underlay nodes. In such networks, the traceroute procedure is executed only on the overlay SR nodes. " <SH> ok 253 Reply Path (RP) TLV is defined in [RFC7110]. SR networks statically 254 assign the labels to nodes and a PMS/head-end may know the entire 255 database. The reverse path can be built from the PMS/head-end by [major] What for database? The LSDB? a database with the all the nodes and assigned SIDs? something else? <SH> Fixed as below " may know the entire Link State Database (LSDB) along with assigned SIDs" GV> Thanks 265 The type of segment that the head-end chooses to send in the Reply 266 Path TLV is governed by local policy. Implementations MAY provide 267 Command Line Interface (CLI) input parameters in the form of Labels/ 268 IPv4 addresses/IPv6 addresses or a combination of these which get 269 encoded in the Reply Path TLV. Implementations MAY also provide 270 mechanisms to acquire the database of remote domains and compute the 271 return path based on the acquired database. For traceroute purposes, 272 the return path will have to consider the reply being sent from every 273 node along the path. The return path changes when the traceroute [major] I do not understand why these are uppercase MAY? no formal protocol procedures are provided in this section? consider lower case as it distracts from formal protocol procedures <SH> will fix it [major] The term 'database' is unclear. What for database is exactly intended? A node may have many databases <SH> It means Link state Database. Will fix in all places GV> Thanks 279 Some networks may consist of pure IPv4 domains and pure IPv6 domains. 280 Handling end-to-end MPLS OAM for such networks is out of the scope of 281 this document. It is recommended to use dual-stack in such cases and 282 use end-to-end IPv6 addresses for MPLS ping and traceroute 283 procedures. [minor] Clarification: I suspect that it is intended to indicate that it is pure ipv4-only or ipv6-only networks? <SH> yes. Will correct it 295 The below types of Segment sub-TLVs apply to the Reply Path TLV. The 296 code points for the sub-TLVs are taken from the IANA registry common 297 to TLVs 1, 16, and 21. This document defines the Segment sub-TLVs 298 usage and processing when it appears in TLV 21. If these sub-TLVs 299 appear in TLVs 1 or 16, appropriate error codes MUST be returned as 300 defined in [RFC8029]. [major] While the text here is is not wrong, it is confusing type-A/C/D and then three code-point TLVs... The text should be more explit that code points punt towards: 1 Target FEC Stack 16 Reverse-path Target FEC Stack 21 Reply Path and be more explicit that the new defined sub-TLVs are only to be used with TLV21 (Reply Path TLV). <SH> Fixed some text. Pls check if it looks better now. GV> Thanks 327 Type: TBD1(to be assigned by IANA from the registry "Sub-TLVs for TLV 328 Types 1, 16, and 21"). [minor] Should it not specify a field length of 2 octets? 330 Length: 2 octets. Carries value 8. The length excludes the length 331 of the Type and Length Fields. [minor] The length "value" exclude.... 335 RESERVED: 3 octets of reserved bits. MUST be set to zero when 336 sending; MUST be ignored on receipt. [minor] I believe that the declaration for reserved is the correct one, but want to double check. If there is any potential that in future these bits may be used, then instead Future Use may be better choice. <SH> AFAIK, it’s a standard practice to say MUST be ignored on receipt. New RFC which updates Reserved field will also update this RFC IMO. 342 S: 1 bit Reserved. [minor] few lines above the RESERVED 3 octets were described directly, however the formal procedure for handling S bit is explained later in the text, which is inconsistent <SH> I tried to fix some but didn't look at all. I would leave it to the RFC editors. 390 Length: 2 octets. Carries value 8 without SID included or 12 with 391 SID included. [minor] The text should be more prescriptive. "Caries value 8 when no optional SID is included or value 12 when optional SID is included." <SH> ok 395 SR Algorithm: 1 octet specifying SR Algorithm as described in section 396 3.1.1 in [RFC8402], when A-Flag as defined in Section 4.4 is present. 397 SR Algorithm is used by the receiver to derive the Label. When 398 A-flag is unset, this field has no meaning and thus MUST be set to 399 zero on transmission and ignored on receipt. [major] Is the algorithm not always used by the received to derive the used label? the algorithm is either 0 (or 1) or one of the flex-algorithms. Iam not sure why there is an A-flag? could the setting of AR Algorithm not implicit assume that there is an SR Algorithm? why a specific A-fleg? <SH> This A flag is derived from base document that defines segment types. RFC 9256 and draft-ietf-idr-bgp-sr-segtypes-ext. I think as Algo 0 is a valid algorithm, there is A flag defined to instruct specified algo MUST be used. If no A flag then either algo 0 or 1 can be used to derive label. 404 IPv4 Node Address: 4-octet IPv4 address representing a node. [minor] Should it be mentioned that this should be best a stable address (e.g a loopback address?) <SH> yes. Good point 406 SID: optional: 4-octet field containing label, TC, S and TTL as 407 defined in Section 4.1. When the SID field is present, it MUST be 408 used for constructing the Reply Path. [major] A SID can be a label or an index. Is there a reason to exclude the index type of SID? (see: https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/rfc8402*section-3.1.2__;Iw!!NEt6yMaO-gk!DDRHlr3LozgYc2SPH9ia7xvN_6lrrMs4BKzfdXkHRQCstSUMVNiYMjyJbIngQPDBPvxp9W1-wGUGKZPM$ ) <SH> I can see how providing an optional label can be useful in some cases where remote node Does not have SRGB details etc. I don't see how index can be useful. Again, these segment type formats are derived from base specs. 414 The SID is optional and specifies a 4-octet MPLS SID containing 415 label, TC, S and TTL as defined in Section 4.1. [minor] Seems duplicate text meanings already documented in line406-408 <SH> fixed 417 If the length is 8, then only the IPv4 Node Address is present. 419 If the length is 12, then the IPv4 Node Address and the MPLS SID are 420 present. [minor] Is this not already documented earlier when the Length field is described? <SH> Fixed 422 4.3. Type D: IPv6 Node Address with Optional SID for SR MPLS [minor] This section has similar editorial issues as section 4.2 where some fields are explained twice. Maybe optimise the formal text <SH> fixed 494 A-Flag: This flag indicates the presence of SR Algorithm ID in the 495 "SR-Algorithm" field applicable to various segment Types. [major] Why not use the existence of the SR Algorithm field instead of a A-flag? <SH> as discussed in previous comment on same topic. 507 This section uses the term "initiator" for the node that initiates 508 the MPLS ping or MPLS traceroute procedure. The term "responder" is 509 used for the node that receives the echo request and sends the echo 510 reply. The term egress node is used to identify the last node where 511 the MPLS ping or traceroute is destined to. In an MPLS network any 512 node can be initiator or responder or egress. [minor] What is the difference between 'responder and the 'egress node'? should they be the same node? <SH> egress would usually have some special OAM related processing 516 In the inter-AS scenario, the procedures described in this document 517 are used to specify the return path, if IP connectivity to the 518 initiator is not available, and may be used in any case. The LSP [minor] Readability rewrite: "In the inter-AS scenario, the procedures outlined in this document are employed to specify the return path when IP connectivity to the initiator is unavailable. These procedures may also be utilized regardless of the availability of IP connectivity. " <SH> ok 529 As described in [RFC7110], when Reply mode is set to 5 (Reply via 530 Specified Path), the echo request must contain the Reply path TLV. 531 Absence of Reply Path TLV is treated as a malformed echo request. [minor] In previous section uppercase RFC2119 language is used. Would using MUST here not be justified? <SH> As another RFC text is being referred here, Previous reviews asked to remove normative language. GV> ok 532 When an echo request is received, if the responder does not know the 533 Reply Mode 5 defined in [RFC7110], an echo reply with the return code 534 set to "Malformed echo request received" and the Subcode set to zero 535 must be sent back to the initiator according to the rules of 536 [RFC8029]. If the echo request message contains a malformed Segment [minor] instead of 'does not know' i suspect what is meant is 'does not support'? <SH> Yes. Will use the word "does not support" 541 When a Reply Path TLV is received, the responder that supports 542 processing it, MUST use the segments in Reply Path TLV to build the 543 echo reply. The responder MUST follow the normal FEC validation 544 procedures as described in [RFC8029] and [RFC8287] and this document 545 does not suggest any change to those procedures. When the echo reply [major] If validation fails (e.g. sid does not exist or is not reachable for example) would this cause a echo reply to be returned with some error subcode? <SH> Is the question about FEC validation? Or Reply Path TLV validation? FEC validation procedures are governed by RFC 8029. If it Reply Path TLV validation Text from previous paragraph applies. " If the echo request message contains a malformed Segment sub-TLV, such as incorrect length field, an echo reply with return code set to "Malformed echo request received" and the Subcode set to zero must be sent back to the initiator." GV> ok 545 does not suggest any change to those procedures. When the echo reply 546 has to be sent out the Reply Path TLV MUST be used to construct the 547 MPLS packet to send out. [major] Must the MPLS label stack created by the node be an exact copy of the sid stack encoded in the Reply Path TLV? can there be MPLS labels added (for redirecting purposes or special services)? <SH> should be exact copy as per this document. That clarification has been added to the text as part of previous comment. GV> thanks 555 segment from the Reply Path TLV. The remaining labels MUST follow 556 the order from the Reply Path TLV. The responder MAY check the [major] What if te order of labels is kept, but some other labels are inserted for steering or other purposes? <SH> This statement is added. " The MPLS header of the Echo Reply MUST be constructed from the segments in Reply Path TLV and MUST NOT add any other label" GV> thanks 566 if such information is available from the controller or via operator 567 input. In such cases, the node sending the echo reply MUST derive 568 the MPLS labels based on Node-SIDs associated with the IPv4/IPv6 569 addresses or from the optional MPLS SIDs in the Type-C/Type-D 570 segments and encode the echo reply with MPLS labels. [major] What if the Type-C/D encoded IP address does not correspond with that nodes SID? What would happen? for example IP address 1.1.1.1 has SID 111 but in the subTLV the address 1.1.1.1 is encoded with ID222. Would that give an error or is there some validation? <SH> The Sid overwrites. This is explained in the text " When the SID field is present, it MUST be used for constructing the Reply Path." GV> i missed this. Thanks for pointing it out. 636 it is RECOMMENDED to add a Type-C or a Type-D segment, but 637 implementations MAY safely use other approaches if they see benefits 638 in doing so. If the existing segment in the Reply Path TLV is a [minor] I am confused by the wording of other approaches? If Type-C or D is not used, only Type-A remains. Is that 'the other' approaches? If yes, then why not just say to insert Type-A? <SH> It's quite obvious only remaining option is Type A. Since SRGB is not common, The other approaches is about how to correctly derive Type A label. The approaches are out of scope of this document 646 When an ASBR receives an echo request from another AS, and the ASBR 647 is configured to build the return path dynamically, the ASBR should 648 build a Reply Path TLV and include it in the echo reply. The Reply [major] This is most likely a clarification item. Would this result into potentially multiple Replay Path TLVs to be appended? or to have additional subTLVs (i.e. Type-A) to be inserted into the Type 21 TLV? i believe that later in the paragraph it is indicated that subTLVs are added <SH> yes. 674 An ASBR that receives the echo request from a neighbor belonging to 675 the same AS, MUST look at the Reply Path TLV received in the echo 676 request. If the Reply Path TLV consists of a Type-C/Type-D segment, [minor] IS 'receiving' correct? it is receiving and if the local SID is the top sid of the received packet then the processing takes place. Otherwise the packet is presumably MPLS switched onwards without any processing by the local node. <SH> This is OAM echo request processing. So any packet hitting TTL expiry will be processed by the Node and echo request will be examined. 701 6. Detailed Example [major] This is an example of the formal procedures outlined in this document. Examples are not formal procedures and are better placed into the Appendix. <SH> done 950 IANA should assign three new sub-TLVs from the "sub-TLVs for TLV 951 Types 1, 16, and 21" sub-registry of the "Multiprotocol Label 952 Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" 953 registry. [major] These subTLVs can only be in the TLV21. Should that be mentioned on the IANA page in the registry notes? <SH> I am not sure if this needs to be recorded in IANA registry. Current document has provided use for TLV 21 only. Future documents may provide Details on use in other TOP TLVs. In case we were to strictly restrict the use to TLV 21 then separate registry would be the way. 978 New entries are assigned by Standards Action. Initial entries in the 979 registry are as follows: [minor] Using standards action would not allow the allocation of flags for experimental purpose. Maybe more appropriate is to allocate using 'IETF Review' (also known as IETF Consensus)? <SH> As said before, these sub-TLVs and contents try to mimic the already defined extension For the purposes of segment routing te policy. I don't see the need to differ from base spec Unless there is strong need tp do so.
- [mpls] Gunter Van de Velde's Discuss on draft-iet… Gunter Van de Velde via Datatracker
- [mpls] Re: Gunter Van de Velde's Discuss on draft… Shraddha Hegde
- [mpls] Re: Gunter Van de Velde's Discuss on draft… Gunter van de Velde (Nokia)
- [mpls] Re: Gunter Van de Velde's Discuss on draft… Shraddha Hegde