[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.