[mpls] Re: Rtgdir early review of draft-ietf-mpls-ri-rsvp-frr-18

[Chandrasekar Ramachandran <[e-mail]>]

Thanks for the detailed review. Please see inline (prefixed [CR]) for responses.

Thanks,
Chandra.


Juniper Business Use Only
> -----Original Message-----
> From: Ketan Talaulikar via Datatracker <[e-mail]>
> Sent: Monday, May 27, 2024 9:09 PM
> To: [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: Rtgdir early review of draft-ietf-mpls-ri-rsvp-frr-18
>
> [External Email. Be cautious of content]
>
>
> Reviewer: Ketan Talaulikar
> Review result: Has Issues
>
> Hello,
>
> I've been asked to review this document for the RTGDIR.
>
> Thanks to the authors and the WG members for a very well written and
> thorough document.
>
> My concern is with the overloading of the I-flag with additional semantics
> instead of defining a new one and most of the major comments are related to
> this. Other than that, I believe the other comments are minor and should be
> easy to address/clarify.

[CR]  Please refer to the following thread for some background and detailed discussion on the overloading of the I-flag:
https://mailarchive.ietf.org/arch/msg/mpls/g8Hp5dDOve8Z_3QaydX4tVZwKj0/

Yes, the authors believe that it is extremely unlikely that an MPLS RSVP-TE implementation that supports RFC4090 would implement only RI-RSVP and not RI-RSVP-FRR. In the rare scenario where such an implementation choice is made, the requirements on the establishment of signaling handshake and the backwards compatibility procedures discussed in the document provide for sufficient cover.

> Please find below inline comments in the ID nits output (with portions
> snipped out).
>
> Thanks,
> Ketan
>
>
>
> 15      Abstract
>
> 17         The RSVP-TE Fast Reroute extensions specified in RFC 4090 defines
> two
> 18         local repair techniques to reroute Label Switched Path (LSP) traffic
> 19         over pre-established backup tunnel.  Facility backup method allows
> 20         one or more LSPs traversing a connected link or node to be protected
> 21         using a bypass tunnel.  The many-to-one nature of local repair
> 22         technique is attractive from scalability point of view.  This
> 23         document enumerates facility backup procedures in RFC 4090 that rely
> 24         on refresh timeout and hence make facility backup method refresh-
> 25         interval dependent.  The RSVP-TE extensions defined in this document
> 26         will enhance the facility backup protection mechanism by making the
> 27         corresponding procedures refresh-interval independent and hence
> 28         compatible with Refresh-interval Independent RSVP (RI-RSVP)
> specified
> 29         in RFC 8370.  Hence, this document updates RFC 4090 in order to
> 30         support RI-RSVP capability specified in RFC 8370.
>
> < major > Since RFC8370 does not formally update the base RSVP-TE specs, is
> it appropriate for this document to formally update RFC4090. I would think
> that it enhances RFC4090? I'll let the responsible AD determine if this is
> appropriate.

[CR] The "Updates RFC4090" attribute was added to the document based on the guidance given by the then chairs and AD following relevant discussion during WGLC. Please refer to the following thread for some background and discussion on this:
https://mailarchive.ietf.org/arch/msg/mpls/tGexG5IZFk9Vj4WvFfLuJIO9FKI/

The "Updates RFC4090" attribute was deemed appropriate then because updated RFC4090 procedures are needed when RI-RSVP is enabled in the network.

> 360     4.1.  Requirement on RFC 4090 Capable Node to advertise RI-RSVP
> 361           Capability
>
> 363        A node supporting facility backup protection [RFC4090] MUST set the
> 364        RI-RSVP flag (I bit) that is defined in Section 3.1 of RSVP-TE
> 365        Scaling Techniques [RFC8370] only if it supports all the extensions
> 366        specified in the rest of this document.  Hence, this document updates
>
> < major > Was the use of another different capability considered instead of
> overloading the existing I bit with additional requirements? This would have
> taken care of some of the backward compatibility issues described further.
> There is no discussion why this isn't being done - assuming there is/was a
> good reason for it.

[CR] Please refer to the following thread for some background and detailed discussion on this:
https://mailarchive.ietf.org/arch/msg/mpls/g8Hp5dDOve8Z_3QaydX4tVZwKj0/

> 367        [RFC4090] by defining extensions and additional procedures over
> 368        facility backup protection [RFC4090] in order to advertise RI-RSVP
> 369        capability [RFC8370].  However, if a node supporting facility backup
> 370        protection [RFC4090] does set the RI-RSVP capability (I bit) but does
> 371        not support all the extensions specified in the rest of this
> 372        document, then it leaves room for stale state to linger around for an
> 373        inordinate period of time given the long refresh intervals
> 374        recommended by [RFC8370] or disruption of normal FRR operation.
> 375        Procedures for backward compatibility (see Section 4.6.2.3 of this
> 376        document) delves on this in detail.
>
> 378     4.2.  Signaling Handshake between PLR and MP
>
> 380     4.2.1.  PLR Behavior
>
> 382        As per the facility backup procedures [RFC4090], when an LSP
> becomes
> 383        operational on a node and the "local protection desired" flag has
> 384        been set in the SESSION_ATTRIBUTE object carried in the Path
> message
> 385        corresponding to the LSP, then the node attempts to make local
> 386        protection available for the LSP.
>
> 388        -  If the "node protection desired" flag is set, then the node tries
> 389           to become a PLR by attempting to create a NP-bypass LSP to the
> 390           NNhop node avoiding the Nhop node on protected LSP path.  In
> case
> 391           node protection could not be made available, the node attempts to
> 392           create an LP-bypass LSP to the Nhop node avoiding only the link
> 393           that the protected LSP takes to reach the Nhop
>
> 395        -  If the "node protection desired" flag is not set, then the PLR
> 396           attempts to create an LP-bypass LSP to the Nhop node avoiding the
> 397           link that the protected LSP takes to reach the Nhop
>
> 399        With regard to the PLR procedures described above and that are
> 400        specified in [RFC4090], this document specifies the following
> 401        additional procedures to support RI-RSVP [RFC8370].
>
> 403        -  While selecting the destination address of the bypass LSP, the PLR
> 404           MUST select the router ID of the NNhop or Nhop node from the
> Node-
> 405           ID sub-object included in the RRO object carried in the most
> 406           recent Resv message corresponding to the LSP.  If the MP has not
> 407           included a Node-ID sub-object in the Resv RRO and if the PLR and
> 408           the MP are in the same area, then the PLR may utilize the TED to
>
> < minor > Shouldn't this be MAY ?

[CR] The subsequent "MP behavior" section mandates that the downstream node include the Node-ID sub-object in the Resv RRO to enable the upstream node to bring up both the bypass tunnel and the remote node-id signaling adjacency with the MP node. Hence, the MUST in the first sentence is correct.

The second sentence above provides an optional method on the PLR to utilize the TED, if the MP is in the same IGP area, to bring up both the bypass tunnel and the remote node-id signaling adjacency - even if the MP has not included a Node-ID sub-object in the Resv RRO.

> 409           determine the router ID corresponding to the interface address
> 410           included by the MP in the RRO object.  If the NP-MP in a different
> 411           IGP area has not included a Node-ID sub-object in RRO object, then
> 412           the PLR MUST execute backward compatibility procedures as if the
> 413           downstream nodes along the LSP do not support the extensions
> 414           defined in the document (see Section 4.6.2.1).
>
> 416        -  The PLR MUST also include its router ID in a Node-ID sub-object in
> 417           RRO object carried in any subsequent Path message corresponding
> to
> 418           the LSP.  While including its router ID in the Node-ID sub-object
> 419           carried in the outgoing Path message, the PLR MUST include the
> 420           Node-ID sub-object after including its IPv4/IPv6 address or
> 421           unnumbered interface ID sub-object.
>
> 423        -  In parallel to the attempt made to create NP-bypass or LP-bypass,
> 424           the PLR MUST initiate a Node-ID based Hello session to the NNhop
> 425           or Nhop node respectively along the LSP to establish the RSVP-TE
> 426           signaling adjacency.  This Hello session is used to detect MP node
> 427           failure as well as determine the capability of the MP node.  If
> 428           the MP has set the I-bit in the CAPABILITY object [RFC8370]
> 429           carried in Hello message corresponding to the Node-ID based Hello
> 430           session, then the PLR MUST conclude that the MP supports refresh-
> 431           interval independent FRR procedures defined in this document.  If
> 432           the MP has not sent Node-ID based Hello messages or has not set
> 433           the I-bit in CAPABILITY object [RFC8370], then the PLR MUST
> 434           execute backward compatibility procedures defined in
> 435           Section 4.6.2.1 of this document.
>
> 437        -  When the PLR associates a bypass to a protected LSP, it MUST
> 438           include a B-SFRR-Ready Extended Association object [RFC8796] and
> 439           trigger a Path message to be sent for the LSP.  If a B-SFRR-Ready
> 440           Extended Association object is included in the Path message
> 441           corresponding to the LSP, the encoding and object ordering rules
> 442           specified in RSVP-TE Summary FRR [RFC8796] MUST be followed.  In
> 443           addition to those rules, the PLR MUST set the Association Source
> 444           in the object to its Node-ID address.
>
> 446     4.2.2.  Remote Signaling Adjacency
>
> 448        A Node-ID based RSVP-TE Hello session is one in which Node-ID is
> used
> 449        in the source and the destination address fields of RSVP Hello
> 450        messages [RFC4558].  This document extends Node-ID based RSVP
> Hello
> 451        session to track the state of any RSVP-TE neighbor that is not
> 452        directly connected by at least one interface.  In order to apply
> 453        Node-ID based RSVP-TE Hello session between any two routers that
> are
> 454        not immediate neighbors, the router that supports the extensions
> 455        defined in the document MUST set TTL to 255 in all outgoing Node-ID
> 456        based Hello messages exchanged between the PLR and the MP.  The
> 457        default hello interval for this Node-ID hello session MUST be set to
> 458        the default specified in RSVP-TE Scaling Techniques [RFC8370].
>
> < minor > Is it possible that there already exists a RSVP Hello session between
> the PLR and MP (for some reasons other than FRR)?

[CR] Yes, it may be possible.

> < major > Is it not necessary to add some text to indicate when these RSVP
> hello session states need to be cleaned-up/removed?

[CR] When the hello session states are created and cleaned up are implementation choices that do not impact the procedures specified in the document. Hence, no recommendation is made on those aspects.

> 460        In the rest of the document the term "signaling adjacency", or
> 461        "remote signaling adjacency" refers specifically to the RSVP-TE
> 462        signaling adjacency.
>
>
> 511     4.2.4.  "Remote" State on MP
>
> 513        Once a router concludes it is the MP for a PLR running refresh-
> 514        interval independent FRR procedures as described in the preceding
> 515        section, it MUST create a remote path state for the LSP.  The only
> 516        difference between the "remote" path state and the LSP state is the
> 517        RSVP_HOP object.  The RSVP_HOP object in a "remote" path state
> 518        contains the address that the PLR uses to send Node-ID hello
> messages
> 519        to the MP.
>
> 521        The MP MUST consider the "remote" path state corresponding to the
> LSP
> 522        automatically deleted if:
>
> 524        -  The MP later receives a Path message for the LSP with no matching
> 525           B-SFRR-Ready Extended Association object corresponding to the
> 526           PLR's IP address contained in the Path RRO, or
>
> 528        -  The Node-ID signaling adjacency with the PLR goes down, or
>
> < minor > I assume the above also includes "down" due to something like
> BFD?

[CR] The state of node-id signaling adjacency could be tied to the RSVP hello session between the two nodes or to a BFD session between the node-id addresses that is left to the choice of the implementation.

> 530        -  The MP receives backup LSP signaling for the LSP from the PLR or
>
> < minor > Does the above assume that the PLR is signaling a different backup
> LSP?

[CR] Not sure what you mean by "different". This is backup LSP signaling as discussed in https://datatracker.ietf.org/doc/html/rfc4090#section-6.1

> 532        -  The MP receives a PathTear for the LSP, or
>
> 534        -  The MP deletes the LSP state on a local policy or an exception
> 535           event
>
> 537        The purpose of "remote" path state is to enable the PLR to explicitly
> 538        tear down the path and reservation states corresponding to the LSP
> by
> 539        sending a tear message for the "remote" path state.  Such a message
> 540        tearing down "remote" path state is called "Remote" PathTear.
>
> 542        The scenarios in which a "Remote" PathTear is applied are described
> 543        in Section 4.5 of this document.
>
>
> 869     4.6.  Backward Compatibility Procedures
>
> 871        "Refresh interval Independent FRR" or RI-RSVP-FRR refers to the set
> 872        of procedures defined in this document to eliminate the reliance of
> 873        periodic refreshes.  The extensions proposed in RSVP-TE Summary
> FRR
> 874        [RFC8796] may apply to implementations that do not support RI-
> RSVP-
> 875        FRR.  On the other hand, RI-RSVP-FRR extensions relating to LSP state
> 876        cleanup namely Conditional and "Remote" PathTear require support
> from
> 877        one-hop and two-hop neighboring nodes along the LSP path.  So
> 878        procedures that fall under LSP state cleanup category MUST NOT be
> 879        turned on if any of the nodes involved in the node protection FRR
> 880        i.e.  the PLR, the MP and the intermediate node in the case of NP,
> 881        DOES NOT support RI-RSVP-FRR extensions.  Note that for LSPs
> 882        requesting link protection, only the PLR and the LP-MP MUST support
> 883        the extensions.
>
> 885     4.6.1.  Detecting Support for Refresh interval Independent FRR
>
> 887        An implementation supporting RI-RSVP-FRR extensions SHOULD set
> the
>
> < minor > I believe this is a MUST per RFC8370 sec 3.1, or am I missing
> something?

[CR] Good catch. We'll change this to "MUST".

> 888        flag "Refresh interval Independent RSVP" or RI-RSVP flag in the
> 889        CAPABILITY object carried in Hello messages as specified in RSVP-TE
> 890        Scaling Techniques [RFC8370].  If an implementation does not set the
> 891        flag even if it supports RI-RSVP-FRR extensions, then its neighbors
> 892        will view the node as any node that does not support the extensions.
>
> < major > The above seems to be conflicting with RFC8370 in that it changes
> the meaning of the I - flag. See previous comments as well.

[CR]  Yes, An implementation that supports RFC8370 MUST set the RI-RSVP flag in the CAPABILITY object. The text here is just describing what a neighbor of a faulty implementation is expected to do.

> 894        -  As nodes supporting the RI-RSVP-FRR extensions initiate Node-ID
> 895           based signaling adjacency with all immediate neighbors, such a
> 896           node on the path of a protected LSP can determine whether its
> Phop
> 897           and Nhop neighbors support RI-RSVP-FRR enhancements.
>
> 899        -  As nodes supporting the RI-RSVP-FRR extensions also initiate Node-
> 900           ID based signaling adjacency with the NNhop along the path of the
> 901           LSP requested node protection (see Section 4.2.1 of this
> 902           document), each node along the LSP path can determine whether
> its
> 903           NNhop node supports RI-RSVP-FRR enhancements.  If the NNhop
> (a)
> 904           does not reply to remote Node-ID Hello messages or (b) does not
> 905           set the RI-RSVP flag in the CAPABILITY object carried in its Node-
> 906           ID Hello messages, then the node acting as the PLR can conclude
> 907           that NNhop does not support RI-RSVP-FRR extensions.
>
> 909        -  If node protection is requested for an LSP and if (a) the PPhop
> 910           node has not included a matching B-SFRR-Ready Extended
> Association
> 911           object in its Path messages or (b) the PPhop node has not
> 912           initiated remote Node-ID Hello messages or (c) the PPhop node
> does
> 913           not set the RI-RSVP flag in the CAPABILITY object carried in its
> 914           Node-ID Hello messages, then the node MUST conclude that the
> PLR
> 915           does not support RI-RSVP-FRR extensions.
>
>
> 980     4.6.2.3.  Advertising RI-RSVP without RI-RSVP-FRR
>
> 982        If a node supporting facility backup protection [RFC4090] sets the
> 983        RI-RSVP capability (I bit) but does not support the RI-RSVP-FRR
> 984        extensions, then it leaves room for stale state to linger around for
> 985        an inordinate period of time or disruption of normal FRR operation
> 986        (see Section 3 of this document).  Consider the example topology
> 987        Figure 1 provided in this document.
>
> 989        -  Assume node B does set RI-RSVP capability in its Node-ID based
> 990           Hello messages even though it does not support RI-RSVP-FRR
> 991           extensions.  When B detects the failure of its Phop link along an
> 992           LSP, it will not send Conditional PathTear to C as required by the
> 993           RI-RSVP-FRR procedures.  If B simply leaves the LSP state without
> 994           deleting, then B may end up holding on to the stale state until
> 995           the (long) refresh timeout.
>
> 997        -  Instead of node B, assume node C does set RI-RSVP capability in
> 998           its Node-id based Hello messages even though it does not support
> 999           RI-RSVP-FRR extensions.  When B details the failure of its Phop
> 1000          link along an LSP, it will send Conditional PathTear to C as
> 1001          required by the RI-RSVP-FRR procedures.  But, C would not
> 1002          recognize the condition encoded in the PathTear and end up
> tearing
> 1003          down the LSP.
>
> 1005       -  Assume node B does set RI-RSVP capability in its Node-ID based
> 1006          Hello messages even though it does not support RI-RSVP-FRR
> 1007          extensions.  Also assume local repair is about to commence on
> node
> 1008          B for an LSP that has only requested link protection.  That is, B
> 1009          has not initiated the backup LSP signaling for the LSP.  If node B
> 1010          receives a normal PathTear at this time from ingress A because of
> 1011          a management event initiated on A, then B simply deletes the LSP
> 1012          state without sending a Remote PathTear to the LP-MP C.  So, C may
> 1013          end up holding on to the stale state until the (long) refresh
> 1014          timeout.
>
> < major > As mentioned in a previous comment, all these backward
> compatibility issues would have been mitigated with the use of a new flag
> than the existing I flag?

[CR] Please see earlier response on the motivation behind overloading the I flag.

> 1089    6.2.  CONDITIONS Flags
>
> 1091       Apart from allocating Class-Number for the CONDITIONS object, the
> 1092       allocation of the Merge-point condition bit or M-bit (see Section 4.4
> 1093       of this document) will also be done by IANA.
>
> 1095       Flag: 0x1 Name: Merge-point condition bit or M-bit
>
> < major > This seems like a new registry. What is the allocation policy for it?
> OTOH from the picture, this seems like a single flag since the rest is marked as
> a reserved and not a flags field - in that case, we don't need anything from
> IANA, right?
>

[CR] Please refer to the updated IANA section in the latest version of the draft.
https://datatracker.ietf.org/doc/html/draft-ietf-mpls-ri-rsvp-frr#section-6
The changes in this version should address all the IANA section specific comments received so far.