idnits 2.17.1 draft-esale-mpls-ldp-node-frr-05.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 : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. 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 13, 2017) is 2594 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 284, but no explicit reference was found in the text == Unused Reference: 'RFC7715' is defined on line 299, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 4 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 Raveendra Torvi 4 Intended Status: Proposed Standard Juniper Networks 5 Expires: September 14, 2017 6 Luyuan Fang 7 Microsoft 9 Luay Jalil 10 Verizon 12 March 13, 2017 14 Fast Reroute for Node Protection in LDP-based LSPs 15 draft-esale-mpls-ldp-node-frr-05 17 Abstract 19 This document describes procedures to support node protection for 20 unicast Label Switched Paths (LSPs) established by Label Distribution 21 Protocol (LDP). In order to protect a node N, the Point of Local 22 Repair (PLR) of N must discover the Merge Points (MPs) of node N such 23 that traffic can be redirected to them in case of node N failure. 24 Redirecting the traffic around the failed node N depends on existing 25 point-to-point LSPs originated from the PLR to the MPs while 26 bypassing the protected node N. The procedures described in this 27 document are topology independent in a sense that they provide node 28 protection in any topology so long as there is a alternate path in 29 the network that avoids the protected node. 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) 2017 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 70 1.1 Abbreviations . . . . . . . . . . . . . . . . . . . . . . . 4 71 3. Merge Point (MP) Discovery . . . . . . . . . . . . . . . . . . 4 72 4. Constructing Bypass LSPs . . . . . . . . . . . . . . . . . . . 5 73 5. Obtaining Label Mapping from MP . . . . . . . . . . . . . . . . 6 74 6. Forwarding Considerations . . . . . . . . . . . . . . . . . . . 6 75 7. Synergy with node protection in mLDP . . . . . . . . . . . . . 7 76 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 77 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 78 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 79 11. Normative References . . . . . . . . . . . . . . . . . . . . . 7 80 12. Informative References . . . . . . . . . . . . . . . . . . . . 7 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 83 1. Introduction 85 This document describes procedures to support node protection for 86 unicast Label Switched Paths (LSPs) established by Label Distribution 87 Protocol (LDP) [RFC5036]. In order to protect a node N, the Point of 88 Local Repair (PLR) of N must discover the Merge Points (MPs) of node 89 N such that traffic can be redirected to them in case of node N 90 failure. Redirecting the traffic around the failed node N depends on 91 existing explicit path Point-to-Point (P2P) LSPs originated from the 92 PLR LSR to the MPs while bypassing node N. The procedures to setup 93 these P2P LSPs are outside the scope of this document, but one option 94 is to use RSVP-TE based techniques [RFC3209] to accomplish it. 95 Finally, sending traffic from the PLR to the MPs requires the PLR to 96 obtain FEC-label bindings from the MPs. The procedures described in 97 this document relies on Targeted LDP (tLDP) session [RFC5036] for the 98 PLR to obtain such FEC-Label bindings. 100 The procedure described in this document assumes the use of platform- 101 wide label space. The procedures for node protection described in 102 this document fall into the category of local protection. The 103 procedures described in this document apply to LDP LSPs bound to 104 either an IPv4 or IPv6 Prefix FEC element. The procedures described 105 in this document are topology independent in a sense that they 106 provide node protection in any topology so long as there is a 107 alternate path in the network that avoids the protected node. Thus 108 these procedures provide topology independent fast reroute. 110 1.1 Abbreviations 112 PLR: Point of Local Repair - the LSR that redirects the traffic to 113 one or more Merge Point LSRs. 115 MP: Merge Point. Any LSR on the LDP-signaled (multi-point to 116 point) LSP, provided that the path from that LSR to the 117 egress of that LSP is not affected by the failure of the 118 protected node. 120 tLDP: A targeted LDP session is an LDP session between non-directly 121 connected LSRs, established using the LDP extended discovery 122 mechanism. 124 FEC: Forwarding equivalence class. 126 IGP: Interior Gateway Protocol. 128 BR: Border Router. 130 3. Merge Point (MP) Discovery 132 For a given LSP that traverses the PLR, the protected node N, and a 133 particular neighbor of the protected node, we'll refer to this 134 neighbor as the "next next-hop". Note that from the PLR's perspective 135 the protected node N is the next hop for the FEC associated with that 136 LSP. Likewise, from the protected node's perspective the next next- 137 hop is the next hop for that FEC. If for a given 138 triplet the next next-hop is in the same routing subdomain (area) as 139 the PLR, then that next next-hop acts as the MP for that triplet. For 140 a given LSP traversing a PLR and the node protected by the PLR, the 141 PLR discovers its next next-hops (MPs) that are in the same routing 142 subdomain (IGP area) as the PLR from IGP shortest path first (SPF) 143 calculations. The discovery of next next-hop, depending on an 144 implementation, may not involve any additional SPF, above and beyond 145 what will be needed by either ISIS or OSPF anyway, as the next next- 146 hop, just like the next-hop, is a by-product of SPF computation. 148 Also, the PLR may discover all possible MPs from either its traffic 149 engineering database or link state database. Some implementations MAY 150 need appropriate configuration to populate the traffic engineering 151 database. The traffic engineering database is populated by routing 152 protocols such as ISIS and OSPF or configured statically. 154 If for a given triplet the node protected by the PLR is 155 an Border Router (BR), then the PLR and the next next-hop may end up 156 in different routing subdomain. This could happen when an LSP 157 traversing the PLR and the protected node does not terminate in the 158 same routing subdomain as the PLR. In this situation the PLR may not 159 be able to determine the next next-hop from shortest path first (SPF) 160 calculations, and thus may not be able to use the next next-hop as 161 the MP. In this scenario the PLR uses an "alternative" BR as the MP, 162 where an alternative BR is defined as follows. For a given LSP that 163 traverses the PLR and the (protected) BR, an alternative BR is 164 defined as any BR that advertises into PLR's own routing subdomain 165 reachability to the FEC associated with the LSP. 167 Note that even if a PLR protects an BR, for some of the LSPs 168 traversing the PLR and the BR, the next next-hops may be in the same 169 routing subdomain as the PLR, in which case these next next-hops act 170 as MPs for these LSPs. Note that even if the protected node is not an 171 BR, if an LSP traversing the PLR and the protected node does not 172 terminate in the same routing subdomain as the PLR, then for this LSP 173 the PLR MAY use an alternative BR (as defined earlier), rather than 174 the next next-hop as the MP. When there are several candidate BRs for 175 alternative BR, the LSR MUST select one BR. The algorithm used for 176 the alternative BR selection is a local matter but one option is to 177 select the BR per FEC based on shortest path from PLR to the BR. 179 4. Constructing Bypass LSPs 181 As mentioned before, redirecting traffic around the failed node N 182 depends on existing explicit path Point-to-Point (P2P) LSPs 183 originated from the PLR to the MPs while bypassing node N. Let's 184 refer to these LSPs as "bypass LSPs". While the procedures to signal 185 these bypass LSPs are outside the scope of this document, this 186 document assumes use of RSVP-TE LSPs [RFC3209] to accomplish it. Once 187 a PLR that protects a given node N discovers the set of MPs 188 associated with itself and the protected node, at the minimum the PLR 189 MUST (automatically) establish bypass LSPs to all these MPs. The 190 bypass LSPs MUST be established prior to the failure of the protected 191 node. 193 One could observe that if the protected node is not an BR and the PLR 194 does not use alternative BR(s) as MP(s), then the set of all the IGP 195 neighbors of the protected node forms a superset of the MPs. Thus it 196 would be sufficient for the PLR to establish bypass LSPs with all the 197 IGP neighbors of the protected node, even though some of these 198 neighbors may not be MPs for any of the LSPs traversing the PLR and 199 the protected node. 201 The bypass LSPs MUST avoid traversing the protected node, which means 202 that the bypass LSPs are explicitly routed LSPs. Of course, using 203 RSVP-TE to establish bypass LSPs allows these LSPs to be explicitly 204 routed. As a given router may act as an MP for more than one LSP 205 traversing the PLR, the protected node, and the MP, the same bypass 206 LSP will be used to protect all those LSPs. 208 5. Obtaining Label Mapping from MP 210 As mentioned before, sending traffic from the PLR to the MPs requires 211 the PLR to obtain FEC-label bindings from the MPs. The solution 212 described in this document relies on Targeted LDP (tLDP) session 213 [RFC5036] for the PLR to obtain such mappings. Specifically, for a 214 given PLR and the node protected by this PLR, at the minimum the PLR 215 MUST (automatically) establish tLDP with all the MPs associated with 216 this PLR and the protected node. These tLDP sessions MUST be 217 established prior to the failure of the protected node. One could 218 observe that if the protected node is not an BR and the PLR does not 219 use alternative BR(s) as MP(s), then the set of all the IGP neighbors 220 of the protected node forms a superset of the MPs. Thus it will be 221 sufficient for the PLR to (automatically) establish tLDP session with 222 all the IGP neighbors of the protected node - except the PLR - that 223 are in the same area as the PLR, even though some of these neighbors 224 may not be MPs for any of the LSPs traversing the PLR and the 225 protected node. 227 At the minimum for a given tLDP peer the PLR MUST obtain FEC-label 228 mapping for the FEC(s) for which the peer acts as an MP. The PLR MUST 229 obtain this mapping before the failure of the protected node. To 230 obtain this mapping for only these FECs and no other FECs that the 231 peer may maintain, the PLR SHOULD rely on the LDP Downstream on 232 Demand (DoD) procedures [RFC5036]. Otherwise, without relying on the 233 DoD procedures, the PLR may end up receiving from a given tLDP peer 234 FEC-label mappings for all the FECs maintained by the peer, even if 235 the peer does not act as an MP for some of these FECs. If the LDP DoD 236 procedures are not used, then for the purpose of the procedures 237 specified in this draft the only label mappings that SHOULD be 238 exchanged are for the Prefix FEC elements whose PreLen value is 239 either 32 (IPv4), or 128 (IPv6); label mappings for the Prefix FEC 240 elements with any other PreLen value SHOULD NOT be exchanged. 242 When a PLR has one or more BRs acting as MPs, the PLR MAY use the 243 procedures specified in [draft-ietf-mpls-app-aware-tldp] to limit the 244 set of FEC-label mappings received from non-BR MPs to only the 245 mappings for the FECs associated with the LSPs that terminate in the 246 PLR's own routing subdomain (area). 248 6. Forwarding Considerations 250 When a PLR detects failure of the protected node then rather than 251 swapping an incoming label with a label that the PLR received from 252 the protected node, the PLR swaps the incoming label with the label 253 that the PLR receives from the MP, and then pushes the label 254 associated with the bypass LSP to that MP. 256 To minimize micro-loop during the IGP global convergence PLR may 257 continue to use the bypass LSP during network convergence by adding 258 small delay before switching to a new path. 260 7. Synergy with node protection in mLDP 262 Both the bypass LSPs and tLDP sessions described in this document 263 could also be used for the purpose of mLDP node protection, as 264 described in [draft-ietf-mpls-mldp-node-protection]. 266 8. Security Considerations 268 The same security considerations apply as those for the base LDP 269 specification, as described in [RFC5036]. 271 9. IANA Considerations 273 This document introduces no new IANA Considerations. 275 10. Acknowledgements 277 We are indebted to Yakov Rekhter for many discussions on this topic. 278 We like to thank Hannes Gredler, Aman Kapoor, Minto Jeyananth, Eric 279 Rosen, Vladimir Blazhkun and Loa Andersson for through review of this 280 document. 282 11. Normative References 284 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 285 Requirement Levels", BCP 14, RFC 2119, March 1997. 287 [RFC3209] D. Awduche, et al., "RSVP-TE: Extensions to RSVP for LSP 288 Tunnels", RFC3209, Decembet 2001. 290 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 291 Specification", RFC 5036, October 2007. 293 [draft-ietf-mpls-app-aware-tldp] Esale, S., et al.,"Application- 294 aware Targeted LDP", draft-esale-mpls-app-aware-tldp, work 295 in progress. 297 12. Informative References 299 [RFC7715], IJ. Wijnands, et al., "Multipoint LDP (mLDP) Node 300 Protection", RFC7715, January 2016. 301 Authors' Addresses 303 Santosh Esale 304 Juniper Networks 305 EMail: sesale@juniper.net 307 Raveendra Torvi 308 Juniper Networks 309 EMail: rtorvi@juniper.net 311 Luyuan Fang 312 Microsoft 313 Email: lufang@microsoft.com 315 Luay Jalil 316 Verizon 317 Email: luay.jalil@verizon.com