[mpls] 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 12:34 UTC
Return-Path: <adrian@olddog.co.uk>
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 095A2C14F6EC; Tue, 27 Aug 2024 05:34:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.106
X-Spam-Level:
X-Spam-Status: No, score=-7.106 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_HI=-5, 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=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 QxPhaId8beHl; Tue, 27 Aug 2024 05:34:24 -0700 (PDT)
Received: from mta5.iomartmail.com (mta5.iomartmail.com [62.128.193.155]) (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 50E8AC14F6E3; Tue, 27 Aug 2024 05:34:22 -0700 (PDT)
Received: from vs3.iomartmail.com (vs3.iomartmail.com [10.12.10.124]) by mta5.iomartmail.com (8.14.7/8.14.7) with ESMTP id 47RCYK0G015614; Tue, 27 Aug 2024 13:34:20 +0100
Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 0E1CD4604B; Tue, 27 Aug 2024 13:34:20 +0100 (BST)
Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 011AD4604A; Tue, 27 Aug 2024 13:34:20 +0100 (BST)
Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs3.iomartmail.com (Postfix) with ESMTPS; Tue, 27 Aug 2024 13:34:19 +0100 (BST)
Received: from LAPTOPK7AS653V (82-69-109-75.dsl.in-addr.zen.co.uk [82.69.109.75]) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.7/8.14.7) with ESMTP id 47RCYJ8M018455 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 27 Aug 2024 13:34:19 +0100
From: Adrian Farrel <adrian@olddog.co.uk>
To: 'Alexander Vainshtein' <Alexander.Vainshtein@rbbn.com>, 'mpls' <mpls@ietf.org>
References: <PH0PR03MB63007A1C71A9A11AF0AEF3C4F6942@PH0PR03MB6300.namprd03.prod.outlook.com>
In-Reply-To: <PH0PR03MB63007A1C71A9A11AF0AEF3C4F6942@PH0PR03MB6300.namprd03.prod.outlook.com>
Date: Tue, 27 Aug 2024 13:34:19 +0100
Organization: Old Dog Consulting
Message-ID: <098301daf87d$70971180$51c53480$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0984_01DAF885.D25C3CD0"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQIwToMu9Bmbnsde0EHAnDo9coO4LrGQQ9SQ
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=Tp2wA8ZmNqYb3ZiL0p/CC qqQBuA9y7BU4nBT+4/3YqQ=; b=HAyQJA8+igwuAJX6lSxgF7a19yNRbrvMb9aw0 DVzNXjb5NrR4DGVgYz/1N6smFsIRuNeiW6xb/RmEfeLCzuVuowGMp4iVJlNlSRH2 bk8IZO1p9O4D8e1qllTwJT/aXw1rLxu7mCH+8ZMIHfMFoOq+bhp2kmSuG3C1RZzm Ceva+ZkB7TcSqRc006nuCxgrryapX4tcDg1CsBKamGs1kZ6htulXpO2Izf/4+0i6 ZQXm4LF4tHqAKmPjAlSvV/a4psSWnYfiyd9hQxp5FFem/yRqmD9Bn8ml3RcTJ5BD J9zwxr+Iw5MdO8q4QxUzrTvlpWd4WM/kcUETjMbXWHNYgaKNw==
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--36.488-10.0-31-10
X-imss-scan-details: No--36.488-10.0-31-10
X-TMASE-Version: IMSVA-9.1.0.2090-9.0.1002-28352.003
X-TMASE-Result: 10--36.488300-10.000000
X-TMASE-MatchedRID: Z/tjqhsgM6c7iuZ/mdYYtrlNLzKnFXx/QbNTsIpfWx2tz154mxLnXJW3 mL+rnGfa2WURF1LpXi6hLSC6hXpJlwV54COoxb6XgQF5fS5D6eljZf1Uyfo76Rd5fJCEyHUvnDq RJLX0AJ5+fOZykHM6u65bb5QEYSkd8nuBtG35YKvMtotGtpF5VlAKyZ8B6Bt0/ReYKQf/E1I40w irq0mM9a3GFfJOpzTZF+qQpCWTUjn4qCLIu0mtIC3euai/vqCsxJ+7THN9m2g5DMj/FS1NXMqiL um2WvWcsowoC5zjVCMZokyW9/FkXj4v6osTIVnV0O/0pIyJ31FMFVBACA+ZEzKS0PX944b/K9qy WhOZsO9wZYiakM33/I61Z+HJnvsOJp0Oa6+L6ZvhEY4rS+ELKyJ1YT6M2y/pZvd/++YdzCeOSe0 doWeIWAJW+jkd+3/uE7sLdRVaGmffVqwz+CynaZ0oD5Lw3bToEqSmDx1CZ0qQiUqgvBUFUDwNak GbUKNlOY0uFdPXUM5SAphtkUXoaLzutTz14s8pusQJNrQf70w4KPKQxy+E/gvBPGQoLW6lDWo1/ vBF88XM0QPdYuYm98PDPFi81d1AohrMq0nEhQf5q5JB+ib2QT/bl4B9hyYe5xfUagMOILAbShpH N0FKWhS3v3B/YnypOYqUl58EXDO4oAbg4yXJ/44fFueSeIindeqErkVhgOkSW2ZMFgOR2Ah6TX2 bzUHm5FmazwMilg8ZS5uxXPxN6a7tzl8n4dIA7Y358uT9xuVxgSwnlE2iS+s4QSG+GkxnujOPKT RawmDq3WC5KhDhQw5fRf2Xqs+kfS0Ip2eEHnyvXSmSdlcYmrLn+0Vm71LcGt7mdu4lvE4/3GZ+d Hsx6otkBWmEtb9tqxB32o9eGcn/ita+mP1RyAP90fJP9eHt
X-TMASE-SNAP-Result: 1.821001.0001-0-1-22:0,33:0,34:0-0
Message-ID-Hash: UT22EMKY7T7ACLRMCK6MYXPPY6ONV4IK
X-Message-ID-Hash: UT22EMKY7T7ACLRMCK6MYXPPY6ONV4IK
X-MailFrom: adrian@olddog.co.uk
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: teas@ietf.org
X-Mailman-Version: 3.3.9rc4
Precedence: list
Reply-To: adrian@olddog.co.uk
Subject: [mpls] Re: A gap between Section 5 of RFC 4090 and Section 4.4.3 of RFC 3209
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/snoroQ1j_Ty72RwCpVlLzvR7beQ>
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>
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> Sent: 27 August 2024 11:39 To: mpls <mpls@ietf.org> Cc: adrian@olddog.co.uk; 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.
- [mpls] A gap between Section 5 of RFC 4090 and Se… Alexander Vainshtein
- [mpls] Re: A gap between Section 5 of RFC 4090 an… Adrian Farrel
- [mpls] Re: [EXTERNAL] RE: A gap between Section 5… Alexander Vainshtein
- [mpls] Re: [Teas] A gap between Section 5 of RFC … Vishnu Pavan Beeram
- [mpls] Re: [EXTERNAL] RE: A gap between Section 5… Vishnu Pavan Beeram
- [mpls] Re: [EXTERNAL] Re: [Teas] A gap between Se… Alexander Vainshtein
- [mpls] Re: [EXTERNAL] RE: A gap between Section 5… Adrian Farrel
- [mpls] Re: [Teas] Re: [EXTERNAL] RE: A gap betwee… Vishnu Pavan Beeram
- [mpls] Re: [EXTERNAL] Re: [Teas] A gap between Se… Vishnu Pavan Beeram
- [mpls] Re: [EXTERNAL] RE: A gap between Section 5… Alexander Vainshtein