[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:17 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 0D280C19ECB9; Tue, 27 Aug 2024 21:17:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.105
X-Spam-Level:
X-Spam-Status: No, score=-7.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, 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=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 TqKGYUwLXW2l; Tue, 27 Aug 2024 21:17:00 -0700 (PDT)
Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) (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 200C8C18DBBB; Tue, 27 Aug 2024 21:17:00 -0700 (PDT)
Received: by mail-pl1-x632.google.com with SMTP id d9443c01a7336-20223b5c1c0so57130815ad.2; Tue, 27 Aug 2024 21:17:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1724818619; x=1725423419; 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=QnOrltNoyEo1TZT+FN6Xk3wCks6eS0+qb7c33S1bV1U=; b=CBk2RNNp8terfVf1MIzoDeBJydSilBxDXBjs8xghaURKCuL2HaH5/JvPdUMAzzDx+9 NZLquZPJ9+6SS7piCwLnyCB4LJA1ng9IEH3EbNl4UF4H5LCSRk+JirxB+KPm+SDNJokA uIlISA6VS2HfYdm6QzXLWg2Sx5AgQi1ak6RPFCXHyAPJgPXtk3ES7oaYuDnr2EfOgmWT ON97DoNijIjDip+Vq8eMVqMw6gM3M9RbuqktWG5MaRQ+QTJlc06DaB/aUJ83sAdlLVP5 Sz9ANlknzJXnIqnJS7lkZQOxy3YmvVCBqL3GU5NwAmP+HaC/1ds3pxBTeAnTiXfAdsO0 eDiQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724818619; x=1725423419; 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=QnOrltNoyEo1TZT+FN6Xk3wCks6eS0+qb7c33S1bV1U=; b=VFa107kNRvxG/LpJL67SficAkqf6bRaJ0Ga/QF1MbW0DSG3VyPSDNaT414xLlAbnnu ZuMCujkMbBf1vJZC2L3sRAlPPcRiImdpvF7Lhi12GThlH7VeykfNyFg05urSPGGogQkA Kf4cW9dfYsLdBsa68t5GAjeiOxGbrJKW9rJhERUB12ON0K0Mj5dplCMV7RXoVTy9pBOa rFK7ehIpDV4hNyx4V5DM8afp7JEpyEwNBV7934AiUbLMdeYQW1SZT/8omggp4Uo7ViTS ibCwmfbrowo+K/XZgnTHCoXBE2kGUw4QW8uMW0hR90jnEgtnFDpR0FHo9PqEOtE32v3V fklw==
X-Forwarded-Encrypted: i=1; AJvYcCWKFviHP1RtH/6Ss+phZpcCI7TkskeiLZkjel0IlVaEiXO893yp4qE29TH50YheSDII65au@ietf.org
X-Gm-Message-State: AOJu0YxIE+4b8yQ93iSt3MCCy6Ht+3b3Cde2ViiEEP7It+PKl2Mge6T7 tJJ05xvbgIhhEwiW/kDZ0baFqhcT1mEyUryJg1gU/X5s/3N0sMwVy9e5/mQGlRx1s/pvzVGnfdh pDGgj3dOIHT4sCy5sJjsED8ZuzP0=
X-Google-Smtp-Source: AGHT+IHJIpGcrwT4SyBlYd83bpAV97Dugei6sf24pB2HIMZbxRtjvUHItNndUr6n/ZGQLPSNvQvbPWBikAIWedfDlA4=
X-Received: by 2002:a17:90a:c788:b0:2d3:cd22:e67b with SMTP id 98e67ed59e1d1-2d8440af8camr827061a91.6.1724818619112; Tue, 27 Aug 2024 21:16:59 -0700 (PDT)
MIME-Version: 1.0
References: <PH0PR03MB63007A1C71A9A11AF0AEF3C4F6942@PH0PR03MB6300.namprd03.prod.outlook.com> <CA+YzgTtw-Z-qPzsz_GY0P=vboXvneEgCja98w38fTH8fPgUqAw@mail.gmail.com> <PH0PR03MB630090912EC2C5D68AC976ABF6942@PH0PR03MB6300.namprd03.prod.outlook.com>
In-Reply-To: <PH0PR03MB630090912EC2C5D68AC976ABF6942@PH0PR03MB6300.namprd03.prod.outlook.com>
From: Vishnu Pavan Beeram <vishnupavan@gmail.com>
Date: Wed, 28 Aug 2024 09:46:47 +0530
Message-ID: <CA+YzgTvyvOaU=S4HYjJmd9Tjjm66UtQcD2=1z03iXP3TWA8nbQ@mail.gmail.com>
To: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>
Content-Type: multipart/alternative; boundary="0000000000001825d00620b6a11e"
Message-ID-Hash: UD2K3MEAUAZKSHMJQBJLJSRRPG3H22RP
X-Message-ID-Hash: UD2K3MEAUAZKSHMJQBJLJSRRPG3H22RP
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: mpls <mpls@ietf.org>, "adrian@olddog.co.uk" <adrian@olddog.co.uk>, "teas@ietf.org" <teas@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/xJwB9XUyUfGd0IicPuEzFZBxOqA>
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 [Pavan] for responses.

Regards,
-Pavan

On Tue, Aug 27, 2024 at 8:27 PM Alexander Vainshtein <
Alexander.Vainshtein@rbbn.com> wrote:

> Pavan hi!
>
>
>
> Quoting from RFC 2119 <https://datatracker.ietf.org/doc/html/rfc2119>:
>
>
>
> *2 <https://datatracker.ietf.org/doc/html/rfc2119#section-2>. MUST NOT  * This
> phrase, or the phrase "SHALL NOT", mean that the
>
>    definition is an absolute prohibition of the specification.
>
> The last para in Section 4.4.3 of RFC 3209 uses the phrase “SHALL NOT”,
> i.e. , it expresses an absolute prohibition for the tail-end node to
> include RRO in the Resv messages generated in response to reception of Path
> messages without RRO.
>
>
>
> As you have said, you are “aware of tail-end LSR implementations that are
> “strict” about this”  - but then there is at least one widely deployed
> implementation that behaves differently.
>
> I wonder whether interoperability between a “strict” implementation and a
> “violating” one has even been tested.
>

[Pavan] Please feel free to unicast me details of the specimen
implementation and I can help determine if interoperability was ever tested
between the two implementations.


>
>
> I also think that keeping both 3209 and 4090 unchanged actually results in
> a somewhat problematic situation:
>
>    - The head-end node requests facility protection and, therefore, sets
>    the Label Record Desired flag, but does not include the RRO in its Path
>    message
>    - The “strict” tail-end node does not include the RRO in its RESV
>    message
>    - As a consequence, facility protection is not provided – but the
>    head-end node remains unaware of this fact.
>
>
[Pavan] The absence of the RRO in the RESV message can be used by the
head-end node to discern that facility protection was not catered to by the
PLRs along the path of the LSP.

Of course, we can say that IETF does not care about implementations that
> explicitly violate the standard – but personally I doubt IETF can force
> operators to drop a non-compliant implementation that, AFAIK, has been
> widely deployed for years.
>
>
>
> IMHO and FWIW replacing “SHALL NOT” with “SHOULD NOT” in Section 4.4.3 of
> RFC 3209 (possibly with some text about possible reasons to ignore this
> recommendation) would be the simplest way out of this situation.
>

[Pavan] It would be useful to articulate if there are any operational
issues being observed with this specimen implementation. If there are none
(possibly because there are no multi-vendor deployments with this
implementation), then it would seem okay to have the implementation made
RFC-compliant in due course of time (backwards compatible change). Please
note that the PATH RRO has other uses apart from facilitating
ingress-triggered route-recording (in addition to helping with loop
detection, it is also used in certain Summary-FRR and RI-RSVP-FRR
procedures) and might not be a bad idea for the implementation to start
using it.


>
>
> My 2c,
>
> Sasha
>
>
>
> *From:* Vishnu Pavan Beeram <vishnupavan@gmail.com>
> *Sent:* Tuesday, August 27, 2024 5:04 PM
> *To:* Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>
> *Cc:* mpls <mpls@ietf.org>; adrian@olddog.co.uk; teas@ietf.org
> *Subject:* [EXTERNAL] Re: [Teas] A gap between Section 5 of RFC 4090 and
> Section 4.4.3 of RFC 3209
>
>
>
> Sasha, Hi!
>
>
>
> I don’t see any contradiction.
>
>
>
> My interpretation of the relevant text in RFC3209:
>
> ·       ‘Route Recording’ for an LSP is enabled by the head-end LSR by
> including the RRO in the PATH.
>
> ·       There should be no RRO in the RESV if there is no RRO in the
> corresponding PATH. I’m aware of tail-end LSR implementations that are
> “strict” about this.
>
> ·       The presence of the “Label Recording” flag in the
> SESSION_ATTRIBUTE object indicates the “desire” to have the label at each
> hop recorded. It is not mandatory for this “desire” to be always catered
> to. If there is no RRO in the RESV, there is no “Label Recording”  (no
> non-RRO label recording procedure is specified).
>
>
>
> My interpretation of the relevant text in RFC4090:
>
> ·       If a head-end LSR implementation is compliant with RFC4090, it
> MUST set the “Label Recording Desired” flag in the SESSION_ATTRIBUTE of the
> protected LSP. If ‘Label Recording’ is not catered to, then facility backup
> method specific procedures would not work.  This implies that for the
> facility backup method procedures to work, an RFC4090 compliant head-end
> LSR implementation must also enable ‘Route Recording’ by including the RRO
> in the PATH. I’m aware of PLR implementations that do not provide
> facility-backup based local protection for protection-seeking LSPs that do
> not include an RRO.
>
>
>
> Though I think it would have been useful for the specifications to be a
> bit more explicit, I don’t see the need to make any changes to the
> specifications.
>
>
>
> Regards,
>
> -Pavan
>
>
>
> On Tue, Aug 27, 2024 at 4:09 PM Alexander Vainshtein
> <Alexander.Vainshtein=40rbbn.com@dmarc.ietf.org> wrote:
>
> 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
>
>