Refresh-Interval Independent RSVP Fast Reroute Facility Protection

Solution Aspects The solution consists of five parts:

Utilize the MP determination mechanism specified in RSVP-TE Summary FRR that enables the PLR to signal the availability of local protection to the MP. In addition, introduce PLR and MP procedures to establish a Node-ID-based Hello session between the PLR and the MP to detect router failures and to determine capability. See of this document for more details. This part of the solution reuses some of the extensions defined in and , and the subsequent subsections will list the extensions in these documents that are utilized in this document.
Handle upstream link or node failures by cleaning up LSP states if the node has not found itself as an MP through the MP determination mechanism. See of this document for more details.
Introduce extensions to enable a router to send a teardown message to the downstream router that enables the receiving router to conditionally delete its local LSP state. See of this document for more details.
Enhance facility backup protection by allowing a PLR to directly send a teardown message to the MP without requiring the PLR to either have a working bypass LSP or have already signaled the backup LSP state. See of this document for more details.
Introduce extensions to enable the above procedures to be backward compatible with routers along the LSP running implementations that do not support these procedures. See of this document for more details.

Requirement for RFC 4090 Capable Nodes to Advertise the RI-RSVP Capability A node supporting facility backup protection MUST NOT set the RI-RSVP flag (I-bit) that is defined in unless it supports all the extensions specified in the rest of this document. Hence, this document updates by defining extensions and additional procedures over facility backup protection in order to advertise the RI-RSVP capability . However, if a node supporting facility backup protection does set the RI-RSVP capability (I-bit) but does not support all the extensions specified in the rest of this document, then it may result in lingering stale states due to the long refresh intervals recommended by . This can also disrupt normal Fast Reroute (FRR) operations. of this document delves into this in detail.

Signaling Handshake Between PLR and MP

PLR Behavior As per the facility backup procedures , when an LSP becomes operational on a node and the "local protection desired" flag has been set in the SESSION_ATTRIBUTE object carried in the Path message corresponding to the LSP, then the node attempts to make local protection available for the LSP.

If the "node protection desired" flag is set, then the node tries to become a PLR by attempting to create an NP-bypass LSP to the NNHOP node avoiding the NHOP node on a protected LSP. In case node protection could not be made available, the node attempts to create an LP-bypass LSP to the NHOP node avoiding only the link that the protected LSP takes to reach the NHOP.
If the "node protection desired" flag is not set, then the PLR attempts to create an LP-bypass LSP to the NHOP node avoiding the link that the protected LSP takes to reach the NHOP.

With regard to the PLR procedures described above and specified in , this document specifies the following additional procedures to support RI-RSVP .

While selecting the destination address of the bypass LSP, the PLR MUST select the router ID of the NNHOP or NHOP node from the Node-ID sub-object included in the RRO that is carried in the most recent Resv message corresponding to the LSP. If the MP has not included a Node-ID sub-object in the Resv RRO and if the PLR and the MP are in the same area, then the PLR may utilize the TED to determine the router ID corresponding to the interface address that is included by the MP in the RRO. If the NP-MP in a different IGP area has not included a Node-ID sub-object in the RRO, then the PLR MUST execute backward compatibility procedures as if the downstream nodes along the LSP do not support the extensions defined in the document (see ).
The PLR MUST also include its router ID in a Node-ID sub-object in the RRO that is carried in any subsequent Path message corresponding to the LSP. While doing so, the PLR MUST include the Node-ID sub-object after including its IPv4/IPv6 address or unnumbered interface ID sub-object.
In parallel to the attempt made to create an NP-bypass or an LP-bypass, the PLR MUST initiate a Node-ID-based Hello session to the NNHOP or NHOP node respectively along the LSP to establish the RSVP-TE signaling adjacency. This Hello session is used to detect MP node failure as well as to determine the capability of the MP node. The PLR MUST conclude that the MP supports the refresh-interval independent FRR procedures defined in this document if the MP has set the I-bit in the CAPABILITY object carried in the Hello message corresponding to the Node-ID-based Hello session. If the MP has not sent Node-ID-based Hello messages or has not set the I-bit in the CAPABILITY object , then the PLR MUST execute backward compatibility procedures defined in of this document.
When the PLR associates a bypass to a protected LSP, it MUST include a B-SFRR-Ready Extended ASSOCIATION object and trigger a Path message to be sent for the LSP. If a B-SFRR-Ready Extended ASSOCIATION object is included in the Path message corresponding to the LSP, the encoding and object ordering rules specified in RSVP-TE Summary FRR MUST be followed. In addition to those rules, the PLR MUST set the Association Source in the object to its Node-ID address.

Remote Signaling Adjacency A Node-ID-based RSVP-TE Hello session is one in which a Node-ID is used in the source and the destination address fields of RSVP Hello messages . This document extends Node-ID-based RSVP Hello sessions to track the state of any RSVP-TE neighbor that is not directly connected by at least one interface. In order to apply Node-ID-based RSVP-TE Hello sessions between any two routers that are not immediate neighbors, the router that supports the extensions defined in the document MUST set the TTL to 255 in all outgoing Node-ID-based Hello messages exchanged between the PLR and the MP. The default hello interval for this Node-ID Hello session MUST be set to the default specified in RSVP-TE Scaling Techniques . In the rest of the document, the terms "signaling adjacency" and "remote signaling adjacency" refer specifically to the RSVP-TE signaling adjacency.

MP Behavior With regard to the MP procedures that are defined in , this document specifies the following additional procedures to support RI-RSVP as defined in . Each node along an LSP supporting the extensions defined in this document MUST also include its router ID in the Node-ID sub-object of the RRO that is carried in the Resv message of the corresponding LSP. If the PLR has not included a Node-ID sub-object in the RRO that is carried in the Path message and if the PLR is in a different IGP area, then the router MUST NOT execute the MP procedures specified in this document for those LSPs. Instead, the node MUST execute backward compatibility procedures defined in of this document as if the upstream nodes along the LSP do not support the extensions defined in this document. A node receiving a Path message should determine:

whether the message contains a B-SFRR-Ready Extended ASSOCIATION object with its own address as the bypass destination address and
whether it has an operational Node-ID signaling adjacency with the Association Source.

The node MUST execute the backward compatibility procedures defined in of this document if:

the PLR has not included the B-SFRR-Ready Extended ASSOCIATION object,
there is no operational Node-ID signaling adjacency with the PLR identified by the Association Source address, or
the PLR has not advertised the RI-RSVP capability in its Node-ID-based Hello messages.

If a matching B-SFRR-Ready Extended ASSOCIATION object is found in the Path message and if there is an operational remote Node-ID signaling adjacency with the PLR (identified by the Association Source) that has advertised the RI-RSVP capability (I-bit) , then the node MUST consider itself as the MP for the PLR. The matching and ordering rules for Bypass Summary FRR Extended Association specified in RSVP-TE Summary FRR MUST be followed by the implementations supporting this document.

If a matching Bypass Summary FRR Extended Association object is included by the PPHOP node of an LSP and if a corresponding Node-ID signaling adjacency exists with the PPHOP node, then the router MUST conclude it is the NP-MP.
If a matching Bypass Summary FRR Extended Association object is included by the PHOP node of an LSP and if a corresponding Node-ID signaling adjacency exists with the PHOP node, then the router MUST conclude it is the LP-MP.

"Remote" State on MP Once a router concludes it is the MP for a PLR running refresh-interval independent FRR procedures as described in the preceding section, it MUST create a remote path state for the LSP. The only difference between the "remote" path state and the LSP state is the RSVP_HOP object. The RSVP_HOP object in a "remote" path state contains the address that the PLR uses to send Node-ID Hello messages to the MP. The MP MUST consider the "remote" path state corresponding to the LSP automatically deleted if:

the MP later receives a Path message for the LSP with no matching B-SFRR-Ready Extended ASSOCIATION object corresponding to the PLR's IP address contained in the Path RRO,
the Node-ID signaling adjacency with the PLR goes down,
the MP receives backup LSP signaling for the LSP from the PLR,
the MP receives a PathTear for the LSP, or
the MP deletes the LSP state on a local policy or an exception event.

The purpose of "remote" path state is to enable the PLR to explicitly tear down the path and reservation states corresponding to the LSP by sending a tear message for the "remote" path state. Such a message tearing down the "remote" path state is called "Remote" PathTear. The scenarios in which a "Remote" PathTear is applied are described in of this document.

Impact of Failures on LSP State This section describes the procedures that must be executed upon different kinds of failures by nodes along the path of the LSP. The procedures that must be executed upon detecting RSVP signaling adjacency failures do not impact the RSVP-TE graceful restart mechanisms . If a node executing these procedures acts as a helper for a neighboring router, then the signaling adjacency with the neighbor will be declared as having failed only after taking into account the grace period extended for the neighbor by this node acting as a helper. Node failures are detected from the state of Node-ID Hello sessions established with immediate neighbors. RSVP-TE Scaling Techniques recommends that each node establish Node-ID Hello sessions with all its immediate neighbors. A non-immediate PLR or MP failure is detected from the state of remote signaling adjacency established according to of this document.

Non-MP Behavior When a router detects the PHOP link or the PHOP node failure for an LSP and the router is not an MP for the LSP, then it MUST send a Conditional PathTear (refer to of this document) and delete the PSB and RSB states corresponding to the LSP.

LP-MP Behavior When the PHOP link for an LSP fails on a router that is an LP-MP for the LSP, the LP-MP MUST retain the PSB and RSB states corresponding to the LSP until the occurrence of any of the following events:

the Node-ID signaling adjacency with the PHOP PLR goes down,
the MP receives a normal or "Remote" PathTear for its PSB, or
the MP receives a ResvTear for its RSB.

When a router that is an LP-MP for an LSP detects PHOP node failure from the Node-ID signaling adjacency state, the LP-MP MUST send a normal PathTear and delete the PSB and RSB states corresponding to the LSP.

NP-MP Behavior When a router that is an NP-MP for an LSP detects PHOP link failure or PHOP node failure from the Node-ID signaling adjacency, the router MUST retain the PSB and RSB states corresponding to the LSP until the occurrence of any of the following events:

the remote Node-ID signaling adjacency with the PPHOP PLR goes down,
the MP receives a normal or "Remote" PathTear for its PSB, or
the MP receives a ResvTear for its RSB.

When a router that is an NP-MP for an LSP does not detect the PHOP link or the PHOP node failure but receives a Conditional PathTear from the PHOP node, then the router MUST retain the PSB and RSB states corresponding to the LSP until the occurrence of any of the following events:

the remote Node-ID signaling adjacency with the PPHOP PLR goes down,
the MP receives a normal or "Remote" PathTear for its PSB, or
the MP receives a ResvTear for its RSB.

Receiving a Conditional PathTear from the PHOP node will not impact the "remote" state from the PPHOP PLR. Note that the PHOP node must have sent the Conditional PathTear as it was not an MP for the LSP (see of this document). In the example topology in , we assume C and D are the NP-MPs for the PLRs A and B, respectively. Now, when the A-B link fails, B will delete the LSP state, because B is not an MP and its PHOP link has failed (this behavior is required for unprotected LSPs; refer to of this document). In the data plane, that would require B to delete the label forwarding entry corresponding to the LSP. Thus, if B's downstream nodes C and D continue to retain state, it would not be correct for D to continue to assume itself as the NP-MP for the PLR B. The mechanism that enables D to stop considering itself as the NP-MP for B and delete the corresponding "remote" path state is given below.

When C receives a Conditional PathTear from B, it decides to retain the LSP state as it is the NP-MP of the PLR A. It also checks whether PHOP B had previously signaled availability of node protection. As B had previously signaled NP availability by including the B-SFRR-Ready Extended ASSOCIATION object, C removes the B-SFRR-Ready Extended ASSOCIATION object containing the Association Source set to B from the Path message and triggers a Path to D.
When D receives the Path message, it realizes that it is no longer the NP-MP for B and so it deletes the corresponding "remote" path state. D does not propagate the Path further down because the only change is that the B-SFRR-Ready Extended ASSOCIATION object corresponding to Association Source B is no longer present in the Path message.

Behavior of a Router That Is Both the LP-MP and NP-MP A router may simultaneously be the LP-MP and the NP-MP for the PHOP and PPHOP nodes of an LSP, respectively. If the PHOP link fails on such a node, the node MUST retain the PSB and RSB states corresponding to the LSP until the occurrence of any of the following events:

both Node-ID signaling adjacencies with PHOP and PPHOP nodes go down,
the MP receives a normal or "Remote" PathTear for its PSB, or
the MP receives a ResvTear for its RSB.

If a router that is both an LP-MP and an NP-MP detects PHOP node failure, then the node MUST retain the PSB and RSB states corresponding to the LSP until the occurrence of any of the following events:

the remote Node-ID signaling adjacency with the PPHOP PLR goes down,
the MP receives a normal or "Remote" PathTear for its PSB, or
the MP receives a ResvTear for its RSB.

Conditional PathTear In the example provided in of this document, B deletes the PSB and RSB states corresponding to the LSP once B detects its PHOP link has gone down as B is not an MP. If B were to send a PathTear normally, then C would delete the LSP state immediately. In order to avoid this, there should be some mechanism by which B can indicate to C that B does not require the receiving node to unconditionally delete the LSP state immediately. For this, B MUST add a new optional CONDITIONS object in the PathTear. The CONDITIONS object is defined in of this document. If node C also understands the new object, then C MUST NOT delete the LSP state if it is an NP-MP.

Sending the Conditional PathTear A router that is not an MP for an LSP MUST delete the PSB and RSB states corresponding to the LSP if the PHOP link or the PHOP Node-ID signaling adjacency goes down (see of this document). The router MUST send a Conditional PathTear if the following are also true:

the ingress has requested node protection for the LSP and
no PathTear is received from the upstream node.

Processing the Conditional PathTear When a router that is not an NP-MP receives a Conditional PathTear, the node MUST delete the PSB and RSB states corresponding to the LSP and process the Conditional PathTear by considering it as a normal PathTear. Specifically, the node MUST NOT propagate the Conditional PathTear downstream but remove the optional object and send a normal PathTear downstream. When a node that is an NP-MP receives a Conditional PathTear, it MUST NOT delete the LSP state. The node MUST check whether the PHOP node had previously included the B-SFRR-Ready Extended ASSOCIATION object in the Path. If the object had been included previously by the PHOP, then the node processing the Conditional PathTear from the PHOP MUST remove the corresponding object and trigger a Path downstream. If a Conditional PathTear is received from a neighbor that has not advertised support (refer to of this document) for the new procedures defined in this document, then the node MUST consider the message as a normal PathTear. The node MUST propagate the normal PathTear downstream and delete the LSP state.

CONDITIONS Object Any implementation that does not support a Conditional PathTear needs to ignore the new object but process the message as a normal PathTear without generating any error. For this reason, the Class-Num of the new object follows the pattern 10bbbbbb, where "b" represents a bit. (The behavior for objects of this type is specified in .) The new object is called the "CONDITIONS" object and will specify the conditions under which default processing rules of the RSVP-TE message MUST be invoked. The object has the following format:

Class:: 135
C-type:: 1
Flags:: 32 bit field
M:: Bit 31 is the Merge-point condition (M) bit. If the M bit is set to 1, then the PathTear message MUST be processed according to the receiver router role, i.e., if the receiving router is an MP or not for the LSP. If it is not set, then the PathTear message MUST be processed as a normal PathTear message for the LSP.

Bits 0-30 are reserved; they MUST be set to zero on transmission and MUST be ignored on receipt.

Remote State Teardown If the ingress wants to tear down the LSP because of a management event while the LSP is being locally repaired at a transit PLR, it would not be desirable to wait until the completion of backup LSP signaling to perform state cleanup. In this case, the PLR MUST send a "Remote" PathTear message instructing the MP to delete the PSB and RSB states corresponding to the LSP. The TTL in the "Remote" PathTear message MUST be set to 255. Doing this enables LSP state cleanup when the LSP is being locally repaired. Consider that node C in the example topology () has gone down and node B locally repairs the LSP:

Ingress A receives a management event to tear down the LSP.
A sends a normal PathTear for the LSP to B.
Assume B has not initiated the backup signaling for the LSP during local repair. To enable LSP state cleanup, B sends a "Remote" PathTear with the destination IP address set to that of the node D used in the Node-ID signaling adjacency with D and the RSVP_HOP object containing the local address used in the Node-ID signaling adjacency.
B then deletes the PSB and RSB states corresponding to the LSP.
On D, there would be a remote signaling adjacency with B, and so D accepts the "Remote" PathTear and deletes the PSB and RSB states corresponding to the LSP.

PLR Behavior on Local Repair Failure If local repair fails on the PLR after a failure, the PLR MUST send a "Remote" PathTear to the MP. The purpose of this is to clean up LSP state from the PLR to the egress. Upon receiving the PathTear, the MP MUST delete the states corresponding to the LSP and also propagate the PathTear downstream, thereby achieving state cleanup from all downstream nodes up to the LSP egress. Note that in the case of link protection, the PathTear MUST be directed to the LP-MP's Node-ID IP address rather than the NHOP interface address.

PLR Behavior on Resv RRO Change When a PLR router that has already made NP available for an LSP detects a change in the RRO carried in the Resv message that indicates that the router's former NP-MP is no longer present on the path of the LSP, then the router MUST send a "Remote" PathTear directly to its former NP-MP. In the example topology in , assume node A has made node protection available for an LSP and C has concluded it is the NP-MP for PLR A. When the B-C link fails, then C, implementing the procedure specified in of this document, will retain the states corresponding to the LSP until one of the following occurs:

the remote Node-ID signaling adjacency with A goes down or
a PathTear or a ResvTear is received for its PSB or RSB, respectively.

If B also has made node protection available, B will eventually complete backup LSP signaling with its NP-MP D and trigger a Resv to A with RRO changed. The new RRO of the LSP carried in the Resv will not contain C. When A processes the Resv message with a new RRO not containing C, its former NP-MP, A, sends a "Remote" PathTear to C. When C receives the "Remote" PathTear for its PSB state, C will send a normal PathTear downstream to D and delete both the PSB and RSB states corresponding to the LSP. As D has already received backup LSP signaling from B, D will retain the control plane and forwarding states corresponding to the LSP.

LSP Preemption During Local Repair

Preemption on LP-MP After PHOP Link Failure If an LSP is preempted on an LP-MP after its PHOP link has already failed but the backup LSP has not been signaled yet as part of the local repair procedure, then the node MUST send a normal PathTear and delete both the PSB and RSB states corresponding to the LSP. As the LP-MP has retained the LSP state expecting the PLR to initiate backup LSP signaling, preemption would bring down the LSP and the node would not be LP-MP anymore, requiring the node to clean up the LSP state.

Preemption on NP-MP After PHOP Link Failure If an LSP is preempted on an NP-MP after its PHOP link has already failed but the backup LSP has not been signaled yet, then the node MUST send a normal PathTear and delete the PSB and RSB states corresponding to the LSP. As the NP-MP has retained the LSP state expecting the PLR to initiate backup LSP signaling, preemption would bring down the LSP and the node would not be NP-MP anymore, requiring the node to clean up LSP state. Consider that the B-C link goes down on the same example topology (). As C is the NP-MP for the PLR A, C will retain the LSP state.

The LSP is preempted on C.
C will delete the RSB state corresponding to the LSP. However, C cannot send a PathErr or a ResvTear to the PLR A because the backup LSP has not been signaled yet.
As the only reason for C having retained state after PHOP node failure was that it was an NP-MP, C sends a normal PathTear to D and also deletes its PSB state. D would also delete the PSB and RSB states on receiving a PathTear from C.
B starts backup LSP signaling to D. However, as D does not have the LSP state, it will reject the backup LSP Path message and send a PathErr to B.
B will delete its reservation and send a ResvTear to A.

Backward Compatibility Procedures "Refresh-Interval Independent RSVP FRR" and "RI-RSVP-FRR" refer to the set of procedures defined in this document to eliminate the reliance on periodic refreshes. The extensions proposed in RSVP-TE Summary FRR may apply to implementations that do not support RI-RSVP-FRR. On the other hand, RI-RSVP-FRR extensions relating to LSP state cleanup, namely Conditional and "Remote" PathTears, require support from one-hop and two-hop neighboring nodes along the LSP. Thus, procedures that fall under the LSP state cleanup category MUST NOT be turned on if any of the nodes involved in the node protection FRR (i.e., the PLR, the MP, and the intermediate node in the case of NP) do not support RI-RSVP-FRR extensions. Note that for LSPs requesting link protection, only the PLR and the LP-MP MUST support the extensions.

Detecting Support for Refresh-Interval Independent RSVP FRR An implementation supporting RI-RSVP-FRR extensions MUST set the RI-RSVP Capable flag in the CAPABILITY object carried in Hello messages as specified in RSVP-TE Scaling Techniques . If an implementation does not set the flag even if it supports RI-RSVP-FRR extensions, then its neighbors will view the node as any node that does not support the extensions.

As nodes supporting the RI-RSVP-FRR extensions initiate Node-ID-based signaling adjacency with all immediate neighbors, such a node on the path of a protected LSP can determine whether its PHOP and NHOP neighbors support RI-RSVP-FRR enhancements.
As nodes supporting the RI-RSVP-FRR extensions also initiate Node-ID-based signaling adjacency with the NNHOP along the path of the LSP requesting node protection (see of this document), each node along the LSP can determine whether its NNHOP node supports RI-RSVP-FRR enhancements. If the NNHOP (a) does not reply to remote Node-ID Hello messages or (b) does not set the RI-RSVP flag in the CAPABILITY object carried in its Node-ID Hello messages, then the node acting as the PLR can conclude that NNHOP does not support RI-RSVP-FRR extensions.
If node protection is requested for an LSP and if (a) the PPHOP node has not included a matching B-SFRR-Ready Extended ASSOCIATION object in its Path messages, (b) the PPHOP node has not initiated remote Node-ID Hello messages, or (c) the PPHOP node does not set the RI-RSVP flag in the CAPABILITY object carried in its Node-ID Hello messages, then the node MUST conclude that the PLR does not support RI-RSVP-FRR extensions.

Procedures for Backward Compatibility Every node that supports RI-RSVP-FRR MUST support the procedures defined in this section in order to support backward compatibility for those subsets of LSPs that also traverse nodes that do not support RI-RSVP-FRR.

Lack of Support on Downstream Nodes The procedures on the downstream direction are as follows:

If a node finds that the NHOP node along the LSP does not support the RI-RSVP-FRR extensions, then the node MUST reduce the "refresh period" in the TIME_VALUES object carried in the Path messages to the default short refresh interval.
If node protection is requested for the LSP and the NNHOP node along the LSP does not support the RI-RSVP-FRR extensions, then the node MUST reduce the "refresh period" in the TIME_VALUES object carried in the Path messages to the default short refresh interval.

If a node reduces the refresh time using the above procedures, it MUST NOT send any "Remote" PathTear or Conditional PathTear message to the downstream node. Consider the example topology in . If C does not support the RI-RSVP-FRR extensions, then:

A and B reduce the refresh time to the default short refresh interval of 30 seconds and trigger a Path message.
If B is not an MP and if the PHOP link of B fails, B cannot send a Conditional PathTear to C but times out the PSB state from A normally. Note that B can only normally time out the PSB state A if A did not set the long refresh in the TIME_VALUES object carried in the Path messages sent earlier.

Lack of Support on Upstream Nodes The procedures on the upstream direction are as follows:

If a node finds that the PHOP node along the LSP does not support the RI-RSVP-FRR extensions, then the node MUST reduce the "refresh period" in the TIME_VALUES object carried in the Resv messages to the default short refresh interval.
If node protection is requested for the LSP and the PHOP node along the LSP does not support the RI-RSVP-FRR extensions, then the node MUST reduce the "refresh period" in the TIME_VALUES object carried in the Path messages to the default short refresh interval (thus, the NHOP can use compatible values when sending a Resv).
If node protection is requested for the LSP and the PPHOP node does not support the RI-RSVP-FRR extensions, then the node MUST reduce the "refresh period" in the TIME_VALUES object carried in the Resv messages to the default short refresh interval.
If the node reduces the refresh time using the above procedures, it MUST NOT execute MP procedures specified in of this document.

Incremental Deployment The backward compatibility procedures described in the previous subsections imply that a router supporting the RI-RSVP-FRR extensions specified in this document can apply the procedures specified in this document either in the downstream or upstream direction of an LSP, depending on the capability of the routers downstream or upstream in the LSP.

RI-RSVP-FRR extensions and procedures are enabled for downstream Path, PathTear, and ResvErr messages corresponding to an LSP if link protection is requested for the LSP and the NHOP node supports the extensions.
RI-RSVP-FRR extensions and procedures are enabled for downstream Path, PathTear, and ResvErr messages corresponding to an LSP if node protection is requested for the LSP and both NHOP and NNHOP nodes support the extensions.
RI-RSVP-FRR extensions and procedures are enabled for upstream PathErr, Resv, and ResvTear messages corresponding to an LSP if link protection is requested for the LSP and the PHOP node supports the extensions.
RI-RSVP-FRR extensions and procedures are enabled for upstream PathErr, Resv, and ResvTear messages corresponding to an LSP if node protection is requested for the LSP and both PHOP and PPHOP nodes support the extensions.

For example, if an implementation supporting the RI-RSVP-FRR extensions specified in this document is deployed on all routers in a particular region of the network and if all the LSPs in the network request node protection, then the FRR extensions will only be applied for the LSP segments that traverse the particular region. This will aid incremental deployment of these extensions and also allow reaping the benefits of the extensions in portions of the network where it is supported.

Consequences of Advertising RI-RSVP Without RI-RSVP-FRR If a node supporting facility backup protection sets the RI-RSVP capability (I-bit) but does not support the RI-RSVP-FRR extensions, due to an implementation bug or configuration error, then it leaves room for the stale state to linger around for an inordinate period of time or for disruption of normal FRR operations (see of this document). Consider the example topology () provided in this document.

Assume node B does set the RI-RSVP capability in its Node-ID-based Hello messages even though it does not support RI-RSVP-FRR extensions. When B detects the failure of its PHOP link along an LSP, it will not send a Conditional PathTear to C as required by the RI-RSVP-FRR procedures. If B simply leaves the LSP state without deleting, then B may end up holding on to the stale state until the (long) refresh timeout.
Instead of node B, assume node C does set the RI-RSVP capability in its Node-ID-based Hello messages even though it does not support RI-RSVP-FRR extensions. When B details the failure of its PHOP link along an LSP, it will send a Conditional PathTear to C as required by the RI-RSVP-FRR procedures. However, C would not recognize the condition encoded in the PathTear and end up tearing down the LSP.
Assume node B does set the RI-RSVP capability in its Node-ID-based Hello messages even though it does not support RI-RSVP-FRR extensions. In addition, assume local repair is about to commence on node B for an LSP that has only requested link protection, that is, B has not initiated the backup LSP signaling for the LSP. If node B receives a normal PathTear at this time from ingress A because of a management event initiated on A, then B simply deletes the LSP state without sending a Remote PathTear to the LP-MP C, so C may end up holding on to the stale state until the (long) refresh timeout.

Bit Number	32-Bit Value	Name	Reference
0-30		Unassigned
31	0x0001	Merge-point	RFC 9705