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

Vishnu Pavan Beeram <vishnupavan@gmail.com> Wed, 28 August 2024 04:55 UTC

Return-Path: <vishnupavan@gmail.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 83AD8C157937; Tue, 27 Aug 2024 21:55:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=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=gmail.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 NBuoZzXJR_WV; Tue, 27 Aug 2024 21:55:07 -0700 (PDT)
Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com [IPv6:2607:f8b0:4864:20::434]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73993C15108A; Tue, 27 Aug 2024 21:55:07 -0700 (PDT)
Received: by mail-pf1-x434.google.com with SMTP id d2e1a72fcca58-71446fefddfso3566531b3a.0; Tue, 27 Aug 2024 21:55:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1724820907; x=1725425707; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Vvm/dKFWTVHUxNVEdUZd427GaARAq9yhGZ7xW02pZSw=; b=ASD7thOkcipJ2suLYR+3JCmBFEkqPhXs+nX1jUOXltLglxTFdy+SNGVrbjqsNedgD0 KDrXea3pIqtehvXR6YwA4VOgByxpj/QxSsCVu7atUyjQnbU43QHKj4j+1uC1eKi360Q1 fzrGBZ3OdGgV+FruNclGaFzIH4OZmeX5+Uimgha2CePXyKJPHm0zWrMBUeet0V3feFcH KHhH+oYFxEuskhlEOgXnPWO3ky7rMCaEnzAGiX0gFmTan2hoEO/IkQTyFwa4M3EPukcb 4AJQyuONu7YWigNZz5kGkxucUWY/a3dyj4rOhRIqmRHlucJQSUkE8JNWNek6l6cCYrzj BjpQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724820907; x=1725425707; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Vvm/dKFWTVHUxNVEdUZd427GaARAq9yhGZ7xW02pZSw=; b=gHLdrEM/JvuYVF6EO22QqMWbjPX2s6hpoMumA+pXlS9ocATT9jHFdzMaLxr7fLJ2nG 7526sf+HCrpSLl66doO3w0bJDMlH0pHzZo7vW545mM3HmoRJSJNargNiWPzbCahz5sDC V+G/mJO22d+1pXxKKp4gs2w53DjH2UjzoQUXS+ebJt1jqKPMiUbNxtCzahQE0KA/p6UL XvQH6UNtvvGVx9wgC+TC2YfHuBcOUXld90aJK1WsoJPXQ5euck+49+hYLCRPMzuhe3go WG/GdOnmRSK+xSxYIgXYtuCNYLlt6+dIZQ3zw6ir8ODMITA5wGqIW6gVD2Fg+0i0AEV2 AvBQ==
X-Forwarded-Encrypted: i=1; AJvYcCW/FG3P/M2t6jyevKRgn42Gm0xOeQEvxfsD0/fVhADTXXi+ektNY6vxEzoN7Nai1AVDUmAgmA==@ietf.org, AJvYcCWmNkVp4t+8ZQWCZLJU4bXUU+P5vn27/0bnPNWgXTlm2rHXKuov5ahHA3Rjh0cZEkOp2Z+3@ietf.org
X-Gm-Message-State: AOJu0Yz7wuuFGHBmnUpCSGCTQRdG4k68oXlmPDA/5gBvtcKIsUx4nAmx 9xX0weH/XAf4XLyDJ9xD0sz2FKS9ipkj3aut/6XUulmeRS6Bd7bnxeUsGcDwP1ZNorjjChmdFYf iZVMAPO8OLsv84te28Oa4+H5tOgk=
X-Google-Smtp-Source: AGHT+IE2+CItRqNlOgBsipTQ5l5H/Mg/BA5F8V18y525YLfiMDGnzTqhZHiYkLwLeW94csiMBt+HFFJG74d6NmM3I+s=
X-Received: by 2002:a05:6300:42:b0:1c4:9ce8:e6ca with SMTP id adf61e73a8af0-1cc8a089fe3mr16557645637.54.1724820906703; Tue, 27 Aug 2024 21:55:06 -0700 (PDT)
MIME-Version: 1.0
References: <PH0PR03MB63007A1C71A9A11AF0AEF3C4F6942@PH0PR03MB6300.namprd03.prod.outlook.com> <098301daf87d$70971180$51c53480$@olddog.co.uk> <PH0PR03MB63005F9F687C7DFF31252581F6942@PH0PR03MB6300.namprd03.prod.outlook.com> <09ef01daf8bb$fd095130$f71bf390$@olddog.co.uk>
In-Reply-To: <09ef01daf8bb$fd095130$f71bf390$@olddog.co.uk>
From: Vishnu Pavan Beeram <vishnupavan@gmail.com>
Date: Wed, 28 Aug 2024 10:24:54 +0530
Message-ID: <CA+YzgTs2-5qaWpXb-iM14V0TYHj69Rpg1+oKTgbQ16LN+Kib9Q@mail.gmail.com>
To: adrian@olddog.co.uk
Content-Type: multipart/alternative; boundary="0000000000007203470620b72916"
Message-ID-Hash: QVDET3ES6NKUBHRW4E3WR3EQAERFFBTQ
X-Message-ID-Hash: QVDET3ES6NKUBHRW4E3WR3EQAERFFBTQ
X-MailFrom: vishnupavan@gmail.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: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>, 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/8_8PzeeI_Fak1aq5FXx7A_5967k>
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>

Please see inline (prefixed VPB)

Regards,
-Pavan

On Wed, Aug 28, 2024 at 1:32 AM Adrian Farrel <adrian@olddog.co.uk> wrote:

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

[VPB] Allowing the egress to add the RRO in the RESV when there is no RRO
in the PATH takes away the flexibility of having the ingress control "route
recording" along the PATH. If we have to allow this, we may also want to
consider introducing an LSP-ATTRIBUTE flag in the PATH for explicitly
triggering "Route Recording in the RESV".


>
>
> 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.
>
>
[VPB] Agree.


>
> 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:
>
>    1. Have the feature fail and blame the ingress that did not include an
>    RRO in its PATH. Get that implementation fixed.
>    2. Fix the egress implementation to act as in the first issue (i.e.,
>    send an RRO in the RESV regardless).
>    3. 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.
>
>
[VPB] IMHO, "a" seems quite reasonable. "b" penalizes implementations that
are already RFC3209-complaint. And I don't see a strong reason to push for
"c".

[VPB] If we do decide to spend some cycles revisiting these procedures, I
would rather look into providing an option to seek "mandatory"
Route-Recording/Local-Protection/Label Recording/<other-relevant session
attribute flags> (can be easily done by using LSP_REQUIRED_ATTRUBUTES) --
this would ensure tightening the existing procedures.



>
>
> 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>
> *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>
> *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.
> _______________________________________________
> Teas mailing list -- teas@ietf.org
> To unsubscribe send an email to teas-leave@ietf.org
>