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

[Vishnu Pavan Beeram <[e-mail]>]

Sasha, Hi!



Thanks for the additional context. Please see inline (prefixed VPB) for
responses.



Regards,

-Pavan

On Tue, Aug 27, 2024 at 7:21 PM Alexander Vainshtein <Alexander.Vainshtein=
[e-mail]> wrote:

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

[VPB] I’m not sure what constitutes “de-facto industry reality”. The
specimen implementation that you are referring to seems to be non-compliant
with the procedure specified in Section 4.4.3 of RFC3209. As noted earlier,
there exist RFC3209 compliant implementations (that have been around for
more than 2 decades) that do not include the RRO in the RESV if the RRO is
not present in the PATH.


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

[VPB] IMHO, the proposed text ("for some specific purpose" is vague) is
bound to cause confusion. If the “specimen implementation” is running into
some interoperability issue (which is quite possible given the existence of
the other RFC3209 compliant implementations), I would recommend fixing the
implementation to include the PATH RRO when “label recording” is desired.


>
>
> My 2c
>
> Sasha
>
>
>
> *From:* Adrian Farrel <[e-mail]>
> *Sent:* Tuesday, August 27, 2024 3:34 PM
> *To:* Alexander Vainshtein <[e-mail]>; 'mpls' <
> [e-mail]>
> *Cc:* [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]>
> *Sent:* 27 August 2024 11:39
> *To:* mpls <[e-mail]>
> *Cc:* [e-mail]; [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.
> _______________________________________________
> mpls mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>