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

Adrian Farrel <adrian@olddog.co.uk> Tue, 27 August 2024 20:02 UTC

Return-Path: <adrian@olddog.co.uk>
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 32835C1840DA; Tue, 27 Aug 2024 13:02:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.102
X-Spam-Level:
X-Spam-Status: No, score=-2.102 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_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=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_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=olddog.co.uk
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 Gnkko0xHcukI; Tue, 27 Aug 2024 13:02:10 -0700 (PDT)
Received: from mta6.iomartmail.com (mta6.iomartmail.com [62.128.193.156]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E5F2C14F6A3; Tue, 27 Aug 2024 13:02:06 -0700 (PDT)
Received: from vs1.iomartmail.com (vs1.iomartmail.com [10.12.10.121]) by mta6.iomartmail.com (8.14.7/8.14.7) with ESMTP id 47RK24nS013131; Tue, 27 Aug 2024 21:02:04 +0100
Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id F2B704604B; Tue, 27 Aug 2024 21:02:03 +0100 (BST)
Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id D37A44603D; Tue, 27 Aug 2024 21:02:03 +0100 (BST)
Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs1.iomartmail.com (Postfix) with ESMTPS; Tue, 27 Aug 2024 21:02:03 +0100 (BST)
Received: from LAPTOPK7AS653V (82-69-109-75.dsl.in-addr.zen.co.uk [82.69.109.75]) (authenticated bits=0) by asmtp3.iomartmail.com (8.14.7/8.14.7) with ESMTP id 47RK2310022242 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 27 Aug 2024 21:02:03 +0100
From: Adrian Farrel <adrian@olddog.co.uk>
To: 'Alexander Vainshtein' <Alexander.Vainshtein@rbbn.com>
References: <PH0PR03MB63007A1C71A9A11AF0AEF3C4F6942@PH0PR03MB6300.namprd03.prod.outlook.com> <098301daf87d$70971180$51c53480$@olddog.co.uk> <PH0PR03MB63005F9F687C7DFF31252581F6942@PH0PR03MB6300.namprd03.prod.outlook.com>
In-Reply-To: <PH0PR03MB63005F9F687C7DFF31252581F6942@PH0PR03MB6300.namprd03.prod.outlook.com>
Date: Tue, 27 Aug 2024 21:02:04 +0100
Organization: Old Dog Consulting
Message-ID: <09ef01daf8bb$fd095130$f71bf390$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_09F0_01DAF8C4.5ECF18C0"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQIwToMu9Bmbnsde0EHAnDo9coO4LgHkArpxAu/RFhWxajkukA==
Content-Language: en-gb
X-Originating-IP: 82.69.109.75
X-Thinkmail-Auth: adrian@olddog.co.uk
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=olddog.co.uk; h=reply-to :from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type; s=20221128; bh=pEHcXpdqbq4KCSlpWhEMV 1kk/vp0Kmq/jjC1cxDMYSY=; b=vymYNDiQk73I9H+fiCN1t+9XF4b0nq21sKDP/ e7yJPQdc7LpUM5i6KGaugmR/6GdETxCwyEIJzA6NJAcrSSyNsSKdXcSx6su3N7Tz sUaGLKv7dFVrHHyNP4SOaK5EbX0JPQ3tsg9rjAGpgEz12FIqgAKbgB4Jf2mA/X3p Un1tb9S2EQeMpoGMOqW9dhXqIdkDgQ38GjO8PAbE+NFMBfLCPgaSuxuGb6bQzMIL t5+9ONybWpWdah6QpVsrBCTUdokTT0uOglq5JQjoxbc5USLOfppvqk1Lzof38Rv5 NkcAnSY2WOZ94RqvnONcomTbawh67GL5rebZKTJbQBOXkPJnQ==
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.1.0.2090-9.0.0.1002-28352.003
X-TM-AS-Result: No--26.947-10.0-31-10
X-imss-scan-details: No--26.947-10.0-31-10
X-TMASE-Version: IMSVA-9.1.0.2090-9.0.1002-28352.003
X-TMASE-Result: 10--26.947000-10.000000
X-TMASE-MatchedRID: OoEa6u7Uk5/uYusHgJkgyhK8RjA2ODb72jiD9m+mX1/FDSC+KsmSUJxW n6dtA5GQ0aUWy+2I8Yfzne+DXzqJZSrLqyE6Ur/jdmWMDQajOiIZRMY3EvICKlYWGY8tbKb+eST FYWBXCdghtmCyHbvSzy058wNrEnf/OIQ9GP2P2u8IKj6WwO7KdT+B/tp8itBT29IGmYEBMmrfwn Szp7o5lp7nIUt1j4g8f7OyDqSnYLd7TXnCjI8t9kfLPdsHmQbn4Y6kI/Ug2+dYqgMpOy5G5OqB7 /rwwa8NtpHRAqTqrQ13dXZvIJVkUPZNLVgVojn/tOtXYgbXjdeq5EfSA5z3P4Z+yLx9W9ZB+PID Jm8nMt3DO+xbEI/WFnh1rPkUeh+7Va38YBvXGZy2RKeLHaEMv1izGk5+r6eTZUQomC0LkMs5DMj /FS1NXFT79/1KCh97IP8FCMT2kvCIf3m0sUfx5ye0wHaFmKTn1lVq1QPvPgnePrdhC8Q7LwkC2o tz3ZOAnDqRJLX0AJ5A3pPQZ4eO05wzEulNiZLqMzbF1gbxlQZy1m52x4c9LRU3JTQCzWNHlJXBv k7vV7+QeRYo89LWxHm71hoAj4FEraHfnS9hi2VK0YCCYqpa5e8n6d5wLKiXPoMWqeYk+aV4QDWo RVUbQAMTrxPQzhSPLT5n6hcv+PdBDn6Fjq77jjoSfZud5+GgpKG9GN+fhxSf7y5OBAioaDba6gS bbjl+iONMOkcrBiaHO/kG/PtN6fx0ykrbAxjCv3d9ewcMHQcDLr9vPVWwiIVwK/oeBn0wt88u+p DQws6bVVXilP6Qq/CDFvXZFmYyYeSLiGsUzvl9LQinZ4QefK9dKZJ2Vxiasuf7RWbvUtwa3uZ27 iW8Tj/cZn50ezHqi2QFaYS1v22rEHfaj14Zyf+K1r6Y/VHIA/3R8k/14e0=
X-TMASE-SNAP-Result: 1.821001.0001-0-1-22:0,33:0,34:0-0
Message-ID-Hash: XF3Y5V55TLNALXXACKQEJAHDUPOTJFZR
X-Message-ID-Hash: XF3Y5V55TLNALXXACKQEJAHDUPOTJFZR
X-MailFrom: adrian@olddog.co.uk
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, 'mpls' <mpls@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Reply-To: adrian@olddog.co.uk
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/Jwu-PmW8e8Q_hA4uYMGBryk1ucU>
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>

OK. Sorry. Got you.

 

There are two issues, as I see it.

 

The first is that, in sending an RRO in a RESV when the corresponding PATH did not contain an RRO, the egress is in technical violation of 4.3.3 of 3209.

I agree that SHOULD NOT would fix this, and I think it would be better in any case because, as far as I am aware, egress implementations often consider it wise to include an RRO unless they have seen a RESVerr telling them that there is some problem propagating a RESV with an RRO.

 

However:

1.	You can’t do this with an Erratum. It is making a substantiative change to the technical content, not fixing the document to reflect what the authors originally intended but accidentally miswrote.
2.	I am not sure that this matter much. I don’t believe an implementation that does not include RRO in a PATH will have a problem with receiving one in an RRO. In fact, it probably should expect to given the possible race conditions when it moves from including RRO in PATH to no longer including RRO in PATH.
3.	It would be against the Postel Principle for an implementation to ever object to receiving a RESV on an RRO.

 

The second issue is that, when receiving a PATH without an RRO, an egress may attempt to conform to 4.3.3 of 3209 and so prevent the operation of certain FRR features (namely facility backup). There is a choice to be made here:

a.	Have the feature fail and blame the ingress that did not include an RRO in its PATH. Get that implementation fixed.
b.	Fix the egress implementation to act as in the first issue (i.e., send an RRO in the RESV regardless).
c.	Fix 4090 to say that when FRR is being done, the RRO MAY be present in the RESV regardless of the absence of RRO in the PATH. Note, however, that this also not something you can do with an Erratum.

 

Cheers,

Adrian

 

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

 

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 <mailto:adrian@olddog.co.uk> > 
Sent: Tuesday, August 27, 2024 3:34 PM
To: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com <mailto:Alexander.Vainshtein@rbbn.com> >; 'mpls' <mpls@ietf.org <mailto:mpls@ietf.org> >
Cc: teas@ietf.org <mailto: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.