[mpls] Re: John Scudder's Discuss on draft-ietf-mpls-spring-inter-domain-oam-17: (with DISCUSS and COMMENT)

Shraddha Hegde <shraddha@juniper.net> Tue, 25 June 2024 04:40 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 1180BC14F6B7; Mon, 24 Jun 2024 21:40:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.953
X-Spam-Level:
X-Spam-Status: No, score=-2.953 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_LOW=-0.7, 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="umUHhhz7"; dkim=neutral reason="invalid (public key: not available)" header.d=juniper.net header.b="SyMkp5EJ"
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 BSsCgN40Y8PM; Mon, 24 Jun 2024 21:40:35 -0700 (PDT)
Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 43E7BC14F6BF; Mon, 24 Jun 2024 21:40:35 -0700 (PDT)
Received: from pps.filterd (m0108160.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 45OJ3q7C021096; Mon, 24 Jun 2024 21:40:34 -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=PV sF7Ov062/207vAN2185okdOwX8tj1RuGiDS+C3fBg=; b=umUHhhz7kznFkTY9CG ZMWltbBgRW3MixVGgxrdfdJNOfJu6DpuEBddUxvLWbLzSQHOzMbfsZ1dbOgCQOU3 wxqTEnkBmL2snJTM+u0kln+mPhClSo3MK6oA6GYBsDTUvV3C1lCGUAUFTPCfs+4d Qw61J14GGSdgVEyGFZOv1YLepe7WU9eUP59zbNERkwP3wh5ReivbD7dJzFqnJX9X EyHwUuv2QLNVFAo9VroiPY6sGg2IYAx0Jo5mju3VTNbxOc/Nyn9KJdrqPF8Iiisd BI/Qlv5NumdKt0+7M0jJtvK7urIiIv1hG1Qfarqt6bO9agkf3XobmogNdf6CC9h6 7/5Q==
Received: from nam10-mw2-obe.outbound.protection.outlook.com (mail-mw2nam10lp2044.outbound.protection.outlook.com [104.47.55.44]) by mx0b-00273201.pphosted.com (PPS) with ESMTPS id 3ywvhcn548-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 24 Jun 2024 21:40:33 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nAGe7TA7BHgfNID4sPXLO5kY/aZsIXMPnQ0HPkd6lKlsagEDLhVl4572cpkWJaSV7ObEGu8wp4nGbhbYmP9sNA4EdWr610D8sFbyHwkO8MMm9laqK6MujIvv88L1NgCxSx2qZ/FXMQXVxdsXfp8SdG23GxA3p6NGQ4L68NZt/QzKWlr6ZWyfd6eSArg5rKXBGKuTvdr6wdkMV6jI4hoRfa/5TbpFAl5IXNmioSDgLZUutn1TdDT5iQeam6drT22LGaxb0eospQHnGes6wOcWwbYj6iPMBpU6U7y/5tEmOxZta3MMbZUVWu0d4z6jKVjVplhz1YkpxsQFEguog0lmzQ==
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=PVsF7Ov062/207vAN2185okdOwX8tj1RuGiDS+C3fBg=; b=QeNwt41xd0rFcdMw6HOH2T+Eb/e2iNAhWZdd7Q7FvgLiykglhu5ldV/rSH5Q9vkw8izQmkAaCFyznNh4TxS2mvI+f3Y/oDC8Ed5s5Z5MC7IEXw4KMZYrcgMMUHwANuh+860beHBtzeOZqIYCLdHQsfRzjsFmXk8rcf/2idgeYqvTdSEaFg4ZgTHRSA6N5O9lVn/L2wpUuc49IF+59DHClcbYXnEzjrg3Pu3UbuW4IEQ8HaLt1v7YL1AOgTWmtJBgOJ4GwMlMV5TdH6iOG489cBAXU2D7sDilv8NOd5UQ5rcHfa55g5DKQ3LVE51cVhK4hV7wqMyUK1J1ubHY6VeC2g==
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=PVsF7Ov062/207vAN2185okdOwX8tj1RuGiDS+C3fBg=; b=SyMkp5EJvTkl38bf94etH32HOuUD8GQAIf1DmFLKTdX1XSDoDoUUZEqO1F6IbhFyYJjeE2PktKZfusyR7hz21ci/KATGrxu0KnCbP6/XTj9qi8nhpcUIUv/s8y8xsowOeyjyfql9hXyh/LBsOI/Kmp6QLSpQDlgYQ7IyLdrpucs=
Received: from CO1PR05MB8314.namprd05.prod.outlook.com (2603:10b6:303:fd::13) by PH0PR05MB8270.namprd05.prod.outlook.com (2603:10b6:510:a7::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7698.30; Tue, 25 Jun 2024 04:40:29 +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; Tue, 25 Jun 2024 04:40:29 +0000
From: Shraddha Hegde <shraddha@juniper.net>
To: Loa Andersson <loa@pi.nu>, "adrian@olddog.co.uk" <adrian@olddog.co.uk>, John Scudder <jgs@juniper.net>, 'The IESG' <iesg@ietf.org>
Thread-Topic: [mpls] Re: John Scudder's Discuss on draft-ietf-mpls-spring-inter-domain-oam-17: (with DISCUSS and COMMENT)
Thread-Index: AQHavOLOJUYE0RGfyEGU0O5rsw9HT7HEVssAgBOgOMA=
Date: Tue, 25 Jun 2024 04:40:28 +0000
Message-ID: <CO1PR05MB8314C345ED23528CCC997BD2D5D52@CO1PR05MB8314.namprd05.prod.outlook.com>
References: <171811782664.60855.14869874777880744462@ietfa.amsl.com> <5091fcba-d18c-4654-867f-e56528c8ea00@pi.nu> <043001dabce2$c4773b30$4d65b190$@olddog.co.uk> <13dcf4fa-a7b3-4dc7-83a9-1a5170f52cb4@pi.nu>
In-Reply-To: <13dcf4fa-a7b3-4dc7-83a9-1a5170f52cb4@pi.nu>
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=e8b4cf4f-59b1-4f82-abb9-7ee51a830ead;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-25T04:30:22Z;MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: CO1PR05MB8314:EE_|PH0PR05MB8270:EE_
x-ms-office365-filtering-correlation-id: d163a29b-e480-4379-f211-08dc94d0f08a
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230037|376011|1800799021|4022899006|366013|38070700015;
x-microsoft-antispam-message-info: ht9Y7urvyBRXFjFXOAFyoYKoTb3FLYkpXbXv2T4Gep/Vso+fwWtOBWUiwCMhH1Vz16wIDPzlRbhunrmVaYPTTfYtvvNznM5t7JOu+dJZPsFHksnlo4la9l/v2/oKlKMwrayDSjQMuswCu/oGCFTrk+Roori04ParE/4pZlZtAlqf4oWybfo/Vq27j66yVNerqk3r+T+rlU91ojng6+xT+BlceFfUhEAiEu58ubE85F2tTLUsz9BEV2Ms/igaiqoTwqYXp4zYL9xefu5gn8/v6TIcF0I3BALR+sLJU05wfNOFDIp3Roj/g/G3rsMRjiXE3LMuH5q/AS/jv7puXqUy01qA3226NzYEkYEr8txV9sFMsrjWTHYSPHVtL8AcC7aGHAgRKMmnGxQysCc28G/hmepMNOn9/jSdd6EKbcuY/WE2z5H/EosPkuHCMB4ckFGIFRL1r0u8Azv3XiR/m1qjqXc6iQb+hqZFWSOwoQ0LjfQmyK4vryH0cA3AdburlPV4NFt6N0rm1nNGw2y96Snr0Qqt+9qj84KJnOqiMhr/2NgRYM/MbpSzjjKnEWOO5xmshK9DI5h19phAHbUBnWaNMEspQjJ3JGJj0BNPo0XLrqcg0H2pzPeshGhaZBkv89q8JtWuZ3TNDneO1BUlr6W9XnMS0L7Iv2tvQGVP00ss/HCYhq8sxWVgCxvpTUbECkrK4mXs8Y9M8pk/+SOK7qo01zPB6K14D5UKMGxnrrgTo1abY3fv1lZa1VAEpQ2OCUkVZwnIjNi89yMJ+4iG0zWkDkyTHZ0Jn+lV3aApD23vERAFCzqvkKiAAP//XrPQYOeFBFe6xpfgphDGamo1Fl1ROmBVnSPMZwrg5BfngUumXOFEn7F9tqAkdKdjWj6VHBgeDE3Fs60mHJ1cjUQ2VKCX9pczeclEGZ/BKs7nUqJruI1gw3YnXYwQXCp3P95+ZPJHJhzX86EBJKBZlJRFlu8AnyEEhSyp6Awqc8MRNi5hItDEMClF9CFyU1/GC7VgvN9Pcdst0vhMQhwOLWd//1Tux/VTz5tRFGghpKO04P91nXCDHL6Ylwh+sjKJXSwR7/ok8S/77LIrz/W076gnN8YFwqXOzOFt6lSoIvXqouceV3mI1f/+lQ0QIJeIrINP8eUCJnyDzcvV1LOY7nVJ1jGzAWerqe/LFQA/3lXGMrdIoJh/gtt7O08XH5QximyZo2dQ8bf5g6JX2rtN1pFpk0VK0gUuu7RqPL8P+d4Yhm5t3RgIRZjKAZnkDT5K5Gt71piVCUgVnAfcIGbHJk4c3uYy+EKDzFvbEUxO4NmVtsClmjsTubsvWd5ZaK51WNmOZlLUfiT1/c5ek5RlwfD2W154Yh6C3HkWfW177PKERD9a0mM=
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)(4022899006)(366013)(38070700015);DIR:OUT;SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: 48Xn09dgQXHAm2AXtgzswpTJYze/Txy6ywlpzVYodZSfkdlzP6/EA5WQGaQilLPzl6YNeDQu75jc8w6NXFSDV1lEnj+Vu0UUE9l1heWtGruyIAz51IyPmKO9AA+1LMKeqlMBBIo/Zy+/7eKxMoSfbogww5L7HRpNYNpnYqiaLU9kkHwTrNnK2wnIgJXwMmlZuxj/nBWcjLl7QY+1zO/95QHiJ6iklCK341khE2N+7KBvwnJHO0brYj8EQp66G4Fnwy1/9WM9NgG2WVMAFeCsEGx4cGMeAwXiFmoux51irDWUFMrf2IKnd9pS3uDXAGPWp3jD74f6ZeiQZ2UAqwIq+6dlrAEhP09z9DPQPSoZFDWQzjd3yykpsbZ+GNURuUOxt8bZDHZ/GeRPZBvC4hM+dE2PJlSzvTYIHOqtXGbpUDmhnWiUJb8vxntbrHybCeVWmjX+4TvzfsRAj16zp/tIqBXAJpdkhcOXWUCs9D/lMWO8rOBzSu9HPPomOjNgjWr9WkTLpxOaqgyz3GNQcEo4ZACMiewnLFApuP7YP4Ldg03o60zmlPo97Q5zy6mHQ/P2yrPOzaSF8vH8qgnCFvoYptQsguSzT5EvOqOkfLiHDTPV/7n3sraLDiK2L1B9yBEnjMRMwEahFH5ZufbLr4TOFb1ITJckhkvv3ePXGfi9xPRWBkjiuxC2r34MW500nM3PEvbN3eL8zbDencMmiBdxxWe9x1aEaTMdPt0cRSu8EmN5yfZE9U2JMUxU/fy5OKGNGQb3E6r1Jk3z9WqHTWzNqmJibEmqEhrpb0/7zRTM4LWhJuIF/KlYutAe78ErVO0irTjQh8KG+canA0bxW8KCmBUHBVXb1ew1yVxNEIw0do1Q0WQimxloEJb2+WEZ5d6OCOEsj9eRX5abaNmecpCG9zLhHt6jr11aov6Wrlzgog8JRHYe2aGJ2p7U1eyA3gPeEFRIMmhQeD+aNuu6DcJssmtP5nmgmNYcvcZRJFNJVVycnDlEvJh9lUn52eyOUNWwW9u7TEZf0TxEzfHk+i0hYY51Ff72H407fdCi1Rj5jVwnor9jNUjVds1WAB4ND8KAsr5bB8BHIlmlaWWF/HwszLqs1EvU+Yz1jnXjrnz+AS+hm456gOoiGXIeA7SXKYPD/b+RxDdQ6rNfDiZakXmF8i6pWAYfWH6pqQym3pFJgOWW2KVJ3vV6iFrkszTVOenIWNJJAzjVAq3bEVG8ds59rO+pWCeLJmDevG7xGFqKFwZr8RFFi0YJrZ9E0wxLONMkjGJG/SNyxsxPYwOcMp2C6CZHyuM8kumzJ/lAIqxXw39/KzFGmeUFf8MwuKXL6i7BiK9Fijg1CGMmv9QS+3TL3Ovmga1unrGq6tIMMGdodSzs4Tk6tIP/KgM3dNUD83IPTpP6g9+xNOPNbA4ZtOV70Gk9o/3/zypGLFpKRPuC1kwWtKWKYgtrkNwoI8YIlFx+WkkgajK8eelpG2KRlGviBN3wbTGdPyYqC5nydQ1enAuq65pxviVl6uTjPGWI984Ukz6wuqqT+LpBHl9OJurTxRLxdf58vPFR+iow0PrE6OntpzWSVqUSWhbH5h4TR9zY
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: d163a29b-e480-4379-f211-08dc94d0f08a
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jun 2024 04:40:28.9369 (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: mgQVpoKUYlzTAmE4EJeccz4IihsGg/iUI0rhttpihqrBjXh20E7WEp73x9uDmjpVKkdqViK0IOqYiR027uczIg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR05MB8270
X-Proofpoint-ORIG-GUID: XTrCNXpc5-kQ-37yxhpTnUHiICXs7aAN
X-Proofpoint-GUID: XTrCNXpc5-kQ-37yxhpTnUHiICXs7aAN
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-25_01,2024-06-24_01,2024-05-17_01
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 spamscore=0 clxscore=1015 mlxlogscore=999 bulkscore=0 priorityscore=1501 impostorscore=0 adultscore=0 malwarescore=0 lowpriorityscore=0 phishscore=0 mlxscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2406140001 definitions=main-2406250034
Message-ID-Hash: YB67ATK5VX3V5ISTRPO34AZ4YSR3JLQ6
X-Message-ID-Hash: YB67ATK5VX3V5ISTRPO34AZ4YSR3JLQ6
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/j9sPDArbDwRdFBOC8n9uIPq28lc>
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>

Adrian,

Thanks for the comments.

I have added below statement in procedures for sending echo reply
"The S bit is set for the bottom label as per MPLS specifications <xref target="RFC3032"/>"
It seemed a bit odd to talk about this in the TLV definition section as it has not been
Discussed how these labels are going to be used in that section.
- ver 19 will have the change.
Let me know if it looks good.

Rgds
shraddha


Juniper Business Use Only
-----Original Message-----
From: Loa Andersson <loa@pi.nu>
Sent: Wednesday, June 12, 2024 10:18 PM
To: adrian@olddog.co.uk; John Scudder <jgs@juniper.net>; 'The IESG' <iesg@ietf.org>
Cc: draft-ietf-mpls-spring-inter-domain-oam@ietf.org; mpls-chairs@ietf.org; mpls@ietf.org
Subject: Re: [mpls] Re: John Scudder's Discuss on draft-ietf-mpls-spring-inter-domain-oam-17: (with DISCUSS and COMMENT)

[External Email. Be cautious of content]


Adrian,

Thanks! I have re-read the draft now and think you are right.

I would not object to some more explanatory text in section 4.2., and I'm not clear what it means that the S-bit is "Reserved".

/Loa




Den 2024-06-12 kl. 18:08, skrev Adrian Farrel:
> Loa,
>
> I don't think this is the S-bit in a Label Stack Entry in an active label stack. It is the S-bit carried in an LSE in a TLV that can be later used in the label stack.
> That means that the S-bit in this document is meaningless (ignore) and will be rewritten when the LSE is used in a label stack.
>
> A
>
> -----Original Message-----
> From: Loa Andersson <loa@pi.nu>
> Sent: 11 June 2024 19:01
> To: John Scudder <jgs@juniper.net>; The IESG <iesg@ietf.org>
> Cc: draft-ietf-mpls-spring-inter-domain-oam@ietf.org;
> mpls-chairs@ietf.org; mpls@ietf.org
> Subject: [mpls] Re: John Scudder's Discuss on
> draft-ietf-mpls-spring-inter-domain-oam-17: (with DISCUSS and COMMENT)
>
> John, authors, (top post),
>
> Apology - I have not been following this draft close for a couple of months.
>
> It seem that the draft mandate a receiving LSR to ignore the S-bit.
>
> Why would we ever want to do that?
>
> /Loa
>
> Den 2024-06-11 kl. 16:57, skrev John Scudder via Datatracker:
>> 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/st
>> atements/handling-ballot-positions/__;!!NEt6yMaO-gk!F4taMkUXbvRsecGiT
>> IJBBGLStStoko9_p8hAKoiIK8rT7k6cWRubuvPH-uHg3yKp_jKtZsv4qg$
>> 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-ie
>> tf-mpls-spring-inter-domain-oam/__;!!NEt6yMaO-gk!F4taMkUXbvRsecGiTIJB
>> BGLStStoko9_p8hAKoiIK8rT7k6cWRubuvPH-uHg3yKp_jIFxBJjrg$
>>
>>
>>
>> ---------------------------------------------------------------------
>> -
>> 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.
>>
>> 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.
>>
>>
>> ---------------------------------------------------------------------
>> -
>> 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? 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.
>>
>> 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.
>>
>> ### 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.>
>>
>> ### 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.
>>
>> ### 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”.
>>
>> ### 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? 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.
>>
>> ### 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.
>>
>> ## 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/blo
>> b/main/format.md__;!!NEt6yMaO-gk!F4taMkUXbvRsecGiTIJBBGLStStoko9_p8hA
>> KoiIK8rT7k6cWRubuvPH-uHg3yKp_jL2diTthw$
>> [ICT]:
>> https://urldefense.com/v3/__https://github.com/mnot/ietf-comments__;!
>> !NEt6yMaO-gk!F4taMkUXbvRsecGiTIJBBGLStStoko9_p8hAKoiIK8rT7k6cWRubuvPH
>> -uHg3yKp_jLQGomsdA$
>>
>>
>>
>> _______________________________________________
>> mpls mailing list -- mpls@ietf.org
>> To unsubscribe send an email to mpls-leave@ietf.org

--
Loa Andersson
Senior MPLS Expert
Bronze Dragon Consulting
loa@pi.nu
loa.pi.nu.@gmail.com