[Teas] Re: [EXTERNAL] RE: A gap between Section 5 of RFC 4090 and Section 4.4.3 of RFC 3209

Alexander Vainshtein <Alexander.Vainshtein@rbbn.com> Tue, 27 August 2024 13:51 UTC

Return-Path: <alexander.vainshtein@rbbn.com>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0C1DC14F6FB for <teas@ietfa.amsl.com>; Tue, 27 Aug 2024 06:51:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.104
X-Spam-Level:
X-Spam-Status: No, score=-2.104 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rbbn.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 tXLqs0pOGlv8 for <teas@ietfa.amsl.com>; Tue, 27 Aug 2024 06:51:21 -0700 (PDT)
Received: from usb-smtp-delivery-110.mimecast.com (usb-smtp-delivery-110.mimecast.com [170.10.151.110]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88FF3C180B78 for <teas@ietf.org>; Tue, 27 Aug 2024 06:51:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rbbn.com; s=mimecast20230413; t=1724766680; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=fA0vni6xTUw8eFGtPAoXZRDSLarl/017Fv0axU7pLqs=; b=cP5rZvXnUch8HkxaJxZxDGC7nZBfpkT8jiehXNkwxtoxmu93X4ThNvgUVOyVdt5n4kRNNb 6UyhXaRFoV95ovTOiA8GdU9KQZ7GKgS4Gu7v+CEIK/zvA6M2YX3Sf60QzOgQOdHHC5T7KD ecYisN9tsb+AUGVweWySLjTaNC7aHJo=
Received: from BN8PR05CU002.outbound.protection.outlook.com (mail-eastus2azlp17011027.outbound.protection.outlook.com [40.93.12.27]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id usb-mta-3-59D1fT1lPeCGofZ91bf5ww-2; Tue, 27 Aug 2024 06:51:15 -0700
X-MC-Unique: 59D1fT1lPeCGofZ91bf5ww-2
Received: from PH0PR03MB6300.namprd03.prod.outlook.com (2603:10b6:510:e2::5) by DS7PR03MB5621.namprd03.prod.outlook.com (2603:10b6:5:2c8::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7897.25; Tue, 27 Aug 2024 13:51:11 +0000
Received: from PH0PR03MB6300.namprd03.prod.outlook.com ([fe80::a48b:db16:775a:4a16]) by PH0PR03MB6300.namprd03.prod.outlook.com ([fe80::a48b:db16:775a:4a16%5]) with mapi id 15.20.7897.021; Tue, 27 Aug 2024 13:51:10 +0000
From: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>
To: "adrian@olddog.co.uk" <adrian@olddog.co.uk>
Thread-Topic: [EXTERNAL] RE: A gap between Section 5 of RFC 4090 and Section 4.4.3 of RFC 3209
Thread-Index: Adr4U1YFTf9UCWGUQpCaeoSR+43jbQAKhm2AAAHUE0A=
Date: Tue, 27 Aug 2024 13:51:10 +0000
Message-ID: <PH0PR03MB63005F9F687C7DFF31252581F6942@PH0PR03MB6300.namprd03.prod.outlook.com>
References: <PH0PR03MB63007A1C71A9A11AF0AEF3C4F6942@PH0PR03MB6300.namprd03.prod.outlook.com> <098301daf87d$70971180$51c53480$@olddog.co.uk>
In-Reply-To: <098301daf87d$70971180$51c53480$@olddog.co.uk>
Accept-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: PH0PR03MB6300:EE_|DS7PR03MB5621:EE_
x-ms-office365-filtering-correlation-id: e7c9d482-ecf1-47af-d62b-08dcc69f4ef6
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|366016|376014|38070700018
x-microsoft-antispam-message-info: pI80MuJL3ptwNxutVvhNuKrPXffet8GjTuvhDMc2qFL+3ebw6GZ77kcwHjt2YMRFE4R/Vkxd5pQeOirYvG/3ZP3Ixa6CmST44XDbXPd1lNroaBcMEgcIAoQM0WumuXsZi1ulsqSJLz/4/xCDarY/JjUeqPMhyPBeDdtIvpfmHhQtyL359rhFNry1GqnDrGzGKzJcmGZc21AHLSLXsiDc+dEUmVG5cYZ46O81rQInHWIMI+0zb6X07YX9MRB7cdE7I5Qy1EgGHzfBA+3BXpDm6dMaBZzb+9EwJif1/68exA2GTLCGuXPQ6CfxRm8LBRTJ2qlr9AMSLMtx5yxn/pzYGCsc4s6RGnelqOA0K6iX7Wm+kuhCcIL2e5otcg7aNzWAU0CjRRhOdEXpykP29AWhoHI1IYM42JbaoajhhJ+iX9RzBnMrk0c2A6UmTPKvTE8QIWLxJHfBBgt0tihoJcj01JPqXEYFOJ2rGCXCgUQ5srTXfgRMr1TeiQoYlrwaN05RHL2uL9+QQFrz5VjkBKXfroYE9t4T9BBmdwwP4PCJVPw1eTp/5aeNLzNpH7v++4fS9fItwmOHAyIVCpmYCtKGy+GXcLYVJSVKFNhd+nG1IH6T0ttRRwQSfpprn1K0acdfzB8g320oP1Rv+b+v9GpFBTWtaXCo9NFkt3jwS1kFZGaFkwtKWF3tsVwZKWWO2Za+1Tte5ecJ7e5lOT8mY1NQlXE0CVrKJplkdCiXMFviuSDiLEstiYqHN3lKueTrRE8+Q3r0w9gNkeSd3E+9p7QwKkTBtWIo6iyY4QBQQAf5InK/14SypoOrlHhGHmL16HSDkqZdO6yXK2ns79QKzPPvW2c3IfzTmnnS6DTo47i7Jm8gvaKcVox9RWg1HPs4vtLAmlznCTSITqx+tv0syRNgNLn7E7mQ7V7L+Xe/SF7q6+eF4cVHDWXMbW8n6dEQ8Bwj3yyWFrm7B/IZ5GeM1Z+i3fNGTmUFGXx7r3Wjt0PilGDrU/URdCG/GleW2GPrDsVbJT93bRNRq9iRJh1SY4GTy/dskUlncxqmKQ7nPLyMeAspOvIwy7hM99jbmEH+rIRO1kiWmzSXfUbULGwyBBioMJ2MdMikBpYpM7ysR0ztEfnnjNbKIUBoSAaH4VpVhUwsKYM5pmAmF1+VlNKZrAXDtYNQRGEC88+M5antzIXGR3qTMbaa3WhtktHrCyaoN74wwrend46guvXSA9NJAlxleu5pGVnFyZsptO2fu8HD2hjq+QT5Ek5hJt3QMdUvq7z0fbFLeRV6nDjweNyeyrlAh9zEGmugegYWQIQFzE9JrxuY68Jb/jmtF75g02sI6M+MkbD83yLizeakd8XvGofeBPfzx0GwvZpBVNh7UxRvXTA=
x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PH0PR03MB6300.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(38070700018);DIR:OUT;SFP:1102
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: 7W181MKxqRRJUe3T00FsrbeZItuyS310E4Shz0pwy/iOPEUwxIwL/1rpnQlRnFlszuWTK7OXX7mC3e4scsjIsiOnm1C0E2ASGGYxEeddhptqrVXiv1qqDuB8i5Nph9RYiDUg24sHxWZGdeUx1AL2o3MRfqz6/piabO4Mvqn5Hn7KoKELYcxK91yWQGLHMExgxxDkA2dze+A8PYYPDDDAFCO9uGotv+/O/XPesH6QeYN5fyKUzaWxryV3trpOka3zpfb6g56/O7+JS4aOOK9qkCEdN7Bme/i+J3at8irG4Ifgbye/ZBA9ovkspoLeb1IW0M5wgHbIhYMyjoLSPU5dKSpRMqSLLGLWqejwjih5WjbOjaqIvO3eZt+3fFyyYEdNzSn0aOSu7/FsG6KG6jc8k09BJ+YiCdprk6bdlfvTJWO/eKVk8dc1OySA8Q/7NFLjr0wH5y/KK8FtGbCSWlNY697G1/rZSDdJZNZscIMotzDgJWoNIu7pdDt/G/KhTR7T1ua+FqxeXWHbbfCAR1Et5J+GlHmkYQ3zOTsEfaABVmqJeY7u4knPXdFY5uB/grHrJO77DoukslsQjZAEPPE8mp2SVuyvjx07b4cqCRJeMADc2YPKGBxfOBIbqcv3rT5zkQXx1lWusBpdJAn6zpudVWGSh7QKuYWFB2dr+UsBZldL8DL8WXf5OrKsskTUcY+QVUd+dD4D7DdztQdeoogBvU9G0iN4+r8+QilKTBzrG1PtdpNr9+qWboGNHTcZWF6r5bpVY2iyU3Xm82Cj2sCkFgGYgRrY5GyPIWXMMbil2Utsl25KlBcOaZByZmtsO2h5fNsypka5w96J/9bKfvP5H0JKhvNSlvBkrjAqAFdhiVrTGsdObOI/1YosYsqFEn+nACdkNlFYkAMkD9xJDwfw58TNA++peh5TxGphWw94QoWxSuefPX876hLnXQp/tBXYj3YJG4NCEL4go0ZN+meGu1//l7nwGhIsuirNx2CJ8FR3QcfLIQiqdG4LHHJMP0bxRoLt21iXt/+i4A3zCIEwDDYUpZOXgTe+c5Is4pcKWhnsDwzLxnxPT1KTLracSWktS8KIRQyCh2CkW3dq4SRDIkCDRNpMEE4R7P/m/Xn1ewTTRh2dhtMOkU8l0ajV4sbC9nW07eIehYqyLr6MlDCaVLXBxm3vRJO1uwu1SvcTE7kabOZjdDqlHVI7e3c5ZyWxMjpYAnFy0+ZMsnfSIr9U12lnO+KtK7FSYtNxF7i65ti3PfKCPeKAt/mhrl2m1f5UM8JmmLkovNmdtnPiCxjicq9yrBfNvzSLAhQ8UFRlUFk/x1XFnRurWf51hdmcahYPsP0JPJals6NTkB3xUVX7zyNKzx8VLItwK33DagJsvjJmLb54mHcLeOKj7k+D5C3hPhtOyqsjoOAiO+RHyXIj9866eTpUdl3SHHTYqwTqgnrhSUJyWWTpDP2n81ymEu1dU+LzWLi+miDyTQSeyA8BXTAmOs+BZ3MgYR6sIpbsCDkzgoCTGECNYKK81wlbtZR4ObkfjeSQSwfB8ju8m0z6Qq32e4ra2WFKGD1Pq+BqDEGuyWR+0qbrwLgWfdIHPwy6
MIME-Version: 1.0
X-OriginatorOrg: rbbn.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: PH0PR03MB6300.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: e7c9d482-ecf1-47af-d62b-08dcc69f4ef6
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Aug 2024 13:51:10.6485 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: LS1xrKmMr7z9m8EPDTSmAnzhv3z7K2tjB4dZXtsPusn13FC7Zan8FwTlCXlhqknq7HrQh4Gas6QUr47vm0Q8Cg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR03MB5621
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: rbbn.com
Content-Language: en-US
Content-Type: multipart/alternative; boundary="_000_PH0PR03MB63005F9F687C7DFF31252581F6942PH0PR03MB6300namp_"
Message-ID-Hash: RXMSRI5XOHPPFLNORQQO3V467RL7I3F6
X-Message-ID-Hash: RXMSRI5XOHPPFLNORQQO3V467RL7I3F6
X-MailFrom: alexander.vainshtein@rbbn.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-teas.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: "teas@ietf.org" <teas@ietf.org>, 'mpls' <mpls@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [Teas] Re: [EXTERNAL] RE: A gap between Section 5 of RFC 4090 and Section 4.4.3 of RFC 3209
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/SCHMDbD58uSBWkkbWpm1yX2Gn5s>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Owner: <mailto:teas-owner@ietf.org>
List-Post: <mailto:teas@ietf.org>
List-Subscribe: <mailto:teas-join@ietf.org>
List-Unsubscribe: <mailto:teas-leave@ietf.org>

Adrian,
Lots of thanks for a prompt and highly informative response.



The “specimen implementation” my colleagues and I have encountered sets the “label recording desired” flag without including the RRO in the Path message sent by the head-end node if setup of an RSVP-TE LSP with facility FRR is requested (which, as you say, is the case that requires inclusion of RRO in the Resv message).  And the same implementation in tail-end node includes an RRO in the Resv message it generates generated upon reception of such a Path message.  And, of course. it supports facility protection

I agree that non-usage of RRO in Path messages in this case may be inadvisable. But at the same time the “specimen implementation” in question is quite widely deployed and, AFAIK, has not been reported having interoperability issues.

So maybe this is not a gap between the two RFCs – but, rather, a gap between the RFCs and the de-facto industry reality?

So maybe relaxing the quoted text from Section 4.3.3 of RFC 3209 to something like “A received Path message without an RRO indicates that the sender node no longer needs route recording.  Subsequent Resv messages SHALL SHOULD NOT contain an RRO unless its inclusion is required for some specific purpose” would align the standards with the de-facto situation in the industry?

My 2c
Sasha

From: Adrian Farrel <adrian@olddog.co.uk>
Sent: Tuesday, August 27, 2024 3:34 PM
To: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>; 'mpls' <mpls@ietf.org>
Cc: teas@ietf.org
Subject: [EXTERNAL] RE: A gap between Section 5 of RFC 4090 and Section 4.4.3 of RFC 3209

Good afternoon, Sasha.

How does your specimen implementation set the “label recording desired” flag?

It was long ago, but I think the flag requests labels to be recorded in the RRO. It would be hard to include such labels without including an RRO. But I see in 3209 4.4.3…

   When the Label_Recording flag is set in the SESSION_ATTRIBUTE object,
   nodes doing route recording SHOULD include a Label Record subobject.
   If the node is using a global label space, then it SHOULD set the
   Global Label flag.

I see that as saying that non-use of RRO wins over Label_Recording flag. In other words, a node that decides to not initiate route recording leaves out the RRO on the Path message and how it sets the Label_Recording flag is then irrelevant.

I’d note that, while non-use of RRO in FRR might be inadvisable, it is not mandatory. True, you can’t do facility backup without it, but that doesn’t make it mandatory. Indeed, 4090 section 6…
   The following treatment for the RRO IPv4 or IPv6 sub-object's flags
   must be followed if an RRO is included in the protected LSP's RESV
   message.
…makes it clear that the use of RRO is not a requirement.

My conclusion, therefore, is that there is no hole to be filled.
Agreed, it is odd to set the Label_Recording flag and then not include an RRO. But there is nothing broken.

Cheers,
Adrian

From: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com<mailto:Alexander.Vainshtein@rbbn.com>>
Sent: 27 August 2024 11:39
To: mpls <mpls@ietf.org<mailto:mpls@ietf.org>>
Cc: adrian@olddog.co.uk<mailto:adrian@olddog.co.uk>; teas@ietf.org<mailto:teas@ietf.org>
Subject: A gap between Section 5 of RFC 4090 and Section 4.4.3 of RFC 3209

Hi all,
I would like to share with you what I see as a gap between Section 5 of RFC 4090<https://datatracker.ietf.org/doc/html/rfc4090#section-5> and Section 4.4.3 of RFC 3209<https://datatracker.ietf.org/doc/html/rfc3209#section-4.4.3>:


  1.  The former states that “ The head-end LSR of a protected LSP MUST set the "label recording desired" flag in the SESSION_ATTRIBUTE object.”

a.      Label recording uses Label subojects of the Record Route Object (RRO), so that this statement implies usage of RRO at least in the Resv messages used for signaling a protected LSP

b.      However, inclusion of RRO in the Path messages used for signaling a protected LSP by the head-end is not mentioned at all

2.      The last para of the latter states that “A received Path message without an RRO indicates that the sender node no longer needs route recording.  Subsequent Resv messages SHALL NOT contain an RRO.”

We have encountered a widely deployed implementation that does not include RRO in the Path messages generated by the head-end LSR of protected LSRs but includes RRO (with Label subobjects) in the Resv messages generated in response to this Path messages.

I wonder whether an Erratum describing the gap between the two RFCs should be filed, or some other action should be taken to resolve the observed contradiction.

I would highly appreciated any feedback on the subject.

Regards, and lots of thanks in advance,
Sasha



Disclaimer

This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments.