Return-Path: 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" To: "'Alexander Vainshtein'" , "'mpls'" References: In-Reply-To: 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: =?utf-8?q?=5Bmpls=5D_Re=3A_A_gap_between_Section_5_of_RFC_4090_and_Section_4?= =?utf-8?q?=2E4=2E3_of_RFC_3209?= List-Id: Multi-Protocol Label Switching WG Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: This is a multipart message in MIME format. ------=_NextPart_000_0984_01DAF885.D25C3CD0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Good afternoon, Sasha. =20 How does your specimen implementation set the =E2=80=9Clabel recording = desired=E2=80=9D flag? =20 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=E2=80=A6 =20 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. =20 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. =20 I=E2=80=99d note that, while non-use of RRO in FRR might be inadvisable, = it is not mandatory. True, you can=E2=80=99t do facility backup without = it, but that doesn=E2=80=99t make it mandatory. Indeed, 4090 section = 6=E2=80=A6 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. =20 =E2=80=A6makes it clear that the use of RRO is not a requirement. =20 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. =20 Cheers, Adrian =20 From: Alexander Vainshtein =20 Sent: 27 August 2024 11:39 To: mpls 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 =20 Hi all, I would like to share with you what I see as a gap between Section 5 of = RFC 4090 and = Section 4.4.3 of RFC 3209 = : =20 1. The former states that =E2=80=9C The head-end LSR of a protected LSP = MUST set the "label recording desired" flag in the SESSION_ATTRIBUTE = object.=E2=80=9D 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 =E2=80=9CA received Path = message without an RRO indicates that the sender node no longer needs = route recording. Subsequent Resv messages SHALL NOT contain an = RRO.=E2=80=9D =20 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. =20 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. =20 I would highly appreciated any feedback on the subject. =20 Regards, and lots of thanks in advance, Sasha =20 =20 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.=20 ------=_NextPart_000_0984_01DAF885.D25C3CD0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Goo= d afternoon, Sasha.

 

How= does your specimen implementation set the =E2=80=9Clabel recording = desired=E2=80=9D 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=E2=80=A6

 

=C2=A0=C2=A0 When the Label_Recording = flag is set in the SESSION_ATTRIBUTE object,

=C2=A0=C2=A0 nodes doing route = recording SHOULD include a Label Record = subobject.

=C2=A0=C2=A0 If the node is using a = global label space, then it SHOULD set the

=C2=A0=C2=A0 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=E2= =80=99d note that, while non-use of RRO in FRR might be inadvisable, it = is not mandatory. True, you can=E2=80=99t do facility backup without it, = but that doesn=E2=80=99t make it mandatory. Indeed, 4090 section = 6=E2=80=A6

=C2=A0=C2=A0 The following treatment = for the RRO IPv4 or IPv6 sub-object's flags

=C2=A0=C2=A0 must be followed if an RRO = is included in the protected LSP's RESV

=C2=A0=C2=A0 message.=C2=A0 =

=E2= =80=A6makes it clear that the use of RRO is not a = requirement.

 

My = conclusion, therefore, is that there is no hole to be = filled.

Agr= eed, it is odd to set the Label_Recording flag and then not include an = RRO. But there is nothing broken.

 

Che= ers,

Adr= ian

 

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 and Sect= ion 4.4.3 of RFC 3209:

 

  1. The = former states that =E2=80=9C The head-end LSR of = a protected LSP MUST set the "label recording desired" flag in = the SESSION_ATTRIBUTE object.=E2=80=9D
    1. 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
    2. 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 =E2=80=9CA received Path = message without an RRO indicates that the sender node no longer needs = route recording.  Subsequent Resv messages SHALL NOT contain an = RRO.=E2=80=9D

 

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. =

------=_NextPart_000_0984_01DAF885.D25C3CD0--