--- 1/draft-ietf-mpls-ri-rsvp-frr-02.txt 2018-02-10 01:13:13.890343087 -0800 +++ 2/draft-ietf-mpls-ri-rsvp-frr-03.txt 2018-02-10 01:13:13.942344333 -0800 @@ -1,24 +1,24 @@ Network Working Group Chandra Ramachandran Internet Draft Juniper Networks Intended status: Standards Track Ina Minei Google, Inc Dante Pacella Verizon Tarek Saad Cisco Systems Inc. - Expires: February 11, 2018 August 11, 2017 + Expires: August 9, 2018 February 10, 2018 Refresh Interval Independent FRR Facility Protection - draft-ietf-mpls-ri-rsvp-frr-02 + draft-ietf-mpls-ri-rsvp-frr-03 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), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. @@ -27,25 +27,25 @@ 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html - This Internet-Draft will expire on August 12, 2017. + This Internet-Draft will expire on August 9, 2018. Copyright Notice - Copyright (c) 2016 IETF Trust and the persons identified as the + Copyright (c) 2018 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 (http://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 @@ -74,68 +74,71 @@ should unambiguously determine when a particular LSP state should be deleted. Coupling LSP state with the corresponding RSVP-TE signaling adjacencies as recommended in RSVP-TE Scaling Recommendations (draft-ietf-teas-rsvp-te-scaling-rec) will apply in scenarios other than RFC 4090 FRR using bypass tunnels. 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 scenarios not covered by procedures defined in RSVP-TE Scaling - Recommendations. + Recommendations. Hence, this document updates the semantics of + Refresh-Interval Independent RSVP (RI-RSVP) capability specified in + RSVP-TE Scaling Recommendations (draft-ietf-teas-rsvp-te-scaling- + rec). 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]. Table of Contents 1. Introduction...................................................4 1.1. Motivation................................................4 2. Terminology....................................................5 - 3. Problem Description............................................5 + 3. Problem Description............................................6 4. Solution Aspects...............................................8 4.1. Signaling Handshake between PLR and MP....................8 4.1.1. PLR Behavior.........................................8 4.1.2. Remote Signaling Adjacency..........................10 4.1.3. MP Behavior.........................................10 4.1.4. "Remote" state on MP................................11 4.2. Impact of Failures on LSP State..........................12 4.2.1. Non-MP Behavior.....................................12 4.2.2. LP-MP Behavior......................................12 - 4.2.3. NP-MP Behavior......................................12 + 4.2.3. NP-MP Behavior......................................13 4.2.4. Behavior of a Router that is both LP-MP and NP-MP...14 4.3. Conditional Path Tear....................................14 4.3.1. Sending Conditional Path Tear.......................15 4.3.2. Processing Conditional Path Tear....................15 4.3.3. CONDITIONS object...................................15 4.4. Remote State Teardown....................................16 4.4.1. PLR Behavior on Local Repair Failure................17 4.4.2. PLR Behavior on Resv RRO Change.....................17 4.4.3. LSP Preemption during Local Repair..................18 4.4.3.1. Preemption on LP-MP after Phop Link failure....18 4.4.3.2. Preemption on NP-MP after Phop Link failure....18 4.5. Backward Compatibility Procedures........................19 4.5.1. Detecting Support for Refresh interval Independent FRR ...........................................................19 4.5.2. Procedures for backward compatibility...............20 4.5.2.1. Lack of support on Downstream Node.............20 - 4.5.2.2. Lack of support on Upstream Node...............20 + 4.5.2.2. Lack of support on Upstream Node...............21 4.5.2.3. Incremental Deployment.........................21 5. Security Considerations.......................................22 6. IANA Considerations...........................................22 6.1. New Object - CONDITIONS..................................22 - 7. Normative References..........................................22 + 7. Normative References..........................................23 8. Informative References........................................23 - 9. Acknowledgments...............................................23 + 9. Acknowledgments...............................................24 10. Contributors.................................................24 11. Authors' Addresses...........................................24 1. Introduction RSVP-TE Fast Reroute [RFC4090] 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 @@ -167,52 +170,51 @@ 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 in [TE-SCALE-REC]. - However, the procedures specified in [RFC2961] do not fully address - stale state cleanup for facility backup protection [RFC4090], as - facility backup protection still depends on refresh timeouts for - stale state cleanup. Thus [RFC2961] is insufficient to address the - problem of stale state cleanup when facility backup protection is - used. + However, the procedures specified in [TE-SCALE-REC] do not fully + address stale state cleanup for facility backup protection - The procedures specified in this document, in combination with - [RFC2961], eliminate facility backup protection dependency on - refresh timeouts for stale state cleanup. These procedures, in - combination with [RFC2961], fully address the above mentioned - problem of RSVP-TE stale state cleanup, including the cleanup for - facility backup protection. + [RFC4090], as facility backup protection still depends on refresh + timeouts for stale state cleanup. + + The procedures specified in this document, in combination with [TE- + SCALE-REC], eliminate facility backup protection dependency on + refresh timeouts for stale state cleanup including the cleanup for + facility backup protection. The document hence updates the semantics + of Refresh-Interval Independent RSVP (RI-RSVP) capability specified + in [TE-SCALE-REC]. 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 assumed 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 LSP LP-MP node: Merge Point router at the tail of Link-protecting bypass tunnel - NP-MP node: Merger Point router at the tail of Node-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 Conditional PathTear: PathTear message containing a suggestion to a receiving downstream router to retain Path state if the receiving router is NP-MP @@ -423,28 +427,41 @@ When the NNhop or the Nhop node receives the triggered PATH with a "matching" Bypass Summary FRR Extended Association object, the node should consider itself as the MP for the PLR IP address "corresponding" to the Bypass Summary FRR Extended Association object. The matching and ordering rules for Bypass Summary FRR Extended Association specified in [SUMMARY-FRR] MUST be followed by implementations supporting this document. In addition to the above procedures, the node SHOULD check the - presence of remote signaling adjacency with PLR. If a matching - Bypass Summary FRR Extended Association object is found in the PATH - and if the RSVP-TE signaling adjacency is also present, then the - node concludes that the PLR will undertake refresh-interval + presence of remote signaling adjacency with Refresh-interval + Independent RSVP (RI-RSVP) capable PLR. RI-RSVP capability is + specified in [TE-SCALE-REC] and this document updates the semantics + of RI-RSVP capability for RFC 4090 facility bypass FRR. If a + matching Bypass Summary FRR Extended Association object is found in + the PATH and if the RSVP-TE signaling adjacency is also present, + then the node concludes that the PLR will undertake refresh-interval independent FRR procedures specified in this document. If the PLR has included NodeID sub-object in PATH RRO, then that NodeID is the remote neighbor address. Otherwise, the PLR's interface address in - PATH RRO will be the remote neighbor address. + PATH RRO will be the remote neighbor address. To enable the MP to + correctly match the bypass source address in B-SFRR Extended + Association object with the corresponding RSVP-TE Node-ID based + signaling adjacency with the PLR, the bypass source address in B- + SFRR Extended Association object MUST either be equal to or be tied + to the same node on TED, as the PLR's address used for sending + NodeID based Hello messages for maintaining RSVP-TE signaling + adjacency with the MP. It is recommended that the PLR and the MP + include NodeID sub-object in PATH and RESV RRO respectively, and the + PLR select its NodeID address as the source and the NodeID address + of the MP as the destination addresses for the bypass LSP. - If a matching Bypass Summary FRR Extended Association object is included by the PPhop node and if a corresponding Node-ID signaling adjacency exists with the PPhop node, then the router SHOULD conclude it is NP-MP. - If a matching Bypass Summary FRR Extended Association object is included by Phop node and if a corresponding Node-ID signaling adjacency exists with the Phop node, then the router SHOULD conclude it is LP-MP.