[Teas] Re: A gap between Section 5 of RFC 4090 and Section 4.4.3 of RFC 3209
Vishnu Pavan Beeram <vishnupavan@gmail.com> Tue, 27 August 2024 14:04 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 6EA83C15198B; Tue, 27 Aug 2024 07:04:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.104
X-Spam-Level:
X-Spam-Status: No, score=-2.104 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_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=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 0MIZQr37Ch3H; Tue, 27 Aug 2024 07:04:27 -0700 (PDT)
Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com [IPv6:2607:f8b0:4864:20::42f]) (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 84602C151072; Tue, 27 Aug 2024 07:04:27 -0700 (PDT)
Received: by mail-pf1-x42f.google.com with SMTP id d2e1a72fcca58-7142a93ea9cso3899311b3a.3; Tue, 27 Aug 2024 07:04:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1724767467; x=1725372267; 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=E3+Gz6MT3QRQBJ4L3pP+soZb862h9FwtpBQI4mdhnCo=; b=AYeBN2XQFO9jFlFHGnRleT76hNx3DiccDs6mW6N84yqPN3fwkYhykVVg6e4VhhUbsy SK4KjX8Gq8NfGuh5dUhDbFYeItGVtCUtR0wHkdmQFdq2Qpy2W/VV3QF0WDDTTyk/noqG 3jydq8MpUlhV0s+8XkiO3cM5UXrDECrEsBzidxvLF10Ubyd6PgnbsgNQKikg2IUmc01o 7Ipscc6cPY4MBr+d9Z6C4BbO51Hj9dQAkNQUDPMhaGVjmMAc7NAKuJEDOIWZnd5aWeQO Uq7u8RlvrvP1T3yve72uLv4SqCzMLR7hirv0pE3nGvrIiUZdWBni2OHItk+NmiMVlGyZ 9sCg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724767467; x=1725372267; 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=E3+Gz6MT3QRQBJ4L3pP+soZb862h9FwtpBQI4mdhnCo=; b=pSTS8aQojUn6iPQX3vCZqUNY6184txwDEGP3ZQKUyYdBb/T29KY/KSjO1U8u260mBE QC10eqaRxw9lfCWMNeC4838qQKPCY9zzhPlNGTe6NiBLv6cajpc9AGeg2JzYQSco5b6v RI5TBCksEfmh/Ypz/tUWBUYWIefAxr4RZt666v9NNZvN3GuSLDRTbh4B9qhgLWXGKWvz FhI9rj0tSznmj5b5PwfobgaE9EdZNwmARX7bMBi2yhhh2TFd3UpHCKLzyL398Dso2ZlH 1wBcohXnIQLu4DLKxTJ2JiLsDCU2j9qyvfueMp6Is+YhxWd6+ul9LigZrJR+AObBFkr0 xzYQ==
X-Forwarded-Encrypted: i=1; AJvYcCVvYX3pXz00K8+zurfFpFdtHCt2qOFhZ2UHsrmXTorOdsdCf5S7SOU+dICrMyAcnEwaIWQw@ietf.org
X-Gm-Message-State: AOJu0YzKJPPYaFfUzcTCFlcDSPS6ci+rIisYgmr6yv4KD9Zq2QGvzxzQ ZEl/8wET2/67PgaOSImfcko7qGMVOIwSZph13JmQ5TU9d5WL1D37Va2UncViKuAWXcg0nTe5vAR 875ivo2A9mQXgjnhgsc6yPNjgzzQ=
X-Google-Smtp-Source: AGHT+IGt8KJxQrCd9LpqfAaRbCyKxF+/jKQyvs8STgKTsXQUqz5c/LlnmqRSDT4AiG19OVZqzF/AZoZVe5HpuBKZmgI=
X-Received: by 2002:a05:6a20:9e49:b0:1c2:905c:dc2 with SMTP id adf61e73a8af0-1cc89d6bab9mr14161166637.15.1724767466427; Tue, 27 Aug 2024 07:04:26 -0700 (PDT)
MIME-Version: 1.0
References: <PH0PR03MB63007A1C71A9A11AF0AEF3C4F6942@PH0PR03MB6300.namprd03.prod.outlook.com>
In-Reply-To: <PH0PR03MB63007A1C71A9A11AF0AEF3C4F6942@PH0PR03MB6300.namprd03.prod.outlook.com>
From: Vishnu Pavan Beeram <vishnupavan@gmail.com>
Date: Tue, 27 Aug 2024 19:34:15 +0530
Message-ID: <CA+YzgTtw-Z-qPzsz_GY0P=vboXvneEgCja98w38fTH8fPgUqAw@mail.gmail.com>
To: Alexander Vainshtein <Alexander.Vainshtein=40rbbn.com@dmarc.ietf.org>
Content-Type: multipart/alternative; boundary="000000000000281ef50620aab8cf"
Message-ID-Hash: L3OZM33MU4SLJQNXOH2UQLJBSY5NPZUM
X-Message-ID-Hash: L3OZM33MU4SLJQNXOH2UQLJBSY5NPZUM
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: 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/BPeTC0P_fdIWyuHu4ZFvTH_0g5I>
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>
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. > ” > 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 “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 >
- [Teas] A gap between Section 5 of RFC 4090 and Se… Alexander Vainshtein
- [Teas] Re: A gap between Section 5 of RFC 4090 an… Adrian Farrel
- [Teas] Re: [EXTERNAL] RE: A gap between Section 5… Alexander Vainshtein
- [Teas] Re: A gap between Section 5 of RFC 4090 an… Vishnu Pavan Beeram
- [Teas] Re: [mpls] Re: [EXTERNAL] RE: A gap betwee… Vishnu Pavan Beeram
- [Teas] Re: [EXTERNAL] RE: A gap between Section 5… Adrian Farrel
- [Teas] Re: [EXTERNAL] RE: A gap between Section 5… Vishnu Pavan Beeram
- [Teas] Re: [EXTERNAL] Re: A gap between Section 5… Vishnu Pavan Beeram
- [Teas] Re: [EXTERNAL] RE: A gap between Section 5… Alexander Vainshtein
- [Teas] Re: [EXTERNAL] Re: A gap between Section 5… Alexander Vainshtein