[mpls] Re: John Scudder's Discuss on draft-ietf-mpls-spring-inter-domain-oam-17: (with DISCUSS and COMMENT)
Shraddha Hegde <shraddha@juniper.net> Mon, 24 June 2024 17:20 UTC
Return-Path: <shraddha@juniper.net>
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 1BB3AC18DB9A; Mon, 24 Jun 2024 10:20:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.253
X-Spam-Level:
X-Spam-Status: No, score=-7.253 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_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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=juniper.net header.b="zRAxydKQ"; dkim=neutral reason="invalid (public key: not available)" header.d=juniper.net header.b="O3N5uuhT"
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 dp7FTYnHrLu1; Mon, 24 Jun 2024 10:19:55 -0700 (PDT)
Received: from mx0b-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 BD696C180B78; Mon, 24 Jun 2024 10:19:55 -0700 (PDT)
Received: from pps.filterd (m0108157.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 45OCwm9m011162; Mon, 24 Jun 2024 10:19:55 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s=PPS1017; bh=Cw R+Qk1+yybPUCyk8xrmixkciljyyhmh1ZV/HI6qP18=; b=zRAxydKQX3cjoUk8WJ m6k5MFmkq4XkiYoSTOr/x7IKUbX2EX/mb97pvtdKjpPmH1cE12asXec9PoLHsiqK KoSRCLeCUXIH4YihNsYz5mxiwOfzOFBQRWkXsVbWDkkqh2UEJ6ZlhPjIPSTz/EFq SGVf+c+gR+FUA71JKGlefPCptgcnPy8fceIrdBmo6ztkHptLns9yUOkhbBELFT4i eTowMgKPNuJeLrQjF2KpgmP2HFSrKlCkg098+SICrt7zgE93vIGllw7zfexBMGhf UvcQeI7PfTLl/eoH6u7PFdzHtcPcA0MnQPjxljLBnm4uDdXhST3U2wizJYk5ufSL R+ig==
Received: from nam11-bn8-obe.outbound.protection.outlook.com (mail-bn8nam11lp2171.outbound.protection.outlook.com [104.47.58.171]) by mx0a-00273201.pphosted.com (PPS) with ESMTPS id 3ywwvgkb49-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 24 Jun 2024 10:19:55 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=F5wC0iMzYpsZZ6Aoia0ACiTRKZe3huf5sf7tGFil6CWX4L+Fe7tuaeTB6HCfdwnED8Dy7M9ob52pWNSraiPk08n+mEe1hUuBkqVsX1cICvfKXY5PUkDj2M4Z/SrKgJZwRzWX1khdnSah6vCavUlXnB7EoZZKK1mxEBGpIxcPsuWt4uDF1j7mEHUSYSKKAF1NgNN/BijKL5ny/9WjOsIxwVO+LfrjdQd34rG2S1rN0RcRFkFWXscNQtUCs1dovtr1r2ZHTa3wiKrfmmQVJtlBQxWl26UGxGliZeaHYttQbu380SkounFnZYqr+l96u5+Q0yLoI10yIGoQeDejxGiNkQ==
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=CwR+Qk1+yybPUCyk8xrmixkciljyyhmh1ZV/HI6qP18=; b=iS1MfCMLSmrEBNkDX1Be1cHEjIrz/TSVS8Ru5+EEhnr+cODuGR9wBCpk4YhIbqiOdwRT187n+Ycnd8ZLPHFMP9PR46fhYCq6Rgb+RbxADAQZi6vjA6slacJFEZvJ6r6E/5EFWEIwt6bIS1GRa4boGs6igHKWtF1o/Z3lcLRGtQjYIYicax0FcTyQOWc7KHEspZNVMZm3EjQnzIauBJ4kMQ9O7zbEIxjY6sFI6ICUizRiVdm6tVxDAwxq6sofCi5KzbktYII7CHdcUqoTtJZh8nTpo2nDUbdNVEZRvFqdgG8En9VioocfFm2J4lduKtH/Bg+NTe9hoSm89WwT5J8A8g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=CwR+Qk1+yybPUCyk8xrmixkciljyyhmh1ZV/HI6qP18=; b=O3N5uuhTBK7PvTP8QbksxblV9QW8fYKbBRXBsyB8VgU6Oc+YUco7qbDu+cw1NbAQ6dpOGUr24W76wzxoAoE1LVquM1+pvk2tQJmiRicxg/8m98LxcdTtCrohaAHci1dX56ztbCSDrcXxEcti+Ub09hsJ/3HGcW4oS2cIcsZAxgw=
Received: from CO1PR05MB8314.namprd05.prod.outlook.com (2603:10b6:303:fd::13) by PH0PR05MB8510.namprd05.prod.outlook.com (2603:10b6:510:a7::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7698.29; Mon, 24 Jun 2024 17:19:49 +0000
Received: from CO1PR05MB8314.namprd05.prod.outlook.com ([fe80::9a48:3f33:3abc:59b0]) by CO1PR05MB8314.namprd05.prod.outlook.com ([fe80::9a48:3f33:3abc:59b0%4]) with mapi id 15.20.7698.025; Mon, 24 Jun 2024 17:19:49 +0000
From: Shraddha Hegde <shraddha@juniper.net>
To: John Scudder <jgs@juniper.net>, The IESG <iesg@ietf.org>
Thread-Topic: John Scudder's Discuss on draft-ietf-mpls-spring-inter-domain-oam-17: (with DISCUSS and COMMENT)
Thread-Index: AQHavA+mSKvAaWXsw0iwyrUzOV4QX7HWwClg
Date: Mon, 24 Jun 2024 17:19:49 +0000
Message-ID: <CO1PR05MB8314872E0726691DD012D4B6D5D42@CO1PR05MB8314.namprd05.prod.outlook.com>
References: <171811782664.60855.14869874777880744462@ietfa.amsl.com>
In-Reply-To: <171811782664.60855.14869874777880744462@ietfa.amsl.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=48d3a642-cc41-4c84-9c2b-2614967273f2;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-24T09:51:53Z;MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: CO1PR05MB8314:EE_|PH0PR05MB8510:EE_
x-ms-office365-filtering-correlation-id: 7b659ca4-0cdc-4dd4-f447-08dc9471da31
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230037|376011|1800799021|366013|38070700015;
x-microsoft-antispam-message-info: 3m7kg569eUzNldhVGtEQTCJbuhrNsGXv774ocEHfotqV8oOsOqwwp1kkyrpULhGMYsoaf7AkmVA0FMLt56Wo/dyRBkAmgzRzRNCJuZE3ZfCSZVKN16v+vGpx9nECfd4PYbmD/qmveK6bwg+ftivsYrmuvDk2ag1/bG6DC77WQH4zRN9JgMkeZv8NV6oDSGDvKeRPGOS8UR0ulYcbnP9CZtgYkPTvhyVMBJaTjnmwce/SJ+GPMUW+AoJkwBrUfPW9wET65NJpm/6WVHEzZALrgiZF7lYDKttssDb+6prvRvl52F9QlBlApxgZPycGW7fQAmP4ISZpXQsYbnvvk4DmIzfdfrpzoaHqHYqb4ZzCa8MIfgZwqNOY56JLbcbsjHdRtckboyke+UkqWeUJm9beBSBQvCRjnFgW5dtwnmC3kEa8R+OLDICtwBnfF6pwxl9rf53WzK08JAbupwzuqw+SVmHSWCGLG9OjKpLJJjo5yVzXP5qToXJhV6/Sa6R8+0WpJNybRictRZUOX6WQq4onyc024388BWEmHMUEmVDTFl+Qs6N0iDO0oapq5bj22CQWpEPFi2JAbDeKfsw85/pTbjQclRIjoMc/JP0NYG/VisxqPoZlwjwLQSMHupb5G6Z6UVgu8oss4cMyXxNIRjqL3V/Iw7ExW6LrmuobnLvVDMH02Pl38/S1aELTtcX2Kr9uAnXSZncmSveEVUF2l6UIwrVJgj/xGu2TCOwXBZDi1aTvI2WnY25BtnCVZKVksHUvjT0BunLhVoq+Ulaj4tOXAhSA75eb51kTEk4k63b6XNg4OEeYTGqe+jDvRUOp18ehvKLt1B+xB810lS5bgIE04dWr7jZ9xU7GIvJbT3DkpITWq4Y6BtGulcyz2J+xaGIHLrEs+JBIbDEEhG6JdJNCkO7hSZQaNPGKENJtBU958BsACmk3lsq0/u04GDu9zgk5S5nLKRGqQARYQ1d2q1pFwSOjP9icFE3+sJoJHjMTppol1Wl2s+l6DnooJSfQR3EB3OuwfwANaBZmv4N9/iXgRrsXiPsSjrI666TJpzYrLVPUgKSFjbbHXR+wt8SG4eRO/MpOQz1nltPcgfRDBGIq5I8YRGVIguqW01m/dhz4CNfHmW+iY8GIB5q/0TN+K4mVd03T0r+BYkK3ZuAW4wuANT+O0xWXPG+vvDg3h5sy5xIpLZd9J6U7/8yemDOmJ5EPyBnZ2bgbeCVKnWWAJznGXmvRiuG+dggj4GdYaV+FEeLBPRRjTgozvI2UKXB1dfMQBTjK2N62tCC/rcwZyBJy1qJkvs2x45Unlc9KsYTiXDVXCvdKXsSIuV8K/Sc5vLES
x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CO1PR05MB8314.namprd05.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230037)(376011)(1800799021)(366013)(38070700015);DIR:OUT;SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: rtrk04+15V2nkdITh0xniU+J8fTOQdcjqXqm6rwwhDsn/btc7f7BXBuIami/CpGQbUb+HjNLzg2FRz6o83vsfNPARV4Vk89Ump+wP03+uJYVrZ93ooNmS9vJ6AyjO1T/Acw/4rnwHQBFwhRxN/vlLiu4NQuwjeJsMcfMWLYy5w5F2SH0EmSkCQUlgDcZGbEkCuhJ4e5/aegB5Nm6I5+ViUaxwyCmgbeYo74FpdyMzuYpOvZLme8TKjNC96DlOS98pQJYtsF95OJq10wlHZnPJ58r/OExS5yu1d1cv5NtUa3X3LYaD0kPXN3H6Q8SwB5IAlQoGA80aoVe31O9rxMNI/H7/HIu6+ega8NddILowNKa1FIlKjSNvH1On1y04H0TUR1nws9K+ad4oVxCS7KHZJxI5GrM8oBwI5djDZJMCxk1lxDRfRSsrdv9Cz6Tt4iTFYMM4R4k+DhVmt9jhU28q1DRcFU0kFh9qdh1vCiVIwdaHu976clHf95adJPet8OnR/p3gGinZP7d6IUyXOcZJoFHUcR4jBb00I28+fRXytkprYkTjKa3+jTl+Pro7Lyp6wRnQHCH4rlAFkrtXT+oKEHqExnMVJ0zCVzGtrQSpcq2tepiSJtO1uQaHTAuqueVNQfzL1ZgKyDso/gPgx3g/byivLOwPV3tpzByFBGHogZljAi2R2sgjrdF55ws/6IfeWvFZFJ44Np53B/e0eO8/53sP9dDwMnj8+Xkv0dJD64eHSmZn8jL9fj5MPrKSzPFk4SMtMIuCLNReFA+T73ioKj1z9We9EixxgmCc9+JWEjfRWhLm4u/8BvssGPwwz+eYJAmEchByy05P47zEQgyWSzDW3gWU948Gb/tGm84LTsR2s/51YtL5oSaht7a+OolYWTyMvL0R12ZsxS7JNJls9hKCW0Qhx0C3FdrCUIuDIpb1BmIWFg1S865B7kcqk47YTFwp5xMDdCBSe/uxGDa/OmohuEVJAm+myYB6HgtvU6NgwSuBOZe6ptA4hg1/v4ijAMaa6EXHR+lepeUm75SHapl3ij825NpaYV6F0e34Vpo7EqUvk7XKpBgmP5jo0SzE0Qr3gUbYXrKNoddZr460VsNW3S6lwDFTs6AQdl9d35x6Gj3VwjTWUI1Td0qPq8NQ6r+I5w1p4QwANg/9Lea5BXd4+dAIPSxZ9Xhnpwmo5T35J1CPx5TnByJSG+JSbMORWG2E9mRHtHYSBQG4hyqP28ZTn5P5ei9FpH2oP1sGzRb/WGLvC5xmc3bDjdfvddyRE4T1t9bFAErASjnEwoWxwA+7iarXrZGG9UUbdMKbLMRSMioqlXh5HvJcKKdhwMVec1sp5Ke5qXuW23gcrczv9Lt341zzcs3puQ50lwWiYiGo7Mf6qGTJvVz+8AmExJPVm2M8M+ygBEA8LOhDiH+OCxKUEv7A2VYRo7leBskyBR9OKsXBbquJTo+fPp0YJZ+CCFH00nkW3IrIy/vv8r9+R3syXG8iCepvWKKAPVDt63nfMSUZM5d5nifONVJsRIIRY4qIj85EUrXaK5FRYvTW2LutE3YYKmApmTu13XrYwUPr6ENO9CfKBaGhsPPPx4U
Content-Type: text/plain; charset="utf-7"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CO1PR05MB8314.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 7b659ca4-0cdc-4dd4-f447-08dc9471da31
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jun 2024 17:19:49.2204 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: MsNtuE+4nuTS9eY0mMm/IJpGDhUZ+bOwe+xPK5xSRPX4PpDS3X+IQ5kF7dCy0/VPrV7Fmw1KA7EQ5AVDInjMxQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR05MB8510
X-Proofpoint-GUID: FIlTeZEcJcKmd-L8DnpHbwzaEqZC1WO_
X-Proofpoint-ORIG-GUID: FIlTeZEcJcKmd-L8DnpHbwzaEqZC1WO_
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1039,Hydra:6.0.680,FMLib:17.12.28.16 definitions=2024-06-24_13,2024-06-24_01,2024-05-17_01
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 impostorscore=0 spamscore=0 malwarescore=0 suspectscore=0 adultscore=0 clxscore=1015 mlxlogscore=999 bulkscore=0 lowpriorityscore=0 priorityscore=1501 phishscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2406140001 definitions=main-2406240138
Message-ID-Hash: BHNUTXDRTAYMQ5S4KCUEFMYUUHUEYMIE
X-Message-ID-Hash: BHNUTXDRTAYMQ5S4KCUEFMYUUHUEYMIE
X-MailFrom: shraddha@juniper.net
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: John Scudder'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/WcUTmOaa4p28BydAVFD2uHvKjBU>
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 John, Thanks for your review and comments. Pls see inline for replies. Version -19 will address your comments Rgds Shraddha Juniper Business Use Only -----Original Message----- From: John Scudder via Datatracker <noreply@ietf.org> Sent: Tuesday, June 11, 2024 8:27 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: John Scudder's Discuss on draft-ietf-mpls-spring-inter-domain-oam-17: (with DISCUSS and COMMENT) [External Email. Be cautious of content] John Scudder 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!HsiYSkDu8aHBANSmdPW2CAGqVJhpFCDTkFoLDEVtEgWOF0xMWSy7OVeJQhG-mGj2ju7lF2dQDZqV4vr6$ 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!HsiYSkDu8aHBANSmdPW2CAGqVJhpFCDTkFoLDEVtEgWOF0xMWSy7OVeJQhG-mGj2ju7lF2dQDdYdfllI$ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- # John Scudder, RTG AD, comments for draft-ietf-mpls-spring-inter-domain-oam-17 CC @jgscudder I can see that this document solves an important problem, thanks for your work on it. I find a few of the consequences of the use case a little puzzling, more in my DISCUSS and comments below. ## DISCUSS As I understand it, the motivating use case for this document is summed up by this paragraph in the introduction: It is not always possible to carry out LSP ping and traceroute functionality on these paths to verify basic connectivity and fault isolation using existing LSP ping and traceroute mechanisms([RFC8287] and [RFC8029]). That is because there might not always be IP connectivity from a responding node back to the source address of the ping packet when the responding node is in a different AS from the source of the ping. That is, you are fixing the problem where some node needs to send a packet back to the originator, but doesn't have reachability to it. As a general thing, I think the document would benefit from more careful consideration of this in some of the sections, and I have some comments below related to that. I also have identified what looks like at least one bug -- Section 5.3 includes this requirement: If the top label is unreachable, the responder MUST send the appropriate return code and follow procedures as per section 5.2 of [RFC7110]. But, in this situation, the responder is unlikely to be able to successfully send any return message, because the top label is unreadable, and by definition of the use case, the responder doesn't have IP reachability to the head end. I understand that this might be a problem that has no perfect fix, but (unless I'm just wrong, in which case please tell me!), I think you should put some more realistic guidance in this requirement. <SH> You are right. The responder may not have IP reachability, when it lies in a different domain than the originator. You are also right that there is no perfect fix for the problem. I'll add below guideline " If the top label is unreachable, the responder MUST send the appropriate return code and follow procedures as per section 5.2 of <xref target="RFC7110"/>. The node MAY provide necessary log information in case of unreachability. Note that the responder may not have the IP reachability to the originator, in which case the Echo Reply will not reach the originator." By the way, the detailed example section was very useful, thank you. I think adding an example walk-through of an error case to that section would help elucidate this. <SH> ok ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- ## COMMENTS ### Section 3, if I can compute the return path I don't need to trace the route This text made my brain hurt: One of the ways this can be implemented on the head-end is to acquire the entire database (of all domains) and build a return path for every node along the SR-MPLS path based on the knowledge of the database. That's because, if I have the detailed topology database required to do this, I already know everything the traceroute will tell me. So why bother tracing the route? <SH> The Database generally acquired from ISIS/OSPF. So it has information of the nodes, links,prefixes, SIDs etc. It does not give any information about what each node programmed into their FIB. With traceroute we are trying to figure out by traversing the forwarding path one by one what is programmed in FIB on every router. It can't be simply to verify connectivity, ping would do that, and if I want to verify that connectivity follows the expected route, I can ping with a strict source route. Furthermore, if the traceroute diverges from the expected path, it might be that replies don't come back to me, because the return path I've included might not work for nodes along the actual path. <SH>When a traceroute succeeds it tells that both forward and return path working well and also tells you exact path traced. If it fails, you will know exactly on which node there is problem. Whether forward path was wrong or return path was wrong need to be further debugged by connecting to the node which is in problem, that is out of scope for ping/traceroute procedures. I see that dynamically computed return path addresses these concerns. But I'm struggling to understand what value a precomputed return path, as per the quote, brings to the table. <SH>Is the explanation above helping? ### Section 4.1, minor comment, consistency, flow You have, RESERVED: 3 octets of reserved bits. MUST be set to zero when sending; MUST be ignored on receipt. Label: 20 bits of label value. TC: 3 bits of traffic class. S: 1 bit Reserved. TTL: 1 octet of TTL. The following applies to the Type-A Segment sub-TLV: The S bit MUST be zero upon transmission, and MUST be ignored upon reception. Why not specify the S bit value and behavior in line just as the reserved bits are? As in, NEW: RESERVED: 3 octets of reserved bits. MUST be set to zero when sending; MUST be ignored on receipt. Label: 20 bits of label value. TC: 3 bits of traffic class. S: 1 bit Reserved. MUST be zero upon transmission, and MUST be ignored upon reception. TTL: 1 octet of TTL. The following applies to the Type-A Segment sub-TLV: <"The S bit" line is deleted.> <SH> took care of this in ver-18 ### Section 4.2, why exclude Flex Algo? You cite RFC 8402: SR Algorithm: 1 octet specifying SR Algorithm as described in section 3.1.1 in [RFC8402], when A-Flag as defined in Section 4.4 is present. SR Algorithm is used by the receiver to derive the Label. When A-flag is unset, this field has no meaning and thus MUST be set to zero on transmission and ignored on receipt. Are you intentionally excluding flexible algorithm (RFC 9350)? If not, you might take a look at the way draft-ietf-mpls-mldp-multi-topology does this. In brief, they have a definition in their Introduction: A more lightweight mechanism to define constraint-based topologies is the Flexible Algorithm (FA) [RFC9350]. FA can be seen as creating a sub-topology within a topology using defined topology constraints and computation algorithms. This can be done within an MTR topology or the default Topology. An instance of such a sub-topology is identified by a 1 octet value (Flex-Algorithm) as documented in [RFC9350]. A flexible Algorithm is a mechanism to create a sub- topology, but in the future, different algorithms might be defined for how to achieve that. For that reason, in the remainder of this document, we'll refer to this as the IGP Algorithm. And then elsewhere they just refer to "IGP Algorithm". I'm not saying you have to adopt this approach, but it's one idea. Same comment applies to Section 4.3. <SH> This document does not intend to exclude RFC 9350. It's a miss. I'll explicitly refer RFC 9350 in this section. ### Section 4.2, SID field It’s a little messy that what is defined as four separate fields in the previous section, here is defined as a single SID field. For consistency, I'd suggest either representing this the same way you did in section 4.1, or alternately, Section 4.1 could include text to the effect of “collectively, these four sub-fields comprise the SID field”. <SH> ok ### Section 5.5.1, weird use of "MAY not" “MAY not” looks weird: Internal nodes or non-domain border nodes MAY not set the Reply Path TLV return code to TBA1 in the echo reply message as there is no change in the return Path. Can you clarify that you really mean what this literally says as per the RFC 2119 definition of "MAY", which would be, these nodes are permitted to refrain from setting the return code, but they also can set it, it’s all good? <SH> yes that’s the intended meaning of this sentence. Or, did you mean MUST NOT? if you do genuinely mean the first thing I wrote, I recommend using language different from “MAY not“, since it looks quite weird. <SH>Changed as below. Let me know if that works Internal nodes or non-domain border nodes might not set the Reply Path TLV return code to TBA1 in the echo reply message as there is no change in the return Path ### General, SRGB behavior In various places you talk about different actions depending on whether SRGB is uniform or non-uniform. I don’t think you mention anywhere how the determination of uniform or non-uniform SRGB behavior is made. Is it up to configuration? It would be good to be specific about this. <SH> I think below statement is explicit about SRGB being configured same or different " assumes the same SRGB is configured on all nodes along the path. The SRGB may differ from one node to another node and the SR architecture <xref target="RFC8402"/> allows the nodes to use different SRGBs." ## Notes This review is in the ["IETF Comments" Markdown format][ICMF], You can use the [`ietf-comments` tool][ICT] to automatically convert this review into individual GitHub issues. [ICMF]: https://urldefense.com/v3/__https://github.com/mnot/ietf-comments/blob/main/format.md__;!!NEt6yMaO-gk!HsiYSkDu8aHBANSmdPW2CAGqVJhpFCDTkFoLDEVtEgWOF0xMWSy7OVeJQhG-mGj2ju7lF2dQDeAqANdR$ [ICT]: https://urldefense.com/v3/__https://github.com/mnot/ietf-comments__;!!NEt6yMaO-gk!HsiYSkDu8aHBANSmdPW2CAGqVJhpFCDTkFoLDEVtEgWOF0xMWSy7OVeJQhG-mGj2ju7lF2dQDVKMrANd$
- [mpls] John Scudder's Discuss on draft-ietf-mpls-… John Scudder via Datatracker
- [mpls] Re: John Scudder's Discuss on draft-ietf-m… Loa Andersson
- [mpls] Re: John Scudder's Discuss on draft-ietf-m… Adrian Farrel
- [mpls] Re: John Scudder's Discuss on draft-ietf-m… Loa Andersson
- [mpls] Re: John Scudder's Discuss on draft-ietf-m… Shraddha Hegde
- [mpls] Re: John Scudder's Discuss on draft-ietf-m… Shraddha Hegde
- [mpls] Re: John Scudder's Discuss on draft-ietf-m… John Scudder
- [mpls] Re: John Scudder's Discuss on draft-ietf-m… Shraddha Hegde