idnits 2.17.1 draft-esale-ldp-node-frr-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (March 24, 2015) is 3319 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2119' is defined on line 250, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group Santosh Esale 3 INTERNET-DRAFT Yakov Rekhter 4 Intended Status: Proposed Standard Raveendra Torvi 5 Juniper Networks 7 Luyuan Fang 8 Microsoft 10 Luay Jalil 11 Verizon 13 March 24, 2015 15 Fast Reroute for Node Protection in LDP-based LSPs 16 draft-esale-ldp-node-frr-00 18 Abstract 20 This document describes procedures to support node protection for 21 (unicast) Label Switched Paths(LSPs) established by LDP("Label 22 Distribution Protocol"). In order to protect a node N, the Point of 23 Local Repair (PLR) of N must discover the Merge Points(MPTs) of node 24 N such that traffic can be redirected to them in case node N fails. 25 Redirecting the traffic around the failed node N depends on existing 26 point-to-point LSPs originated from the PLR to the MPTs while 27 bypassing the protected node N. The procedures described in this 28 document are topology independent in a sense that they provide node 29 protection in any topology. 31 Status of this Memo 33 This Internet-Draft is submitted to IETF in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF), its areas, and its working groups. Note that 38 other groups may also distribute working documents as 39 Internet-Drafts. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 The list of current Internet-Drafts can be accessed at 47 http://www.ietf.org/1id-abstracts.html 49 The list of Internet-Draft Shadow Directories can be accessed at 50 http://www.ietf.org/shadow.html 52 Copyright and License Notice 54 Copyright (c) 2015 IETF Trust and the persons identified as the 55 document authors. All rights reserved. 57 This document is subject to BCP 78 and the IETF Trust's Legal 58 Provisions Relating to IETF Documents 59 (http://trustee.ietf.org/license-info) in effect on the date of 60 publication of this document. Please review these documents 61 carefully, as they describe your rights and restrictions with respect 62 to this document. Code Components extracted from this document must 63 include Simplified BSD License text as described in Section 4.e of 64 the Trust Legal Provisions and are provided without warranty as 65 described in the Simplified BSD License. 67 Table of Contents 69 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 70 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 71 3. Merge Point (MPT) Discovery . . . . . . . . . . . . . . . . . . 3 72 4. Constructing Bypass LSPs . . . . . . . . . . . . . . . . . . . 4 73 5. Obtaining Label Mapping from MPT . . . . . . . . . . . . . . . 5 74 6. Forwarding Considerations . . . . . . . . . . . . . . . . . . . 5 75 7. Synergy with node protection in mLDP . . . . . . . . . . . . . 6 76 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 77 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 78 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 79 11. Normative References . . . . . . . . . . . . . . . . . . . . . 6 80 12. Informative References . . . . . . . . . . . . . . . . . . . . 6 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 83 1. Terminology 85 PLR: Point of Local Repair (the LSR that redirects the traffic to 86 one or more Merge Point LSRs). 87 MPT: Merge Point. Any LSR on the LDP-signaled (multi-point to 88 point) LSP, provided that the path from that LSR to the 89 egress of that LSP is not affected by the failure of the 90 protected node 91 tLDP: Targeted LDP session. 93 2. Introduction 95 This document describes procedures to support node protection for 96 (unicast) Label Switched Paths (LSPs) established by LDP ("Label 97 Distribution Protocol") [RFC5036]. In order to protect a node N, the 98 Point of Local Repair (PLR) of N must discover the Merge Points 99 (MPTs) of node N such that traffic can be redirected to them in case 100 node N fails. Redirecting the traffic around the failed node N 101 depends on existing Point-to-Point (P2P) LSPs originating from the 102 PLR LSR to the MPTs while bypassing node N. The procedures to setup 103 these P2P LSPs are outside the scope of this document, but one option 104 is to use RSVP-TE based techniques [RFC3209] to accomplish this. 105 Finally, sending traffic from the PLR to the MPTs requires the PLR to 106 obtain FEC-label mappings from the MPTs. The procedures described in 107 this document relies on Targeted LDP (tLDP) session [RFC5036] for the 108 PLR to obtain such mappings. The procedures for node protection 109 described in this document fall into the category of local 110 protection. The procedures described in this document apply to LSPs 111 bound to either an IPv4 or IPv6 Address Prefix FEC. The procedures 112 described in this document are topology independent in a sense that 113 they provide node protection in any topology. Thus these procedures 114 provide topology independent fast reroute. 116 3. Merge Point (MPT) Discovery 118 For a given LSP that traverses the PLR, the protected node N, and a 119 particular neighbor of the protected node, we'll refer to this 120 neighbor as the "next next-hop". Note that from the PLR's perspective 121 the protected node N is the next hop for the FEC associated with that 122 LSP. Likewise, from the protected node's perspective the next next- 123 hop is the next hop for that FEC. If for a given 124 triplet the next next-hop is in the same IGP area as the PLR, then 125 that next next-hop acts as the MPT for that triplet. For a given LSP 126 traversing a PLR and the node protected by the PLR, the PLR discovers 127 the next next-hops (MPTs) that are in the same IGP area as the PLR 128 from either its Traffic Engineering database or Link State database. 129 The Traffic Engineering database or Link State database is populated 130 by either ISIS or OSPF. The discovery of the next next-hop (depending 131 on an implementation) may not involve any additional SPF, above and 132 beyond what would be needed by ISIS/OSPF anyway, as the next next- 133 hop, just like the next-hop, is a by-product of SPF computation. If 134 for a given triplet the node protected by the PLR is an 135 Area Border Router (ABR), then the PLR and the next next-hop may end 136 up in different IGP areas (this could happen when an LSP traversing 137 the PLR and the protected node does not terminate in the same IGP 138 area as the PLR). In this situation the PLR may not be able to 139 determine the next next-hop from either its Traffic Engineering 140 database or Link State database, and thus may not be able to use the 141 next next-hop as the MPT. In this scenario the PLR uses an 142 "alternative" ABR as the MPT, where an alternative ABR is defined as 143 follows. For a given LSP that traverses the PLR and the (protected) 144 ABR, an alternative ABR is defined as any ABR that advertises into 145 PLR's own IGP area reachability to the FEC associated with the LSP. 146 Note that even if a PLR protects an ABR, for some of the LSPs 147 traversing the PLR and the ABR, the next next-hops may be in the same 148 IGP area as the PLR, in which case these next next-hops act as MPTs 149 for these LSPs. Note that even if the protected node is not an ABR, 150 if an LSP traversing the PLR and the protected node does not 151 terminate in the same IGP area as the PLR, then for this LSP the PLR 152 MAY use an alternative ABR (as defined above), rather than the next 153 next-hop as the MPT. 155 4. Constructing Bypass LSPs 157 As we mentioned before, redirecting traffic around the failed node N 158 depends on existing Point-to-Point (P2P) LSPs originating from the 159 PLR to the MPTs while bypassing node N. We'll refer to these LSPs as 160 "bypass LSPs". While the procedures to setup these bypass LSPs are 161 outside the scope of this document, this document assumes use of 162 RSVP-TE LSPs [RFC3209] to accomplish this. Once a PLR that protects a 163 given node N discovers the set of MPTs associated with itself and the 164 protected node, (at the minimum) the PLR MUST (automatically) 165 establish bypass LSPs to all these MPTs. The bypass LSPs MUST be 166 established before the failure of the protected node. One could 167 observe that if the protected node is not an ABR and the PLR does not 168 use alternative ABR(s) as MPT(s), then the set of all the IGP 169 neighbors of the protected node forms a superset of the MPTs. Thus it 170 would be sufficient for the PLR to establish bypass LSPs with all the 171 IGP neighbors of the protected node, even though some of these 172 neighbors may not be MPTs for any of the LSPs traversing the PLR and 173 the protected node. The bypass LSPs MUST avoid traversing the 174 protected node, which means that the bypass LSPs are explicitly 175 routed LSPs (of course, using RSVP-TE to establish bypass LSPs allows 176 these LSPs to be explicitly routed). As a given router may act as an 177 MPT for more than one LSP traversing the PLR, the protected node, and 178 the MPT, the same bypass LSP will be used to protect all these LSPs. 180 5. Obtaining Label Mapping from MPT 182 As we mentioned before, sending traffic from the PLR to the MPTs 183 requires the PLR to obtain FEC-label mappings from the MPTs. The 184 solution described in this document relies on Targeted LDP (tLDP) 185 session [RFC5036] for the PLR to obtain such mappings. Specifically, 186 for a given PLR and the node protected by this PLR, at the minimum 187 the PLR MUST (automatically) establish tLDP with all the MPTs 188 associated with this PLR and the protected node. These tLDP sessions 189 MUST be established before the failure of the protected node. One 190 could observe that if the protected node is not an ABR and the PLR 191 does not use alternative ABR(s) as MPT(s), then the set of all the 192 IGP neighbors of the protected node forms a superset of the MPTs. 193 Thus it would be sufficient for the PLR to (automatically) establish 194 tLDP with all the IGP neighbors of the protected node that are in the 195 same area as the PLR, even though some of these neighbors may not be 196 MPTs for any of the LSPs traversing the PLR and the protected node. 197 At the minimum for a given tLDP peer the PLR MUST obtain FEC-label 198 mapping for the FEC(s) for which the peer acts as an MPT. The PLR 199 MUST obtain this mapping before the failure of the protected node. To 200 obtain this mapping for only these FECs (and no other FECs that the 201 peer may maintain) the PLR MAY rely on the LDP Downstream on Demand 202 (DoD) procedures [RFC5036]. Otherwise, without relying on the DoD 203 procedures, the PLR may end up receiving from a given tLDP peer FEC- 204 label mappings for all the FECs maintained by the peer, even if the 205 peer does not act as an MPT for some of these FECs. If the LDP DoD 206 procedures are not used, then for the purpose of the procedures 207 specified in this draft the only label mappings that SHOULD be 208 exchanged are for the Address Prefix FECs whose PreLen value is 209 either 32 (IPv4), or 128 (IPv6); label mappings for the Address 210 Prefix FECs with any other PreLen value SHOULD NOT be exchanged. 211 When a PLR has one or more ABRs acting as MPTs, the PLR MAY use the 212 procedures specified in [draft-ietf-mpls-app-aware-tldp] to limit the 213 set of FEC-label mappings received from non-ABR MPTs to only the 214 mappings for the FECs associated with the LSPs that terminate in the 215 PLR's own IGP area. 217 6. Forwarding Considerations 219 When a PLR detects failure of the protected node then rather than 220 swapping an incoming label with a label that the PLR received from 221 the protected node, the PLR swap the incoming label with the label 222 that the PLR receives from the MPT, and then pushes the label 223 associated with the bypass LSP to that MPT. To minimize micro-loop 224 during the IGP global convergence PLR may continue to use the bypass 225 LSP during network convergence by adding small delay before switching 226 to a new path. 228 7. Synergy with node protection in mLDP 230 Both the bypass LSPs and tLDP sessions described in this document 231 could also be used for the purpose of mLDP node protection, as 232 described in [draft-ietf-mpls-mldp-node-protection]. 234 8. Security Considerations 236 The same security considerations apply as those for the base LDP 237 specification, as described in [RFC5036]. 239 9. IANA Considerations 241 This document introduces no new IANA Considerations. 243 10. Acknowledgements 245 The authors would like to thank Hannes Gredler, Aman Kapoor, Minto 246 Jeyananth and Eric Rosen for their contributions to this document. 248 11. Normative References 250 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 251 Requirement Levels", BCP 14, RFC 2119, March 1997. 253 [RFC3209] D. Awduche, et al., "RSVP-TE: Extensions to RSVP for LSP 254 Tunnels", RFC3209, Decembet 2001 256 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 257 Specification", RFC 5036, October 2007. 259 [draft-ietf-mpls-app-aware-tldp] Esale, S., et al.,"Application- 260 aware Targeted LDP", draft-esale-mpls-app-aware-tldp, work 261 in progress 263 12. Informative References 265 [draft-ietf-mpls-mldp-node-protection], IJ. Wijnands, et al., "mLDP 266 Node Protection", draft-ietf-mpls-mldp-node-protection, 267 work in progress 269 Authors' Addresses 271 Santosh Esale 272 Juniper Networks 273 EMail: sesale@juniper.net 274 Yakov Rekhter 275 Juniper Networks 276 Email: yakov@juniper.net 278 Raveendra Torvi 279 Juniper Networks 280 EMail: rtorvi@juniper.net 282 Luyuan Fang 283 Microsoft 284 Email: lufang@microsoft.com 286 Luay Jalil 287 Verizon 288 Email: luay.jalil@verizon.com