MPLS Working Group C. Ramachandran Internet-Draft T. Saad Updates: 4090 (if approved) Juniper Networks, Inc. Intended status: Standards Track I. Minei Expires: May 21, 2021 Google, Inc. D. Pacella Verizon, Inc. November 17, 2020 Refresh-interval Independent FRR Facility Protection draft-ietf-mpls-ri-rsvp-frr-08 Abstract RSVP-TE Fast ReRoute extensions specified in RFC 4090 defines two local repair techniques to reroute Label Switched Path (LSP) traffic over pre-established backup tunnel. Facility backup method allows one or more LSPs traversing a connected link or node to be protected using a bypass tunnel. The many-to-one nature of local repair technique is attractive from scalability point of view. This document enumerates facility backup procedures in RFC 4090 that rely on refresh timeout and hence make facility backup method refresh- interval dependent. The RSVP-TE extensions defined in this document will enhance the facility backup protection mechanism by making the corresponding procedures refresh-interval independent and hence compatible with Refresh-interval Independent RSVP (RI-RSVP) specified in RFC 8370. Hence, this document updates RFC 4090 in order to support RI-RSVP capability specified in RFC 8370. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any Ramachandran, et al. Expires May 21, 2021 [Page 1] Internet-Draft RI-RSVP FRR Bypass November 2020 time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on May 21, 2021. Copyright Notice Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Problem Description . . . . . . . . . . . . . . . . . . . . . 5 4. Solution Aspects . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Requirement on RFC 4090 Capable Node to advertise RI-RSVP Capability . . . . . . . . . . . . . . . . . . . . . . . 8 4.2. Signaling Handshake between PLR and MP . . . . . . . . . 8 4.2.1. PLR Behavior . . . . . . . . . . . . . . . . . . . . 8 4.2.2. Remote Signaling Adjacency . . . . . . . . . . . . . 10 4.2.3. MP Behavior . . . . . . . . . . . . . . . . . . . . . 10 4.2.4. "Remote" State on MP . . . . . . . . . . . . . . . . 11 4.3. Impact of Failures on LSP State . . . . . . . . . . . . . 12 4.3.1. Non-MP Behavior . . . . . . . . . . . . . . . . . . . 12 4.3.2. LP-MP Behavior . . . . . . . . . . . . . . . . . . . 12 4.3.3. NP-MP Behavior . . . . . . . . . . . . . . . . . . . 13 4.3.4. Behavior of a Router that is both LP-MP and NP-MP . . 14 4.4. Conditional PathTear . . . . . . . . . . . . . . . . . . 15 4.4.1. Sending Conditional PathTear . . . . . . . . . . . . 15 4.4.2. Processing Conditional PathTear . . . . . . . . . . . 15 4.4.3. CONDITIONS Object . . . . . . . . . . . . . . . . . . 16 4.5. Remote State Teardown . . . . . . . . . . . . . . . . . . 16 4.5.1. PLR Behavior on Local Repair Failure . . . . . . . . 17 4.5.2. PLR Behavior on Resv RRO Change . . . . . . . . . . . 17 4.5.3. LSP Preemption during Local Repair . . . . . . . . . 18 4.5.3.1. Preemption on LP-MP after Phop Link Failure . . . 18 Ramachandran, et al. Expires May 21, 2021 [Page 2] Internet-Draft RI-RSVP FRR Bypass November 2020 4.5.3.2. Preemption on NP-MP after Phop Link Failure . . . 18 4.6. Backward Compatibility Procedures . . . . . . . . . . . . 19 4.6.1. Detecting Support for Refresh interval Independent FRR . . . . . . . . . . . . . . . . . . . . . . . . . 19 4.6.2. Procedures for Backward Compatibility . . . . . . . . 20 4.6.2.1. Lack of support on Downstream Node . . . . . . . 20 4.6.2.2. Lack of support on Upstream Node . . . . . . . . 20 4.6.2.3. Incremental Deployment . . . . . . . . . . . . . 21 5. Security Considerations . . . . . . . . . . . . . . . . . . . 22 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 6.1. New Object - CONDITIONS . . . . . . . . . . . . . . . . . 22 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 9.1. Normative References . . . . . . . . . . . . . . . . . . 23 9.2. Informative References . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 1. Introduction RSVP-TE relies on periodic refresh of RSVP messages to synchronize and maintain the Label Switched Path (LSP) related states along the reserved path. In the absence of refresh messages, the LSP-related states are automatically deleted. Reliance on periodic refreshes and refresh timeouts are problematic from the scalability point of view. The number of RSVP-TE LSPs that a router needs to maintain has been growing in service provider networks and the implementations should be capable of handling increase in LSP scale. RFC 2961 specifies mechanisms to eliminate the reliance on periodic refresh and refresh timeout of RSVP messages, and enables a router to increase the message refresh interval to values much longer than the default 30 seconds defined in RFC 2205. However, the protocol extensions defined in RFC 4090 for supporting Fast ReRoute (FRR) using bypass tunnels implicitly rely on short refresh timeouts to cleanup stale states. In order to eliminate the reliance on refresh timeouts, the routers should unambiguously determine when a particular LSP state should be deleted. In scenarios involving RFC 4090 FRR using bypass tunnels, additional explicit tear down messages are necessary. Refresh- interval Independent RSVP FRR (RI-RSVP-FRR) extensions specified in this document consists of procedures to enable LSP state cleanup that are essential in supporting RI-RSVP capability for RFC 4090 FRR using bypass tunnels. Ramachandran, et al. Expires May 21, 2021 [Page 3] Internet-Draft RI-RSVP FRR Bypass November 2020 1.1. Motivation Base RSVP [RFC2205] maintains state via the generation of RSVP Path/ Resv refresh messages. Refresh messages are used to both synchronize state between RSVP neighbors and to recover from lost RSVP messages. The use of Refresh messages to cover many possible failures has resulted in a number of operational problems. - One problem relates to RSVP control plane scaling due to periodic refreshes of Path and Resv messages, another relates to the reliability and latency of RSVP signaling. - An additional problem is the time to clean up the stale state after a tear message is lost. For more on these problems see Section 1 of RSVP Refresh Overhead Reduction Extensions [RFC2961]. The problems listed above adversely affect RSVP control plane scalability and RSVP-TE [RFC3209] inherited these problems from standard RSVP. Procedures specified in [RFC2961] address the above mentioned problems by eliminating dependency on refreshes for state synchronization and for recovering from lost RSVP messages, and by eliminating dependency on refresh timeout for stale state cleanup. Implementing these procedures allows implementations to improve RSVP- TE control plane scalability. For more details on eliminating dependency on refresh timeout for stale state cleanup, refer to "Refresh-interval Independent RSVP" section 3 of RSVP-TE Scaling Techniques [RFC8370]. However, the facility backup protection procedures specified in [RFC4090] do not fully address stale state cleanup as the procedures depend on refresh timeouts for stale state cleanup. The updated facility backup protection procedures specified in this document, in combination with RSVP-TE Scaling Techniques [RFC8370], eliminate this dependency on refresh timeouts for stale state cleanup. The procedures specified in this document assume reliable delivery of RSVP messages, as specified in [RFC2961]. Therefore this document makes support for [RFC2961] a pre-requisite. 2. Terminology The reader is expected to be familiar with the terminology in [RFC2205], [RFC3209], [RFC4090] and [RFC4558]. Phop node: Previous-hop router along the label switched path PPhop node: Previous-Previous-hop router along the label switched path Ramachandran, et al. Expires May 21, 2021 [Page 4] Internet-Draft RI-RSVP FRR Bypass November 2020 Nhop node: Next-hop router along the label switched path NNhop node: Next-Next-hop router along the label switched path PLR: Point of Local Repair router as defined in [RFC4090] MP: Merge Point router as defined in [RFC4090] LP-MP node: Merge Point router at the tail of Link-Protecting bypass tunnel NP-MP node: Merge Point router at the tail of Node-Protecting bypass tunnel TED: Traffic Engineering Database LSP state: The combination of "path state" maintained as Path State Block (PSB) and "reservation state" maintained as Reservation State Block (RSB) forms an individual LSP state on an RSVP-TE speaker B-SFRR-Ready: Bypass Summary FRR Ready Extended Association object defined in Summary FRR extensions [RFC8796] and is added by the PLR for each protected LSP. Conditional PathTear: A PathTear message containing a suggestion to a receiving downstream router to retain the path state if the receiving router is an NP-MP Remote PathTear: A PathTear message sent from a Point of Local Repair (PLR) to the MP to delete LSP state on the MP if PLR had not reliably sent the backup Path state before 3. Problem Description Ramachandran, et al. Expires May 21, 2021 [Page 5] Internet-Draft RI-RSVP FRR Bypass November 2020 E / \ / \ / \ / \ / \ / \ A ----- B ----- C ----- D \ / \ / \ / \ / \ / \ / F Figure 1: Example Topology In the topology in Figure 1, let us consider a large number of LSPs from A to D transiting B and C. Assume that refresh interval has been configured to be long of the order of minutes and refresh reduction extensions are enabled on all routers. Also let us assume that node protection has been configured for the LSPs and the LSPs are protected by each router in the following way - A has made node protection available using bypass LSP A -> E -> C; A is the PLR and C is the NP-MP - B has made node protection available using bypass LSP B -> F -> D; B is the PLR and D is the NP-MP - C has made link protection available using bypass LSP C -> B -> F -> D; C is the PLR and D is the LP-MP In the above condition, assume that B-C link fails. The following is the sequence of events that is expected to occur for all protected LSPs under normal conditions. 1. B performs local repair and re-directs LSP traffic over the bypass LSP B -> F -> D. 2. B also creates backup state for the LSP and triggers sending of backup LSP state to D over the bypass LSP B -> F -> D. 3. D receives backup LSP states and merges the backups with the protected LSPs. Ramachandran, et al. Expires May 21, 2021 [Page 6] Internet-Draft RI-RSVP FRR Bypass November 2020 4. As the link on C, over which the LSP states are refreshed, has failed, C will no longer receive state refreshes. Consequently the protected LSP states on C will time out and C will send the tear down messages for all LSPs. As each router should consider itself as an MP, C will time out the state only after waiting for an additional duration equal to refresh timeout. While the above sequence of events has been described in [RFC4090], there are a few problems for which no mechanism has been specified explicitly. - If the protected LSP on C times out before D receives signaling for the backup LSP, then D would receive a PathTear from C prior to receiving signaling for the backup LSP, thus resulting in deleting the LSP state. This would be possible at scale even with default refresh time. - If upon the link failure C is to keep state until its timeout, then with long refresh interval this may result in a large amount of stale state on C. Alternatively, if upon the link failure C is to delete the state and send a PathTear to D, this would result in deleting the state on D, thus deleting the LSP. D needs a reliable mechanism to determine whether it is an MP or not to overcome this problem. - If head-end A attempts to tear down LSP after step 1 but before step 2 of the above sequence, then B may receive the tear down message before step 2 and delete the LSP state from its state database. If B deletes its state without informing D, with long refresh interval this could cause (large) buildup of stale state on D. - If B fails to perform local repair in step 1, then B will delete the LSP state from its state database without informing D. As B deletes its state without informing D, with long refresh interval this could cause (large) buildup of stale state on D. The purpose of this document is to provide solutions to the above problems which will then make it practical to scale up to a large number of protected LSPs in the network. 4. Solution Aspects The solution consists of five parts. - Utilize MP determination mechanism specified in RSVP-TE Summary FRR [RFC8796] that enables the PLR to signal the availability of local protection to the MP. In addition, introduce PLR and MP Ramachandran, et al. Expires May 21, 2021 [Page 7] Internet-Draft RI-RSVP FRR Bypass November 2020 procedures to to establish Node-ID based hello session between the PLR and the MP to detect router failures and to determine capability. See section 4.2 for more details. This part of the solution re-uses some of the extensions defined in RSVP-TE Summary FRR [RFC8796] and RSVP-TE Scaling Techniques [RFC8370], and the subsequent sub-sections will list the extensions in these drafts 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 section 4.3 for more details. - Introduce extensions to enable a router to send a tear down message to the downstream router that enables the receiving router to conditionally delete its local LSP state. See section 4.4 for more details. - Enhance facility protection by allowing a PLR to directly send a tear down message to the MP without requiring the PLR to either have a working bypass LSP or have already signaled backup LSP state. See section 4.5 for more details. - Introduce extensions to enable the above procedures to be backward compatible with routers along the LSP path running implementation that do not support these procedures. See section 4.6 for more details. 4.1. Requirement on RFC 4090 Capable Node to advertise RI-RSVP Capability A node supporting [RFC4090] facility protection FRR MAY set the RI- RSVP capability (I bit) defined in Section 3 of RSVP-TE Scaling Techniques [RFC8370] only if it supports all the extensions specified in the rest of this document. A node supporting [RFC4090] facility bypass FRR but not supporting the extensions specified in this document MUST reset the RI-RSVP capability (I bit) in the outgoing Node-ID based Hello messages. Hence, this document updates [RFC4090] by defining extensions and additional procedures over facility protection FRR defined in [RFC4090] in order to advertise RI-RSVP capability [RFC8370]. 4.2. Signaling Handshake between PLR and MP 4.2.1. PLR Behavior As per the procedures specified in [RFC4090], when a protected LSP comes up and if the "local protection desired" flag is set in the Ramachandran, et al. Expires May 21, 2021 [Page 8] Internet-Draft RI-RSVP FRR Bypass November 2020 SESSION_ATTRIBUTE object, each node along the LSP path 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 a NP-bypass LSP to the NNhop node avoiding the Nhop node on protected LSP path. 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 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 that are specified in [RFC4090], this document specifies the following additional procedures to support RI-RSVP defined in [RFC8370]. - While selecting the destination address of the bypass LSP, the PLR SHOULD select the router ID of the NNhop or Nhop node from the Node-ID sub-object included in the RRO object carried in the Resv message. 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 included by the MP in the RRO object. If the NP-MP in a different IGP area has not included a Node-ID sub- object in RRO object, 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 Section 4.6.2.1). - The PLR MUST also include its router ID in a Node-ID sub-object in RRO object carried in a Path message. While including its router ID in the Node-ID sub-object carried in the outgoing Path message, 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 NP-bypass or LP-bypass, the PLR MUST initiate a Node-ID based Hello session to the NNhop or Nhop node respectively to establish the RSVP-TE signaling adjacency. This Hello session is used to detect MP node failure as well as determine the capability of the MP node. If the MP has set the I-bit in the CAPABILITY object [RFC8370] carried in Hello message corresponding to the Node-ID based Hello session, then the PLR SHOULD conclude that the MP supports refresh-interval independent FRR procedures defined in this document. If the MP has not sent Node-ID based Hello messages or has not set the I-bit in CAPABILITY object [RFC8370], then the PLR MUST execute backward Ramachandran, et al. Expires May 21, 2021 [Page 9] Internet-Draft RI-RSVP FRR Bypass November 2020 compatibility procedures defined in Section 4.6.2.1 of this document. - If the bypass LSP comes up and the PLR has made local protection available for one or more LSPs, then RSVP-TE Summary FRR [RFC8796] applies: the PLR MUST include B-SFRR-Ready Extended Association object and trigger a Path message to be sent for those LSPs. If a B-SFRR-Ready Extended Association object is included in the Path message, then the encoding and object ordering rules specified in RSVP-TE Summary FRR [RFC8796] MUST be followed. 4.2.2. Remote Signaling Adjacency A Node-ID based RSVP-TE Hello session is one in which Node-ID is used in the source and the destination address fields of RSVP Hello messages [RFC4558]. This document extends Node-ID based RSVP Hello session 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 session between any two routers that are not immediate neighbors, the router that supports the extensions defined in the document MUST set 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 SHOULD be set to the default specified in RSVP-TE Scaling Techniques [RFC8370]. In the rest of the document the term "signaling adjacency", or "remote signaling adjacency" refers specifically to the RSVP-TE signaling adjacency. 4.2.3. MP Behavior With regard to the MP procedures that are defined in [RFC4090] this document specifies the following additional procedures to support RI- RSVP defined in [RFC8370]. Each node along an LSP path supporting the extensions defined in this document MUST also include its router ID in the Node-ID sub-object of the RRO object carried in the Resv message of the LSPs. If the PLR has not included a Node-ID sub-object in the RRO object 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 Section 4.6.2.2 as if the upstream nodes along the LSP do not support the extensions defined in this document. A node receiving Path messages should determine whether they contain a B-SFRR-Ready Extended Association object with the Node-ID address Ramachandran, et al. Expires May 21, 2021 [Page 10] Internet-Draft RI-RSVP FRR Bypass November 2020 of the PLR as the source and its own Node-ID as the destination. In addition the node should determine whether it has an operational remote Node-ID signaling adjacency with the PLR. If either the PLR has not included the B-SFRR-Ready Extended Association object or if there is no operational Node-ID signaling adjacency with the PLR or if the PLR has not advertised RI-RSVP capability in its Node-ID based Hello messages, then the node MUST execute backward compatibility procedures defined in Section 4.6.2.2. If a matching B-SFRR-Ready Extended Association object is found in the Path message and if there is an operational remote signaling adjacency with the PLR that has advertised RI-RSVP capability (I-bit) [RFC8370] in its Node-ID based Hello messages, then the node SHOULD consider itself as the MP for the corresponding PLR. The matching and ordering rules for Bypass Summary FRR Extended Association specified in RSVP-TE Summary FRR [RFC8796] 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 SHOULD 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 SHOULD conclude it is the LP-MP. 4.2.4. "Remote" State on MP Once a router concludes it is the MP for a PLR running refresh- interval independent FRR procedures, it SHOULD 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 SHOULD consider the "remote" path state automatically deleted if: - The MP later receives a Path with no matching B-SFRR-Ready Extended Association object corresponding to the PLR's IP address contained in the Path RRO, or - The Node-ID signaling adjacency with the PLR goes down, or - The MP receives backup LSP signaling from the PLR or Ramachandran, et al. Expires May 21, 2021 [Page 11] Internet-Draft RI-RSVP FRR Bypass November 2020 - The MP receives a PathTear, or - The MP deletes the LSP state on local policy or exception event Unlike the normal path state that is either locally generated on the ingress or created by a Path message from the Phop node, the "remote" path state is not signaled explicitly from the PLR. 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 "remote" path state is called "Remote" PathTear. The scenarios in which a "Remote" PathTear is applied are described in Section 4.5. 4.3. Impact of Failures on LSP State This section describes the procedures for routers on the LSP path for different kinds of failures. The procedures described on detecting RSVP control plane adjacency failures do not impact the RSVP-TE graceful restart mechanisms ([RFC3473], [RFC5063]). If the router executing these procedures act as helper for neighboring router, then the control plane adjacency will be declared as having failed after taking into account the grace period extended for neighbor by the helper. Node failures are detected from the state of Node-ID hello sessions established with immediate neighbors. RSVP-TE Scaling Techniques [RFC8370] recommends each router to establish Node-ID hello sessions with all its immediate neighbors. PLR or MP node failure is detected from the state of remote signaling adjacency established according to Section 4.2.2 of this document. 4.3.1. Non-MP Behavior When a router detects Phop link or Phop node failure and the router is not an MP for the LSP, then it SHOULD send a Conditional PathTear (refer to Section 4.4 "Conditional PathTear" below) and delete the PSB and RSB states corresponding to the LSP. 4.3.2. 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 till the occurrence of any of the following events. - The Node-ID signaling adjacency with the Phop PLR goes down, or Ramachandran, et al. Expires May 21, 2021 [Page 12] Internet-Draft RI-RSVP FRR Bypass November 2020 - 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 SHOULD send a normal PathTear and delete the PSB and RSB states corresponding to the LSP. 4.3.3. 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 till the occurrence of any of the following events. - The remote Node-ID signaling adjacency with the PPhop PLR goes down, or - 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 does not detect Phop link or 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 till the occurrence of any of the following events. - The remote Node-ID signaling adjacency with the PPhop PLR goes down, or - 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 Phop node would send a Conditional PathTear if it was not an MP. In the example topology in Figure 1, we assume C & D are the NP-MPs for the PLRs A & B respectively. Now when A-B link fails, as B is not an MP and its Phop link has failed, B will delete LSP state (this behavior is required for unprotected LSPs - Section 4.3.1). In the data plane, that would require B to delete the label forwarding entry corresponding to the LSP. So 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. Ramachandran, et al. Expires May 21, 2021 [Page 13] Internet-Draft RI-RSVP FRR Bypass November 2020 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. 1. When C receives a Conditional PathTear from B, it decides to retain LSP state as it is the NP-MP of the PLR A. C also SHOULD check whether Phop B had previously signaled availability of node protection. As B had previously signaled NP availability by including B-SFRR-Ready Extended Association object, C SHOULD remove the B-SFRR-Ready Extended Association object containing Association Source set to B from the Path message and trigger a Path to D. 2. When D receives a triggered Path, 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. 4.3.4. Behavior of a Router that is both LP-MP and NP-MP A router may be simultaneously the LP-MP as well as the NP-MP for the Phop and the PPhop nodes respectively of an LSP. If Phop link fails on such node, the node MUST retain the PSB and RSB states corresponding to the LSP till the occurrence of any of the following events. - Both Node-ID signaling adjacencies with Phop and PPhop nodes go down, or - 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 LP-MP and NP-MP detects Phop node failure, then the node MUST retain the PSB and RSB states corresponding to the LSP till the occurrence of any of the following events. - The remote Node-ID signaling adjacency with the PPhop PLR goes down, or - The MP receives a normal or "Remote" PathTear for its PSB, or - The MP receives a ResvTear for its RSB. Ramachandran, et al. Expires May 21, 2021 [Page 14] Internet-Draft RI-RSVP FRR Bypass November 2020 4.4. Conditional PathTear In the example provided in the Section 4.3.3, B deletes the PSB and RSB states corresponding to the LSP once B detects its link to Phop went down as B is not an MP. If B were to send a PathTear normally, then C would delete 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 SHOULD add a new optional CONDITIONS object in the PathTear. The CONDITIONS object is defined in Section 4.4.3. If node C also understands the new object, then C SHOULD delete LSP state only if it is not an NP-MP - in other words C SHOULD delete LSP state if there is no "remote" PLR path state on C. 4.4.1. Sending Conditional PathTear A router that is not an MP for an LSP SHOULD delete the PSB and RSB states corresponding to the LSP if the Phop link or the Phop Node-ID signaling adjacency goes down (Section 4.3.1). The router SHOULD 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 4.4.2. Processing Conditional PathTear When a router that is not an NP-MP receives a Conditional PathTear, the node SHOULD 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 LSP state. The node SHOULD 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 SHOULD 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 Section 4.6) for the new procedures defined in this document, then the node SHOULD consider the message as a normal PathTear. The node SHOULD propagate the normal PathTear downstream and delete the LSP state. Ramachandran, et al. Expires May 21, 2021 [Page 15] Internet-Draft RI-RSVP FRR Bypass November 2020 4.4.3. CONDITIONS Object As any implementation that does not support Conditional PathTear SHOULD ignore the new object but process the message as a normal PathTear without generating any error, the Class-Num of the new object MUST be 10bbbbbb where 'b' represents a bit (from Section 3.10 of [RFC2205]). The new object is called as "CONDITIONS" object that will specify the conditions under which default processing rules of the RSVP-TE message MUST be invoked. The object has the following format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Class | C-type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved |M| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: CONDITIONS Object Length: This contains the size of the object in bytes and should be set to eight. Class: To be assigned C-type: 1 M bit: If the M bit is set to 1, then the PathTear message SHOULD be processed according to the receiver router role, i.e. if it is an MP or not. If M-bit is set to 0, then the PathTear message SHOULD be processed as a normal PathTear message. 4.5. 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 till the completion of backup LSP signaling to perform state cleanup. To enable LSP state cleanup when the LSP is being locally repaired, the PLR SHOULD 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 SHOULD be set to 255. Ramachandran, et al. Expires May 21, 2021 [Page 16] Internet-Draft RI-RSVP FRR Bypass November 2020 Let us consider that node C, in example topology (Figure 1), has gone down and B locally repairs the LSP. 1. Ingress A receives a management event to tear down the LSP. 2. A sends a normal PathTear to B. 3. Assume B has not initiated backup signaling for the LSR. To enable LSP state cleanup, B SHOULD send a "Remote" PathTear with destination IP address set to that of D used in the Node-ID signaling adjacency with D, and RSVP_HOP object containing local address used in the Node-ID signaling adjacency. 4. B then deletes the PSB and RSB states corresponding to the LSP. 5. On D there would be a remote signaling adjacency with B and so D SHOULD accept the "Remote" PathTear and delete the PSB and RSB states corresponding to the LSP. 4.5.1. PLR Behavior on Local Repair Failure If local repair fails on the PLR after a failure, then this should be considered as a case for cleaning up LSP state from the PLR to the Egress. The PLR would achieve this using "Remote" PathTear to clean up the state from the MP. If the MP has retained the LSP state, then it would propagate the PathTear downstream thereby achieving state cleanup. Note that in the case of link protection, the PathTear would be directed to the LP-MP node's IP address rather than the Nhop interface address. 4.5.2. PLR Behavior on Resv RRO Change When a PLR router that has already made NP available detects a change in the RRO carried in the Resv message indicating that the router's former NP-MP is no longer present in the LSP path, then the router SHOULD send a "Remote" PathTear directly to its former NP-MP. In the example topology in Figure 1, let us assume A has made node protection available 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 Section 4.3.4 of this document, will retain state till: 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 with a new RRO not containing C - its former NP- MP, A SHOULD send a "Remote" PathTear to C. When C receives the Ramachandran, et al. Expires May 21, 2021 [Page 17] Internet-Draft RI-RSVP FRR Bypass November 2020 "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 control plane and forwarding states corresponding to the LSP. 4.5.3. LSP Preemption during Local Repair 4.5.3.1. Preemption on LP-MP after Phop Link Failure If an LSP is preempted on an LP-MP after its Phop or incoming link has already failed but the backup LSP has not been signaled yet, then the node SHOULD send a normal PathTear and delete both the PSB and RSB states corresponding to the LSP. As the LP-MP has retained LSP state expecting the PLR to perform backup LSP signaling, preemption would bring down the LSP and the node would not be LP-MP any more requiring the node to clean up LSP state. 4.5.3.2. 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 SHOULD send a normal PathTear and delete the PSB and RSB states corresponding to the LSP. As the NP-MP has retained LSP state expecting the PLR to perform backup LSP signaling, preemption would bring down the LSP and the node would not be NP-MP any more requiring the node to clean up LSP state. Let us consider that B-C link goes down on the same example topology (Figure 1). As C is the NP-MP for the PLR A, C will retain LSP state. 1. The LSP is preempted on C. 2. C will delete the RSB state corresponding to the LSP. But C cannot send a PathErr or a ResvTear to the PLR A because the backup LSP has not been signaled yet. 3. As the only reason for C having retained state after Phop node failure was that it was an NP-MP, C SHOULD send a normal PathTear to D and delete its PSB state also. D would also delete the PSB and RSB states on receiving a PathTear from C. 4. B starts backup LSP signaling to D. But as D does not have the LSP state, it will reject the backup LSP Path and send a PathErr to B. 5. B will delete its reservation and send a ResvTear to A. Ramachandran, et al. Expires May 21, 2021 [Page 18] Internet-Draft RI-RSVP FRR Bypass November 2020 4.6. Backward Compatibility Procedures The "Refresh interval Independent FRR" or RI-RSVP-FRR referred below in this section refers to the changes that have been defined in previous sections. Any implementation that does not support them has been termed as "non-RI-RSVP-FRR implementation". The extensions proposed in RSVP-TE Summary FRR [RFC8796] are applicable to implementations that do not support RI-RSVP-FRR. On the other hand, changes proposed relating to LSP state cleanup namely Conditional and "Remote" PathTear require support from one-hop and two-hop neighboring nodes along the LSP path. So procedures that fall under LSP state cleanup category SHOULD be turned on only if all nodes involved in the node protection FRR i.e. the PLR, the MP and the intermediate node in the case of NP, support the extensions. Note that for LSPs requesting only link protection, the PLR and the LP-MP need to support the extensions. 4.6.1. Detecting Support for Refresh interval Independent FRR An implementation supporting the extensions specified in previous sections (called RI-RSVP-FRR here after) SHOULD set the flag "Refresh interval Independent RSVP" or RI-RSVP flag in the CAPABILITY object carried in Hello messages. The RI-RSVP flag is specified in RSVP-TE Scaling Techniques [RFC8370]. - As nodes supporting the extensions SHOULD initiate Node Hellos with adjacent nodes, a node on the path of protected LSP can determine whether its Phop or Nhop neighbor supports RI-RSVP-FRR enhancements from the Hello messages sent by the neighbor. - If a node attempts to make node protection available, then the PLR SHOULD initiate a remote Node-ID signaling adjacency with its NNhop. If the NNhop (a) does not reply to remote node Hello message or (b) does not set the RI-RSVP flag in the CAPABILITY object carried in its Node-ID Hello messages, then 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 or (b) the PPhop node has not initiated remote node 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. The details are described in the "Procedures for Backward Compatibility" section below. Ramachandran, et al. Expires May 21, 2021 [Page 19] Internet-Draft RI-RSVP FRR Bypass November 2020 4.6.2. Procedures for Backward Compatibility The procedures defined hereafter are performed on a subset of LSPs that traverse a node, rather than on all LSPs that traverse a node. This behavior is required to support backward compatibility for a subset of LSPs traversing nodes running non-RI-RSVP-FRR implementations. 4.6.2.1. Lack of support on Downstream Node The procedures on the downstream direction are as follows. - If the Nhop does not support the RI-RSVP-FRR extensions, then the node SHOULD reduce the "refresh period" in the TIME_VALUES object carried in the Path to the default short refresh interval. - If node protection is requested and the NNhop node does not support the enhancements, then the node SHOULD reduce the "refresh period" in the TIME_VALUES object carried in the Path to the default short refresh interval. If the node reduces the refresh time from the above procedures, it MUST NOT send any "Remote" PathTear or Conditional PathTear messages. Consider the example topology in Figure 1. If C does not support the RI-RSVP-FRR extensions, then: - A and B SHOULD reduce the refresh time to default short refresh interval of 30 seconds and trigger a Path - If B is not an MP and if Phop link of B fails, B cannot send Conditional PathTear to C but MUST time out the PSB state from A normally. This would be accomplished if A would also reduce the refresh time to default value. So if C does not support the RI- RSVP-FRR extensions, then Phop B and the PPhop A SHOULD reduce the refresh period to the default short refresh interval. 4.6.2.2. Lack of support on Upstream Node The procedures are as follows. - If Phop node does not support the RI-RSVP-FRR extensions, then the node SHOULD reduce the "refresh period" in the TIME_VALUES object carried in the Resv to the default short refresh interval. - If node protection is requested and the Phop node does not support the RI-RSVP-FRR extensions, then the node SHOULD reduce the "refresh period" in the TIME_VALUES object carried in the Path to Ramachandran, et al. Expires May 21, 2021 [Page 20] Internet-Draft RI-RSVP FRR Bypass November 2020 the default short refresh interval (thus, the Nhop can use compatible values when sending a Resv). - If node protection is requested and the PPhop node does not support the RI-RSVP-FRR extensions, then the node SHOULD reduce the "refresh period" in the TIME_VALUES object carried in the Resv to the default short refresh interval. - If the node reduces the refresh time from the above procedures, it SHOULD also not execute MP procedures specified in Section 4.3 of this document. 4.6.2.3. Incremental Deployment The backward compatibility procedures described in the previous sub- sections imply that a router supporting the RI-RSVP-FRR extensions specified in this document can apply the procedures specified in the document either in the downstream or upstream direction of an LSP, depending on the capability of the routers downstream or upstream in the LSP path. - 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 & 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 the PPhop support the extensions For example, if an implementation supporting the RI-RSVP-FRR extensions specified in this document is deployed on all routers in 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 Ramachandran, et al. Expires May 21, 2021 [Page 21] Internet-Draft RI-RSVP FRR Bypass November 2020 the benefits of the extensions in portions of the network where it is supported. 5. Security Considerations The security considerations pertaining to the original RSVP protocol [RFC2205], [RFC3209] and [RFC5920] remain relevant. This document extends the applicability of Node-ID based Hello session between immediate neighbors. The Node-ID based Hello session between the PLR and the NP-MP may require the two routers to exchange Hello messages with non-immediate neighbor. So, the implementations SHOULD provide the option to configure Node-ID neighbor specific or global authentication key to authentication messages received from Node-ID neighbors. The network administrator MAY utilize this option to enable RSVP-TE routers to authenticate Node-ID Hello messages received with TTL greater than 1. Implementations SHOULD also provide the option to specify a limit on the number of Node-ID based Hello sessions that can be established on a router supporting the extensions defined in this document. 6. IANA Considerations 6.1. New Object - CONDITIONS RSVP Change Guidelines [RFC3936] defines the Class-Number name space for RSVP objects. The name space is managed by IANA. IANA registry: RSVP Parameters Subsection: Class Names, Class Numbers, and Class Types A new RSVP object using a Class-Number from 128-183 range called the "CONDITIONS" object is defined in Section 4.4 of this document. The Class-Number from 128-183 range will be allocated by IANA. 7. Acknowledgements We are very grateful to Yakov Rekhter for his contributions to the development of the idea and thorough review of content of the draft. Thanks to Raveendra Torvi and Yimin Shen for their comments and inputs. 8. Contributors Markus Jork 128 Technology Email: mjork@128technology.net Ramachandran, et al. Expires May 21, 2021 [Page 22] Internet-Draft RI-RSVP FRR Bypass November 2020 Harish Sitaraman Individual Contributor Email: harish.ietf@gmail.com Vishnu Pavan Beeram Juniper Networks, Inc. Email: vbeeram@juniper.net Ebben Aries Arrcus, Inc. Email: exa@arrcus.com Mike Taillon Cisco Systems, Inc. Email: mtaillon@cisco.com 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, September 1997, . [RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., and S. Molendini, "RSVP Refresh Overhead Reduction Extensions", RFC 2961, DOI 10.17487/RFC2961, April 2001, . [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, . [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol- Traffic Engineering (RSVP-TE) Extensions", RFC 3473, DOI 10.17487/RFC3473, January 2003, . Ramachandran, et al. Expires May 21, 2021 [Page 23] Internet-Draft RI-RSVP FRR Bypass November 2020 [RFC3936] Kompella, K. and J. Lang, "Procedures for Modifying the Resource reSerVation Protocol (RSVP)", BCP 96, RFC 3936, DOI 10.17487/RFC3936, October 2004, . [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, DOI 10.17487/RFC4090, May 2005, . [RFC4558] Ali, Z., Rahman, R., Prairie, D., and D. Papadimitriou, "Node-ID Based Resource Reservation Protocol (RSVP) Hello: A Clarification Statement", RFC 4558, DOI 10.17487/RFC4558, June 2006, . [RFC5063] Satyanarayana, A., Ed. and R. Rahman, Ed., "Extensions to GMPLS Resource Reservation Protocol (RSVP) Graceful Restart", RFC 5063, DOI 10.17487/RFC5063, October 2007, . [RFC8370] Beeram, V., Ed., Minei, I., Shakir, R., Pacella, D., and T. Saad, "Techniques to Improve the Scalability of RSVP-TE Deployments", RFC 8370, DOI 10.17487/RFC8370, May 2018, . [RFC8796] Taillon, M., Saad, T., Ed., Gandhi, R., Deshmukh, A., Jork, M., and V. Beeram, "RSVP-TE Summary Fast Reroute Extensions for Label Switched Path (LSP) Tunnels", RFC 8796, DOI 10.17487/RFC8796, July 2020, . 9.2. Informative References [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, . Authors' Addresses Chandra Ramachandran Juniper Networks, Inc. Email: csekar@juniper.net Ramachandran, et al. Expires May 21, 2021 [Page 24] Internet-Draft RI-RSVP FRR Bypass November 2020 Tarek Saad Juniper Networks, Inc. Email: tsaad@juniper.net Ina Minei Google, Inc. Email: inaminei@google.com Dante Pacella Verizon, Inc. Email: dante.j.pacella@verizon.com Ramachandran, et al. Expires May 21, 2021 [Page 25]