--- 1/draft-ietf-mpls-ri-rsvp-frr-11.txt 2021-12-19 03:13:10.267569141 -0800 +++ 2/draft-ietf-mpls-ri-rsvp-frr-12.txt 2021-12-19 03:13:10.319570439 -0800 @@ -1,22 +1,22 @@ -MPLS Working Group C. Ramachandran -Internet-Draft T. Saad +MPLS Working Group C R. Ramachandran +Internet-Draft T S. Saad Updates: 4090 (if approved) Juniper Networks, Inc. -Intended status: Standards Track I. Minei -Expires: December 22, 2021 Google, Inc. - D. Pacella +Intended status: Standards Track I M. Minei +Expires: 22 June 2022 Google, Inc. + D P. Pacella Verizon, Inc. - June 20, 2021 + 19 December 2021 Refresh-interval Independent FRR Facility Protection - draft-ietf-mpls-ri-rsvp-frr-11 + draft-ietf-mpls-ri-rsvp-frr-12 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,77 +42,76 @@ 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 December 22, 2021. + This Internet-Draft will expire on 22 June 2022. Copyright Notice Copyright (c) 2021 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. + 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 Revised BSD License text as + described in Section 4.e of the Trust Legal Provisions and are + provided without warranty as described in the Revised 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 . . . . . . . . . 9 4.2.1. PLR Behavior . . . . . . . . . . . . . . . . . . . . 9 4.2.2. Remote Signaling Adjacency . . . . . . . . . . . . . 10 4.2.3. MP Behavior . . . . . . . . . . . . . . . . . . . . . 10 - 4.2.4. "Remote" State on MP . . . . . . . . . . . . . . . . 11 + 4.2.4. "Remote" State on MP . . . . . . . . . . . . . . . . 12 4.3. Impact of Failures on LSP State . . . . . . . . . . . . . 12 - 4.3.1. Non-MP Behavior . . . . . . . . . . . . . . . . . . . 12 + 4.3.1. Non-MP Behavior . . . . . . . . . . . . . . . . . . . 13 4.3.2. LP-MP Behavior . . . . . . . . . . . . . . . . . . . 13 4.3.3. NP-MP Behavior . . . . . . . . . . . . . . . . . . . 13 - 4.3.4. Behavior of a Router that is both LP-MP and NP-MP . . 14 + 4.3.4. Behavior of a Router that is both LP-MP and NP-MP . . 15 4.4. Conditional PathTear . . . . . . . . . . . . . . . . . . 15 4.4.1. Sending Conditional PathTear . . . . . . . . . . . . 15 - 4.4.2. Processing Conditional PathTear . . . . . . . . . . . 15 + 4.4.2. Processing Conditional PathTear . . . . . . . . . . . 16 4.4.3. CONDITIONS Object . . . . . . . . . . . . . . . . . . 16 4.5. Remote State Teardown . . . . . . . . . . . . . . . . . . 17 - 4.5.1. PLR Behavior on Local Repair Failure . . . . . . . . 17 - 4.5.2. PLR Behavior on Resv RRO Change . . . . . . . . . . . 17 + 4.5.1. PLR Behavior on Local Repair Failure . . . . . . . . 18 + 4.5.2. PLR Behavior on Resv RRO Change . . . . . . . . . . . 18 4.5.3. LSP Preemption during Local Repair . . . . . . . . . 18 4.5.3.1. Preemption on LP-MP after Phop Link Failure . . . 18 - 4.5.3.2. Preemption on NP-MP after Phop Link Failure . . . 18 + 4.5.3.2. Preemption on NP-MP after Phop Link Failure . . . 19 4.6. Backward Compatibility Procedures . . . . . . . . . . . . 19 4.6.1. Detecting Support for Refresh interval Independent - FRR . . . . . . . . . . . . . . . . . . . . . . . . . 19 + FRR . . . . . . . . . . . . . . . . . . . . . . . . . 20 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 . . . . . . . . 21 - 4.6.2.3. Advertising RI-RSVP without RI-RSVP-FRR . . . . . 21 + 4.6.2.3. Advertising RI-RSVP without RI-RSVP-FRR . . . . . 22 4.6.2.4. Incremental Deployment . . . . . . . . . . . . . 22 5. Security Considerations . . . . . . . . . . . . . . . . . . . 23 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 - 6.1. New Object - CONDITIONS . . . . . . . . . . . . . . . . . 23 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 + 6.1. New Object - CONDITIONS . . . . . . . . . . . . . . . . . 24 6.2. CONDITIONS Flags . . . . . . . . . . . . . . . . . . . . 24 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 24 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 9.1. Normative References . . . . . . . . . . . . . . . . . . 24 9.2. Informative References . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 1. Introduction @@ -263,22 +262,22 @@ - 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. + 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. 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 @@ -629,26 +628,26 @@ 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 MUST 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 MUST 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 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. + 2. 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. 4.3.4. Behavior of a Router that is both LP-MP and NP-MP A router may simultaneously be the LP-MP as well as the NP-MP for the Phop and the PPhop nodes respectively of an LSP. If the Phop link fails on such a 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 @@ -730,27 +728,24 @@ 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 + * Length: This contains the size of the object in bytes and should be set to eight. - Class: To be assigned - C-type: 1 - 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 the M-bit is set to 0, then the PathTear message MUST be processed processed as a normal PathTear message for the LSP. 4.5. Remote State Teardown If the ingress wants to tear down the LSP because of a management @@ -762,26 +757,26 @@ corresponding to the LSP. The TTL in the "Remote" PathTear message MUST be set to 255. Let us consider that node C in the example topology (Figure 1) has gone down and node B locally repairs the LSP. 1. Ingress A receives a management event to tear down the LSP. 2. A sends a normal PathTear for the LSP to B. - 3. Assume B has not initiated the backup signaling for the LSP during - local repair. To enable LSP state cleanup, B MUST send a "Remote" - PathTear with 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 local address used in the Node-ID signaling - adjacency. + 3. Assume B has not initiated the backup signaling for the LSP + during local repair. To enable LSP state cleanup, B MUST send a + "Remote" PathTear with 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 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 MUST 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 MUST be @@ -1068,22 +1063,22 @@ 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 + 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. 6.2. CONDITIONS Flags Apart from allocating Class-Number for the CONDITIONS object, the allocation of the Merge-point condition bit or M-bit Section 4.4 will also be done by IANA. @@ -1093,39 +1088,25 @@ 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. We are thankful to Raveendra Torvi and Yimin Shen for their comments and inputs on early versions of the draft. We also thank Alexander Okonnikov for his review and comments on the draft. 8. Contributors - Markus Jork - Juniper Networks, Inc. - Email: mjork@juniper.net - - 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 + Markus Jork Juniper Networks, Inc. Email: mjork@juniper.net 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, .