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

[Alexander Vainshtein <[e-mail]>]

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.

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.

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.

My 2c,
Sasha

From: Vishnu Pavan Beeram <[e-mail]>
Sent: Tuesday, August 27, 2024 5:04 PM
To: Alexander Vainshtein <[e-mail]>
Cc: mpls <[e-mail]>; [e-mail]; [e-mail]
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=[e-mail]<mailto:[e-mail]>> 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 -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>