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

[Alexander Vainshtein <[e-mail]>]

Adrian,
Lots of thanks for a very detailed response.
Please see more inline below.

Regards,
Sasha

From: Adrian Farrel <[e-mail]>
Sent: Tuesday, August 27, 2024 11:02 PM
To: Alexander Vainshtein <[e-mail]>
Cc: [e-mail]; 'mpls' <[e-mail]>
Subject: RE: [EXTERNAL] RE: A gap between Section 5 of RFC 4090 and Section 4.4.3 of RFC 3209

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.

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.


[[Sasha]] I fully agree that this issue, while a technical violation of Section 4.4.3 of RFC 3209, is not important. Changing SHALL NOT to SHOULD NOT would simply make this behaviour legitimate for those who care about such things😊


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).
[[Sasha]] From my POV this is the real issue.
There is a choice to be made here:

a.       Have the feature fail and blame the ingress that did not include an RRO in its PATH. Get that implementation fixed. [[Sasha]] This is fine if we simply want to blame somebody else, but does not solve anything

b.       Fix the egress implementation to act as in the first issue (i.e., send an RRO in the RESV regardless). [[Sasha]] Unless we replace SHALL NOT with SHOULD NOT, this results in egress being in an explicit violation of 3209

c.       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. [[Sasha]] IMHO this means developing something like 4090bis that should be marked as updating 3209 (no such metadata for the original 4090).
Cheers,
Adrian

From: Alexander Vainshtein <[e-mail]<mailto:[e-mail]>>
Sent: 27 August 2024 14:51
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>; 'mpls' <[e-mail]<mailto:[e-mail]>>
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 <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, August 27, 2024 3:34 PM
To: Alexander Vainshtein <[e-mail]<mailto:[e-mail]>>; 'mpls' <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
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 <[e-mail]<mailto:[e-mail]>>
Sent: 27 August 2024 11:39
To: mpls <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
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.