--- 1/draft-ietf-mpls-ri-rsvp-frr-07.txt 2020-11-17 10:13:16.397850123 -0800 +++ 2/draft-ietf-mpls-ri-rsvp-frr-08.txt 2020-11-17 10:13:16.449851443 -0800 @@ -1,22 +1,22 @@ MPLS Working Group C. Ramachandran Internet-Draft T. Saad Updates: 4090 (if approved) Juniper Networks, Inc. Intended status: Standards Track I. Minei -Expires: March 6, 2020 Google, Inc. +Expires: May 21, 2021 Google, Inc. D. Pacella Verizon, Inc. - September 3, 2019 + November 17, 2020 Refresh-interval Independent FRR Facility Protection - draft-ietf-mpls-ri-rsvp-frr-07 + 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 @@ -42,25 +42,25 @@ 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 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 March 6, 2020. + This Internet-Draft will expire on May 21, 2021. Copyright Notice - Copyright (c) 2019 IETF Trust and the persons identified as the + 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 @@ -69,27 +69,27 @@ 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 . . . . . . . . . . . . . . . . . . . . 9 + 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 . . . . . . . . . . . . . . . . . . . 13 + 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 @@ -99,21 +99,21 @@ 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 . . . . . . . . . . . . . . . . . . . . . . . . 23 + 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 @@ -202,22 +202,22 @@ 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 [I-D.ietf-mpls-summary-frr-rsvpte] - and is added by the PLR for each protected LSP. + 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 @@ -308,30 +308,29 @@ 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 [I-D.ietf-mpls-summary-frr-rsvpte] that enables the PLR to - signal the availability of local protection to the MP. In - addition, introduce PLR and MP procedures 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 [I-D.ietf-mpls-summary-frr-rsvpte] - and RSVP-TE Scaling Techniques [RFC8370], and the subsequent sub- - sections will list the extensions in these drafts that are - utilized in this document. + FRR [RFC8796] that enables the PLR to signal the availability of + local protection to the MP. In addition, introduce PLR and MP + 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. @@ -409,27 +409,26 @@ 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 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 [I-D.ietf-mpls-summary-frr- - rsvpte] 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 - [I-D.ietf-mpls-summary-frr-rsvpte] MUST be followed. + 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 @@ -437,21 +436,21 @@ 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 + 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 @@ -469,22 +468,22 @@ 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 [I-D.ietf-mpls-summary-frr-rsvpte] - MUST be followed by the implementations supporting this document. + 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. @@ -840,30 +837,30 @@ to B. 5. B will delete its reservation and send a ResvTear to A. 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 [I-D.ietf-mpls-summary-frr-rsvpte] - 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. + 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 @@ -1044,26 +1040,20 @@ Email: exa@arrcus.com Mike Taillon Cisco Systems, Inc. Email: mtaillon@cisco.com 9. References 9.1. Normative References - [I-D.ietf-mpls-summary-frr-rsvpte] - Taillon, M., Saad, T., Gandhi, R., Deshmukh, A., Jork, M., - and V. Beeram, "RSVP-TE Summary Fast Reroute Extensions - for LSP Tunnels", draft-ietf-mpls-summary-frr-rsvpte-05 - (work in progress), July 2019. - [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, . @@ -1102,32 +1092,38 @@ [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 - Tarek Saad Juniper Networks, Inc. Email: tsaad@juniper.net Ina Minei Google, Inc. Email: inaminei@google.com