idnits 2.17.1 draft-ietf-rtgwg-remote-lfa-11.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 == Line 674 has weird spacing: '...achable via a...' -- The document date (January 30, 2015) is 3374 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) ** Downref: Normative reference to an Informational RFC: RFC 5714 == Outdated reference: A later version (-02) exists of draft-ietf-ospf-routable-ip-address-01 == Outdated reference: A later version (-11) exists of draft-ietf-rtgwg-lfa-manageability-07 == Outdated reference: A later version (-13) exists of draft-ietf-rtgwg-rlfa-node-protection-01 == Outdated reference: A later version (-04) exists of draft-litkowski-rtgwg-uloop-delay-03 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Bryant 3 Internet-Draft C. Filsfils 4 Intended status: Standards Track S. Previdi 5 Expires: August 3, 2015 Cisco Systems 6 M. Shand 7 Independent Contributor 8 N. So 9 Vinci Systems 10 January 30, 2015 12 Remote Loop-Free Alternate (LFA) Fast Re-Route (FRR) 13 draft-ietf-rtgwg-remote-lfa-11 15 Abstract 17 This document describes an extension to the basic IP fast re-route 18 mechanism described in RFC5286, that provides additional backup 19 connectivity for point to point link failures when none can be 20 provided by the basic mechanisms. 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 26 document are to be interpreted as described in RFC2119 [RFC2119]. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on August 3, 2015. 45 Copyright Notice 47 Copyright (c) 2015 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. Overview of Solution . . . . . . . . . . . . . . . . . . . . 4 65 4. Repair Paths . . . . . . . . . . . . . . . . . . . . . . . . 6 66 4.1. Tunnels as Repair Paths . . . . . . . . . . . . . . . . . 6 67 4.2. Tunnel Requirements . . . . . . . . . . . . . . . . . . . 7 68 5. Construction of Repair Paths . . . . . . . . . . . . . . . . 8 69 5.1. Identifying Required Tunneled Repair Paths . . . . . . . 8 70 5.2. Determining Tunnel End Points . . . . . . . . . . . . . . 8 71 5.2.1. Computing Repair Paths . . . . . . . . . . . . . . . 9 72 5.2.2. Selecting Repair Paths . . . . . . . . . . . . . . . 11 73 5.3. A Cost Based RLFA Algorithm . . . . . . . . . . . . . . . 12 74 5.4. Interactions with IS-IS Overload, RFC6987, and Costed 75 Out Links . . . . . . . . . . . . . . . . . . . . . . . . 17 76 6. Example Application of Remote LFAs . . . . . . . . . . . . . 18 77 7. Node Failures . . . . . . . . . . . . . . . . . . . . . . . . 18 78 8. Operation in an LDP environment . . . . . . . . . . . . . . . 20 79 9. Analysis of Real World Topologies . . . . . . . . . . . . . . 21 80 9.1. Topology Details . . . . . . . . . . . . . . . . . . . . 21 81 9.2. LFA only . . . . . . . . . . . . . . . . . . . . . . . . 22 82 9.3. RLFA . . . . . . . . . . . . . . . . . . . . . . . . . . 23 83 9.4. Comparison of LFA an RLFA results . . . . . . . . . . . . 24 84 10. Management and Operational Considerations . . . . . . . . . . 25 85 11. Historical Note . . . . . . . . . . . . . . . . . . . . . . . 26 86 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 87 13. Security Considerations . . . . . . . . . . . . . . . . . . . 26 88 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 89 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 90 15.1. Normative References . . . . . . . . . . . . . . . . . . 27 91 15.2. Informative References . . . . . . . . . . . . . . . . . 27 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 94 1. Introduction 96 RFC 5714 [RFC5714] describes a framework for IP Fast Re-route (IPFRR) 97 and provides a summary of various proposed IPFRR solutions. A basic 98 mechanism using loop-free alternates (LFAs) is described in [RFC5286] 99 that provides good repair coverage in many topologies [RFC6571], 100 especially those that are highly meshed. However, some topologies, 101 notably ring based topologies are not well protected by LFAs alone 102 because there is no neighbor of the point of local repair (PLR) that 103 has a cost to the destination without traversing the failure that is 104 cheaper than the cost to the destination via the failure. 106 The method described in this document extends LFA approach described 107 in [RFC5286] to cover many of these cases by tunneling the packets 108 that require IPFRR to a node that is both reachable from the PLR and 109 can reach the destination. 111 2. Terminology 113 This document uses the terms defined in [RFC5714]. This section 114 defines additional terms that are used in this document. 116 Repair tunnel A tunnel established for the purpose of providing a 117 virtual neighbor which is a Loop Free Alternate. 119 P-space The P-space of a router with respect to a protected 120 link is the set of routers reachable from that 121 specific router using the pre-convergence shortest 122 paths, without any of those paths (including equal 123 cost path splits) transiting that protected link. 125 For example, the P-space of S with respect to link 126 S-E, is the set of routers that S can reach without 127 using the protected link S-E. 129 Extended P-space 131 Consider the set of neighbours of a router protecting 132 a link. Exclude from that set of routers the router 133 reachable over the protected link. The extended 134 P-space of the protecting router with respect to the 135 protected link is the union of the P-spaces of the 136 neighbours in that set of neighbours with respect to 137 the protected link (see Section 5.2.1.2). 139 Q-space Q-space of a router with respect to a protected link 140 is the set of routers from which that specific router 141 can be reached without any path (including equal cost 142 path splits) transiting that protected link. 144 PQ node A PQ node of a node S with respect to a protected link 145 S-E is a node which is a member of both the P-space 146 (or the extended P-space) of S with respect to that 147 protected link S-E and the Q-space of E with respect 148 to that protected link S-E. A repair tunnel endpoint 149 is chosen from the set of PQ-nodes. 151 Remote LFA (RLFA) The use of a PQ node rather than a neighbour of 152 the repairing node as the next hop in an LFA repair 153 [RFC5286]. 155 In this document the notation X-Y is used to mean the path from X to 156 Y over the link directly connecting X and Y, whilst the notation X->Y 157 refers to the shortest path from X to Y via some set of unspecified 158 nodes including the null set (i.e. Including over a link directly 159 connecting X and Y). 161 3. Overview of Solution 163 The problem of LFA IPFRR reachability in some networks is illustrated 164 by the network fragment shown in Figure 1 below. 166 S---E 167 / \ 168 A D 169 \ / 170 B---C 172 Figure 1: A simple ring topology 174 If all link costs are equal, traffic transiting link S-E cannot be 175 fully protected by LFAs. The destination C is an ECMP from S, and so 176 traffic to C can be protected when S-E fails, but traffic to D and E 177 are not protectable using LFAs. 179 This document describes extensions to the basic repair mechanism in 180 which tunnels are used to provide additional logical links which can 181 then be used as loop free alternates where none exist in the original 182 topology. In Figure 1 S can reach A, B, and C without going via S-E; 183 these form S's extended P-space with respect to S-E. The routers 184 that can reach E without going through S-E will be in E's Q-space 185 with respect to link S-E; these are D and C. B has equal-cost paths 186 to E via B-A-S-E and B-C-D-E and so the forwarder at S might choose 187 to send a packet to E via link S-E. Hence B is not in the Q-space of 188 E with respect to link S-E. The single node in both S's extended 189 P-space and E's Q-space is C; thus node C is selected as the repair 190 tunnel's end-point. Thus, if a tunnel is provided between S and C as 191 shown in Figure 2 then C, now being a direct neighbor of S would 192 become an LFA for D and E. The definition of (extended-)P space and 193 Q space are provided in Section 2 and details of the calculation of 194 the tunnel end points is provided in Section 5.2. 196 The non-failure traffic distribution is not disrupted by the 197 provision of such a tunnel since it is only used for repair traffic 198 and MUST NOT be used for normal traffic. Note that Operations and 199 Maintenance (OAM) traffic specifically to verify the viability of the 200 repair MAY traverse the tunnel prior to a failure. 202 S---E 203 / \ \ 204 A \ D 205 \ \ / 206 B---C 208 Figure 2: The addition of a tunnel 210 The use of this technique is not restricted to ring based topologies, 211 but is a general mechanism which can be used to enhance the 212 protection provided by LFAs. A study of the protection achieved 213 using remote LFA in typical service provider core networks is 214 provided in Section 9, and a side by side comparison between LFA and 215 remote LFA is provided in Section 9.4. 217 Remote LFA is suitable for incremental deployment within a network, 218 including a network that is already deploying LFA. Computation of 219 the repair path requires acceptable CPU resources, and takes place 220 exclusively on the repairing node. In MPLS networks the targeted LDP 221 protocol needed to learn the label binding at the repair tunnel 222 endpoint Section 8 is a well understood and widely deployed 223 technology. 225 The technique described in this document is directed at providing 226 repairs in the case of link failures. Considerations regarding node 227 failures are discussed in Section 7. This memo describes a solution 228 to the case where the failure occurs on a point to point link. It 229 covers the case where the repair first hop is reached via a broadcast 230 or non-broadcast multi-access (NBMA) link such as a LAN, and the case 231 where the P or Q node is attached via such a link. It does not 232 however cover the more complicated case where the failed interface is 233 a broadcast or non-broadcast multi-access (NBMA) link. 235 This document considers the case when the repair path is confined to 236 either a single area or to the level two routing domain. In all 237 other cases, the chosen PQ node should be regarded as a tunnel 238 adjacency of the repairing node, and the considerations described in 239 Section 6 of [RFC5286] taken into account. 241 4. Repair Paths 243 As with LFA FRR, when a router detects an adjacent link failure, it 244 uses one or more repair paths in place of the failed link. Repair 245 paths are pre-computed in anticipation of later failures so they can 246 be promptly activated when a failure is detected. 248 A tunneled repair path tunnels traffic to some staging point in the 249 network from which it is known that, in the absence of a worse than 250 anticipated failure, the traffic will travel to its destination using 251 normal forwarding without looping back. This is equivalent to 252 providing a virtual loop-free alternate to supplement the physical 253 loop-free alternates. Hence the name "Remote LFA FRR". In its 254 simplest form, when a link cannot be entirely protected with local 255 LFA neighbors, the protecting router seeks the help of a remote LFA 256 staging point. Network manageability considerations may lead to a 257 repair strategy that uses a remote LFA more frequently 258 [I-D.ietf-rtgwg-lfa-manageability]. 260 Examples of worse failures are node failures (see Section 7 ), the 261 failure of a shared risk link group (SRLG), the independent 262 concurrent failures of multiple links, broadcast or non-broadcast 263 multi-access (NBMA) links Section 3 ; protecting against such worse 264 failures is out of scope for this specification. 266 4.1. Tunnels as Repair Paths 268 Consider an arbitrary protected link S-E. In LFA FRR, if a path to 269 the destination from a neighbor N of S does not cause a packet to 270 loop back over the link S-E (i.e. N is a loop-free alternate), then 271 S can send the packet to N and the packet will be delivered to the 272 destination using the pre-failure forwarding information. If there 273 is no such LFA neighbor, then S may be able to create a virtual LFA 274 by using a tunnel to carry the packet to a point in the network which 275 is not a direct neighbor of S from which the packet will be delivered 276 to the destination without looping back to S. In this document such 277 a tunnel is termed a repair tunnel. The tail-end of this tunnel (the 278 repair tunnel endpoint) is a "PQ node" and the repair mechanism is a 279 "remote LFA". This tunnel MUST NOT traverse the link S-E. 281 Note that the repair tunnel terminates at some intermediate router 282 between S and E, and not E itself. This is clearly the case, since 283 if it were possible to construct a tunnel from S to E then a 284 conventional LFA would have been sufficient to effect the repair. 286 4.2. Tunnel Requirements 288 There are a number of IP in IP tunnel mechanisms that may be used to 289 fulfil the requirements of this design, such as IP-in-IP [RFC1853] 290 and GRE[RFC1701] . 292 In an MPLS enabled network using LDP[RFC5036], a simple label 293 stack[RFC3032] may be used to provide the required repair tunnel. In 294 this case the outer label is S's neighbor's label for the repair 295 tunnel end point, and the inner label is the repair tunnel end 296 point's label for the packet destination. In order for S to obtain 297 the correct inner label it is necessary to establish a targeted LDP 298 session[RFC5036] to the tunnel end point. 300 The selection of the specific tunnelling mechanism (and any necessary 301 enhancements) used to provide a repair path is outside the scope of 302 this document. The deployment in an MPLS/LDP environment is 303 relatively simple in the data plane as an LDP LSP from S to the 304 repair tunnel endpoint (the selected PQ node) is readily available, 305 and hence does not require any new protocol extension or design 306 change. This LSP is automatically established as a basic property of 307 LDP behavior. The performance of the encapsulation and decapsulation 308 is efficient as encapsulation is just a push of one label (like 309 conventional MPLS TE FRR) and the decapsulation is normally 310 configured to occur at the penultimate hop before the repair tunnel 311 endpoint. In the control plane, a targeted LDP (TLDP) session is 312 needed between the repairing node and the repair tunnel endpoint, 313 which will need to be established and the labels processed before the 314 tunnel can be used. The time to establish the TLDP session and 315 acquire labels will limit the speed at which a new tunnel can be put 316 into service. This is not anticipated to be a problem in normal 317 operation since the managed introduction and removal of links is 318 relatively rare as is the incidence of failure in a well managed 319 network. 321 When a failure is detected, it is necessary to immediately redirect 322 traffic to the repair path. Consequently, the repair tunnel used 323 MUST be provisioned beforehand in anticipation of the failure. Since 324 the location of the repair tunnels is dynamically determined it is 325 necessary to automatically establish the repair tunnels. Multiple 326 repair tunnels may share a tunnel end point. 328 5. Construction of Repair Paths 330 5.1. Identifying Required Tunneled Repair Paths 332 Not all links will require protection using a tunneled repair path. 333 Referring to Figure 1, if E can already be protected via an LFA, S-E 334 does not need to be protected using a repair tunnel, since all 335 destinations normally reachable through E must therefore also be 336 protectable by an LFA. Such an LFA is frequently termed a "link 337 LFA". Tunneled repair paths (which may be calculated per-prefix) are 338 only required for links which do not have a link or per-prefix LFA. 340 It should be noted that using the Q-space of E as a proxy for the 341 Q-space of each destination can result in failing to identify valid 342 remote LFAs. The extent to which this reduces the effective 343 protection coverage is topology dependent. 345 5.2. Determining Tunnel End Points 347 The repair tunnel endpoint needs to be a node in the network 348 reachable from S without traversing S-E. In addition, the repair 349 tunnel end point needs to be a node from which packets will normally 350 flow towards their destination without being attracted back to the 351 failed link S-E. 353 Note that once released from the tunnel, the packet will be 354 forwarded, as normal, on the shortest path from the release point to 355 its destination. This may result in the packet traversing the router 356 E at the far end of the protected link S-E, but this is obviously not 357 required. 359 The properties that are required of repair tunnel end points are 360 therefore: 362 o The repair tunneled point MUST be reachable from the tunnel source 363 without traversing the failed link; and 365 o When released from the tunnel, packets MUST proceed towards their 366 destination without being attracted back over the failed link. 368 Provided both these requirements are met, packets forwarded over the 369 repair tunnel will reach their destination, and will not loop after a 370 single link failure. 372 In some topologies it will not be possible to find a repair tunnel 373 endpoint that exhibits both the required properties. For example if 374 the ring topology illustrated in Figure 1 had a cost of 4 for the 375 link B-C, while the remaining links were cost 1, then it would not be 376 possible to establish a tunnel from S to C (without resorting to some 377 form of source routing). 379 5.2.1. Computing Repair Paths 381 To compute the repair path for link S-E it is necessary to determine 382 the set of routers which can be reached from S without traversing 383 S-E, and match this with the set of routers from which the node E can 384 be reached, by normal forwarding, without traversing the link S-E. 386 The approach used in this memo is as follows: 388 o The method of computing the set of routers which can be reached 389 from S on the shortest path tree without traversing S-E is 390 described. This is called the S's P-space with respect to the 391 failure of link S-E. 393 o The distance of the tunnel endpoint from the point of local repair 394 (PLR) is increased by noting that S is able to use the P-Space of 395 its neighbours with respect to the failure of link S-E, since S 396 can determine which neighbour it will use as the next hop for the 397 repair. This is called the S's Extended P-space with respect to 398 the failure of link S-E. The use of extended P-space allows 399 greater repair coverage and is the preferred approach. 401 o Finally two methods of computing the set of routers from which the 402 node E can be reached, by normal forwarding, without traversing 403 the link S-E. This is called the Q-space of E with respect to the 404 link S-E. 406 The selection of the preferred node from the set of nodes that an in 407 both Extended P-Space and Q-Space with respect to the S-E is 408 described in Section 5.2.2. 410 A suitable cost based algorithm to compute the set of nodes common to 411 both extended P-space and Q-space with respect to the S-E is provided 412 in Section 5.3. 414 5.2.1.1. P-space 416 The set of routers which can be reached from S on the shortest path 417 tree without traversing S-E is termed the P-space of S with respect 418 to the link S-E. This P-space can be obtained by computing a 419 shortest path tree (SPT) rooted at S and excising the sub-tree 420 reached via the link S-E (including those routers which are members 421 of an ECMP that includes link S-E). The exclusion of routers 422 reachable via an ECMP that includes S-E prevents the forwarding 423 subsystem from attempting to execute a repair via the failed link 424 S-E. Thus for example, if the SPF computation stores at each node 425 the next-hops to be used to reach that node from S, then the node can 426 be added to P-space if none of its next-hops are link S-E. In the 427 case of Figure 1 this P-space comprises nodes A and B only. 428 Expressed in cost terms the set of routers {P} are those for which 429 the shortest path cost S->P is strictly less than the shortest path 430 cost S->E->P. 432 5.2.1.2. Extended P-space 434 The description in Section 5.2.1.1 calculated router S's P-space 435 rooted at S itself. However, since router S will only use a repair 436 path when it has detected the failure of the link S-E, the initial 437 hop of the repair path need not be subject to S's normal forwarding 438 decision process. Thus the concept of extended P-space is 439 introduced. Router S's extended P-space is the union of the P-spaces 440 of each of S's neighbours (N). This may be calculated by computing a 441 shortest path tree (SPT) at each of S's neighbors (excluding E) and 442 excising the subtree reached via the path N->S->E. Note this will 443 excise those routers which are reachable through all ECMPs that 444 includes link S-E. The use of extended P-space may allow router S to 445 reach potential repair tunnel end points that were otherwise 446 unreachable. In cost terms a router (P) is in extended P-space if 447 the shortest path cost N->P is strictly less than the shortest path 448 cost N->S->E->P. In other words, once the packet it forced to N by 449 S, it is a lower cost for it to continue on to P by any path except 450 one that takes it back to S and then across the S->E link. 452 Since in the case of Figure 1 node A is a per-prefix LFA for the 453 destination node C, the set of extended P-space nodes with respect to 454 link S-E comprises nodes A, B and C. Since node C is also in E's 455 Q-space with respect to link S-E, there is now a node common to both 456 extended P-space and Q-space which can be used as a repair tunnel 457 end-point to protect the link S-E. 459 5.2.1.3. Q-space 461 The set of routers from which the node E can be reached, by normal 462 forwarding, without traversing the link S-E is termed the Q-space of 463 E with respect to the link S-E. The Q-space can be obtained by 464 computing a reverse shortest path tree (rSPT) rooted at E, with the 465 sub-tree which might traverse the protected link S-E excised (i.e. 466 those nodes that would send the packet via S-E plus those nodes which 467 have an ECMP set to E with one or more members of that ECMP set 468 traversing the protected link S-E). The rSPT uses the cost towards 469 the root rather than from it and yields the best paths towards the 470 root from other nodes in the network. In the case of Figure 1 the 471 Q-space of E with respect to S-E comprises nodes C and D only. 473 Expressed in cost terms the set of routers {Q} are those for which 474 the shortest path cost Q<-E is strictly less than the shortest path 475 cost Q<-S<-E. In Figure 1 the intersection of the E's Q-space with 476 respect to S-E with S's P-space with respect to S-E defines the set 477 of viable repair tunnel end-points, known as "PQ nodes". As can be 478 seen, for the case of Figure 1 there is no common node and hence no 479 viable repair tunnel end-point. However when the extended the 480 extended P-space Section 5.2.1.2 at S with respect to S-E is 481 considered, a suitable intersection is found at C. 483 Note that the Q-space calculation could be conducted for each 484 individual destination and a per-destination repair tunnel end point 485 determined. However this would, in the worst case, require an SPF 486 computation per destination which is not currently considered to be 487 scalable. Therefore the Q-space of E with respect to link S-E is 488 used as a proxy for the Q-space of each destination. This 489 approximation is obviously correct since the repair is only used for 490 the set of destinations which were, prior to the failure, routed 491 through node E. This is analogous to the use of link-LFAs rather 492 than per-prefix LFAs. 494 5.2.2. Selecting Repair Paths 496 The mechanisms described above will identify all the possible repair 497 tunnel end points that can be used to protect a particular link. In 498 a well-connected network there are likely to be multiple possible 499 release points for each protected link. All will deliver the packets 500 correctly so, arguably, it does not matter which is chosen. However, 501 one repair tunnel end point may be preferred over the others on the 502 basis of path cost or some other selection criteria. 504 There is no technical requirement for the selection criteria to be 505 consistent across all routers, but such consistency may be desirable 506 from an operational point of view. In general there are advantages 507 in choosing the repair tunnel end point closest (shortest metric) to 508 S. Choosing the closest maximises the opportunity for the traffic to 509 be load balanced once it has been released from the tunnel. For 510 consistency in behavior, it is RECOMMENDED that the member of the set 511 of routers {PQ} with the lowest cost S->P be the default choice for 512 P. In the event of a tie the router with the lowest node identifier 513 SHOULD be selected. 515 It is a local matter whether the repair path selection policy used by 516 the router favours LFA repairs over RLFA repairs. An LFA repair has 517 the advantage of not requiring the use of tunnel, however network 518 manageability considerations may lead to a repair strategy that uses 519 a remote LFA more frequently [I-D.ietf-rtgwg-lfa-manageability]. 521 As described in [RFC5286], always selecting a PQ node that is 522 downstream to the destination with respect to the repairing node, 523 prevents the formation of loops when the failure is worse than 524 expected. The use of downstream nodes reduces the repair coverage, 525 and operators are advised to determine whether adequate coverage is 526 achieved before enabling this selection feature. 528 5.3. A Cost Based RLFA Algorithm 530 The preceding text has described the computation of the remote LFA 531 repair target (PQ) in terms of the intersection of two reachability 532 graphs computed using a shortest path first (SPF) algorithm. This 533 section describes a method of computing the remote LFA repair target 534 for a specific failed link using a cost based algorithm. The pseudo- 535 code provided in this section avoids unnecessary SPF computations, 536 but for the sake of readability, it does not otherwise try to 537 optimize the code. The algorithm covers the case where the repair 538 first hop is reached via a broadcast or non-broadcast multi-access 539 (NBMA) link such as a LAN. It also covers the case where the P or Q 540 node is attached via such a link. It does not cover the case where 541 the failed interface is a broadcast or non-broadcast multi-access 542 (NBMA) link. To address that case it is necessary to compute the Q 543 space of each neighbor of the repairing router reachable though the 544 LAN, i.e. to treat the pseudonode [RFC1195] as a node failure. This 545 is because the Q spaces of the neighbors of the pseudonode may be 546 disjoint requiring use of a neighbor specific PQ node. The reader is 547 referred to [I-D.ietf-rtgwg-rlfa-node-protection] for further 548 information on the use of RLFA for node repairs. 550 The following notation is used: 552 o D_opt(a,b) is the shortest distance from node a to node b as 553 computed by the SPF. 555 o dest is the packet destination 557 o fail_intf is the failed interface (S-E in the example) 559 o fail_intf.remote_node is the node reachable over interface 560 fail_intf (node E in the example) 562 o intf.remote_node is the set of nodes reachable over interface intf 564 o root is the root of the SPF calculation 566 o self is the node carrying out the computation 568 o y is the node in the network under consideration 569 o y.pseudonode is true if y is a pseudonode 571 ////////////////////////////////////////////////////////////////// 572 // 573 // Main Function 575 ////////////////////////////////////////////////////////////////// 576 // 577 // We have already computed the forward SPF from self to all nodes 578 // y in network and thus we know D_opt (self, y). This is needed 579 // for normal forwarding. 580 // However for completeness. 582 Compute_and_Store_Forward_SPF(self) 584 // To extend P-space we compute the SPF at each neighbour except 585 // the neighbour that is reached via the link being protected. 586 // We will also need D_opt(fail_intf.remote_node,y) so compute 587 // that at the same time. 589 Compute_Neighbor_SPFs() 591 // Compute the set of nodes {P} reachable other than via the 592 // failed link 594 Compute_Extended_P_Space(fail_intf) 596 // Compute the set of nodes that can reach the node on the far 597 // side of the failed link without traversing the failed link. 599 Compute_Q_Space(fail_intf) 601 // Compute the set of candidate RLFA tunnel endpoints 603 Intersect_Extended_P_and_Q_Space() 605 // Make sure that we cannot get looping repairs when the 606 // failure is worse than expected. 608 if (guarantee_no_looping_on_worse_than_protected_failure) 609 Apply_Downstream_Constraint() 611 // 612 // End of Main Function 613 // 614 ////////////////////////////////////////////////////////////////// 615 ////////////////////////////////////////////////////////////////// 616 // 617 // Procedures 618 // 620 ///////////////////////////////////////////////////////////////// 621 // 622 // This computes the SPF from root, and stores the optimum 623 // distance from root to each node y 625 Compute_and_Store_Forward_SPF(root) 626 Compute_Forward_SPF(root) 627 foreach node y in network 628 store D_opt(root,y) 630 ///////////////////////////////////////////////////////////////// 631 // 632 // This computes the optimum distance from each neighbour (other 633 // than the neighbour reachable through the failed link) and 634 // every other node in the network 635 // 636 // Note that we compute this for all neighbours including the 637 // neighbour on the far side the failure. This is done on the 638 // expectation that more than on link will be protected, and 639 // that the results are stored for later use. 640 // 642 Compute_Neighbor_SPFs() 643 foreach interface intf in self 644 Compute_and_Store_Forward_SPF(intf.remote_node) 646 ///////////////////////////////////////////////////////////////// 647 // 648 // The reverse SPF computes the cost from each remote node to 649 // root. This is achieved by running the normal SPF algorithm, 650 // but using the link cost in the direction from the next hop 651 // back towards root in place of the link cost in the direction 652 // away from root towards the next hop. 654 Compute_and_Store_Reverse_SPF(root) 655 Compute_Reverse_SPF(root) 656 foreach node y in network 657 store D_opt(y,root) 659 ///////////////////////////////////////////////////////////////// 660 // 661 // Calculate extended P-space 662 // 663 // Note the strictly less than operator is needed to 664 // avoid ECMP issues. 666 Compute_Extended_P_Space(fail_intf) 667 foreach node y in network 668 y.in_extended_P_space = false 669 // Extend P-space to the P-spaces of all reachable 670 // neighbours 671 foreach interface intf in self 672 // Exclude failed interface, noting that 673 // the node reachable via that interface may be 674 // reachable via another interface (parallel path) 675 if (intf != fail_intf) 676 foreach neighbor n in intf.remote_node 677 // Apply RFC5286 Inequality 1 678 if ( D_opt(n, y) < 679 D_opt(n,self) + D_opt(self, y)) 680 y.in_extended_P_space = true 682 ///////////////////////////////////////////////////////////////// 683 // 684 // Compute the nodes in Q-space 685 // 687 Compute_Q_Space(fail_intf) 688 // Compute the cost from every node the network to the 689 // node normally reachable across the failed link 690 Compute_and_Store_Reverse_SPF(fail_intf.remote_node) 692 // Compute the cost from every node the network to self 693 Compute_and_Store_Reverse_SPF(self) 695 foreach node y in network 696 if ( D_opt(y,fail_intf.remote_node) < D_opt(y,self) + 697 D_opt(self,fail_intf.remote_node) ) 698 y.in_Q_space = true 699 else 700 y.in_Q_space = false 702 ///////////////////////////////////////////////////////////////// 703 // 704 // Compute set of nodes in both extended P-space and in Q-space 706 Intersect_Extended_P_and_Q_Space() 707 foreach node y in network 708 if ( y.in_extended_P_space && y.in_Q_space && 709 y.pseudonode == False) 710 y.valid_tunnel_endpoint = true 711 else 712 y.valid_tunnel_endpoint = false 714 ///////////////////////////////////////////////////////////////// 715 // 716 // A downstream route is one where the next hop is strictly 717 // closer to the destination. By sending the packet to a 718 // PQ node that is downstream, we know that if the PQ node 719 // detects a failure, it will not loop the packet back to self. 720 // This is useful when there are two failures, or a node has 721 // failed rather than a link. 723 Apply_Downstream_Constraint() 724 foreach node y in network 725 if (y.valid_tunnel_endpoint) 726 Compute_and_Store_Forward_SPF(y) 727 if ((D_opt(y,dest) < D_opt(self,dest)) 728 y.valid_tunnel_endpoint = true 729 else 730 y.valid_tunnel_endpoint = false 732 // 733 ///////////////////////////////////////////////////////////////// 735 5.4. Interactions with IS-IS Overload, RFC6987, and Costed Out Links 737 Since normal link state routing takes into account the IS-IS overload 738 bit, [RFC6987], and costing out of links as described in Section 3.5 739 of [RFC5286], the forward SPFs performed by the PLR rooted at the 740 neighbors of the PLR also need to take this into account. A repair 741 tunnel path from a neighbor of the PLR to a repair tunnel endpoint 742 will generally avoid the nodes and links excluded by the IGP 743 overload/costing out rules. However, there are two situations where 744 this behavior may result in a repair path traversing a link or router 745 that should be excluded: 747 1. When the first hop on the repair tunnel path (from the PLR to a 748 direct neighbor) does not follow the IGP shortest path. In this 749 case, the PLR MUST NOT use a repair tunnel path whose first hop 750 is along a link whose cost or reverse cost is MaxLinkMetric (for 751 OSPF) or the maximum cost (for IS-IS) or, has the overload bit 752 set (for IS-IS). 754 2. The IS-IS overload bit and the mechanism of [RFC6987] only 755 prevent transit traffic from traversing a node. They do not 756 prevent traffic destined to a node. The per-neighbor forward 757 SPFs using the standard IGP overload rules will not prevent a PLR 758 from choosing a repair tunnel endpoint that is advertising a 759 desire to not carry transit traffic. Therefore, the PLR MUST NOT 760 use a repair tunnel endpoint with the IS-IS overload bit set, or 761 where all outgoing interfaces have the cost set to MaxLinkMetric 762 for OSPF. 764 6. Example Application of Remote LFAs 766 An example of a commonly deployed topology which is not fully 767 protected by LFAs alone is shown in Figure 3. PE1 and PE2 are 768 connected in the same site. P1 and P2 may be geographically 769 separated (inter-site). In order to guarantee the lowest latency 770 path from/to all other remote PEs, normally the shortest path follows 771 the geographical distance of the site locations. Therefore, to 772 ensure this, a lower IGP metric (5) is assigned between PE1 and PE2. 773 A high metric (1000) is set on the P-PE links to prevent the PEs 774 being used for transit traffic. The PEs are not individually dual- 775 homed in order to reduce costs. 777 This is a common topology in SP networks. 779 When a failure occurs on the link between PE1 and P1, PE1 does not 780 have an LFA for traffic reachable via P1. Similarly, by symmetry, if 781 the link between PE2 and P2 fails, PE2 does not have an LFA for 782 traffic reachable via P2. 784 Increasing the metric between PE1 and PE2 to allow the LFA would 785 impact the normal traffic performance by potentially increasing the 786 latency. 788 | 100 | 789 -P1---------P2- 790 \ / 791 1000 \ / 1000 792 PE1---PE2 793 5 795 Figure 3: Example SP topology 797 Clearly, full protection can be provided, using the techniques 798 described in this document, by PE1 choosing P2 as the remote LFA 799 repair target node, and PE2 choosing P1 as the remote LFA repair 800 target. 802 7. Node Failures 804 When the failure is a node failure rather than a point-to-point link 805 failure there is a danger that the RLFA repair will loop. This is 806 discussed in detail in [I-D.bryant-ipfrr-tunnels]. In summary the 807 problem is that two of more of E's neighbors each with E as the next 808 hop to some destination D may attempt to repair a packet addressed to 809 destination D via the other neighbor and then E, thus causing a loop 810 to form. A similar problem exists in the case of a shared risk link 811 group failure where the PLR for each failure attempts to repair via 812 the other failure. As will be noted from [I-D.bryant-ipfrr-tunnels], 813 this can rapidly become a complex problem to address. 815 There are a number of ways to minimize the probability of a loop 816 forming when a node failure occurs and there exists the possibility 817 that two of E's neighbors may form a mutual repair. 819 1. Detect when a packet has arrived on some interface I that is also 820 the interface used to reach the first hop on the RLFA path to the 821 remote LFA repair target, and drop the packet. This is useful in 822 the case of a ring topology. 824 2. Require that the path from the remote LFA repair target to 825 destination D never passes through E (including in the ECMP 826 case), i.e. only use node protecting paths in which the cost from 827 the remote LFA repair target to D is strictly less than the cost 828 from the remote LFA repair target to E plus the cost E to D. 830 3. Require that where the packet may pass through another neighbor 831 of E, that node is down stream (i.e. strictly closer to D than 832 the repairing node). This means that some neighbor of E (X) can 833 repair via some other neighbor of E (Y), but Y cannot repair via 834 X. 836 Case 1 accepts that loops may form and suppresses them by dropping 837 packets. Dropping packets may be considered less detrimental than 838 looping packets. This approach may also lead to dropping some 839 legitimate packets. Cases 2 and 3 above prevent the formation of a 840 loop, but at the expense of a reduced repair coverage and at the cost 841 of additional complexity in the algorithm to compute the repair path. 842 Alternatively one might choose to assume that the probability of a 843 node failure is sufficiently rare that the issue of looping RLFA 844 repairs can be ignored. 846 The probability of a node failure and the consequences of node 847 failure in any particular topology will depend on the node design, 848 the particular topology in use, and the strategy adopted under node 849 failure. It is recommended that a network operator perform an 850 analysis of the consequences and probability of node failure in their 851 network, and determine whether the incidence and consequence of 852 occurrence are acceptable. 854 This topic is further discussed in 855 [I-D.ietf-rtgwg-rlfa-node-protection]. 857 8. Operation in an LDP environment 859 Where this technique is used in an MPLS network using LDP [RFC5036], 860 and S is a transit node, S will need to swap the top label in the 861 stack for the remote LFA repair target's (PQ's) label to the 862 destination, and to then push its own label for the remote LFA repair 863 target. 865 In the example Figure 2 S already has the first hop (A) label for the 866 remote LFA repair target (C) as a result of the ordinary operation of 867 LDP. To get the remote LFA repair target's label (C's label) for the 868 destination (D), S needs to establish a targeted LDP session with C. 869 The label stack for normal operation and RLFA operation is shown 870 below in Figure 4. 872 +-----------------+ +-----------------+ +-----------------+ 873 | datalink | | datalink | | datalink | 874 +-----------------+ +-----------------+ +-----------------+ 875 | S's label for D | | E's label for D | | A's label for C | 876 +-----------------+ +-----------------+ +-----------------+ 877 | Payload | | Payload | | C's label for D | 878 +-----------------+ +-----------------+ +-----------------+ 879 X Y | Payload | 880 +-----------------+ 881 Z 883 X = Normal label stack packet arriving at S 884 Y = Normal label stack packet leaving S 885 Z = RLFA label stack to D via C as the remote LFA repair target. 887 Figure 4 889 To establish an targeted LDP session with a candidate remote LFA 890 repair target node the repairing node (S) needs to know what IP 891 address that the remote LFA repair target is willing to use for 892 targeted LDP sessions. Ideally this is provided by the remote LFA 893 repair target advertising this address in the IGP in use. Which 894 address is used, how this is advertised in the IGP, and whether this 895 is a special IP address or an IP address also used for some other 896 purpose is out of scope for this document and must be specified in an 897 IGP specific RFC. 899 In the absence of a protocol to learn the preferred IP address for 900 targeted LDP, an LSR should attempt a targeted LDP session with the 901 Router ID [RFC2328] [RFC5305] [RFC5340] [RFC6119] 902 [I-D.ietf-ospf-routable-ip-address], unless it is configured 903 otherwise. 905 No protection is available until the TLDP session has been 906 established and a label for the destination has been learned from the 907 remote LFA repair target. If for any reason the TLDP session cannot 908 be established, an implementation SHOULD advise the operator about 909 the protection setup issue through the network management system. 911 9. Analysis of Real World Topologies 913 This section gives the results of analysing a number of real world 914 service provider topologies collected between the end of 2012 and 915 early 2013 917 9.1. Topology Details 919 The figure below characterises each topology (topo) studied in terms 920 of : 922 o The number of nodes (# nodes) excluding pseudonodes. 924 o The number of bidirectional links ( # links) including parallel 925 links and links to and from pseudonodes. 927 o The number of node pairs that are connected by one or more links 928 (# pairs). 930 o The number of node pairs that are connected by more than one (i.e. 931 parallel) link ( # para). 933 o The number of links (excluding pseudonode links, which are by 934 definition asymmetric) that have asymmetric metrics (#asym). 936 +------+---------+---------+---------+--------+--------+ 937 | topo | # nodes | # links | # pairs | # para | # asym | 938 +------+---------+---------+---------+--------+--------+ 939 | 1 | 315 | 570 | 560 | 10 | 3 | 940 | 2 | 158 | 373 | 312 | 33 | 0 | 941 | 3 | 655 | 1768 | 1314 | 275 | 1195 | 942 | 4 | 1281 | 2326 | 2248 | 70 | 10 | 943 | 5 | 364 | 811 | 659 | 80 | 86 | 944 | 6 | 114 | 318 | 197 | 101 | 4 | 945 | 7 | 55 | 237 | 159 | 67 | 2 | 946 | 8 | 779 | 1848 | 1441 | 199 | 437 | 947 | 9 | 263 | 482 | 413 | 41 | 12 | 948 | 10 | 86 | 375 | 145 | 64 | 22 | 949 | 11 | 162 | 1083 | 351 | 201 | 49 | 950 | 12 | 380 | 1174 | 763 | 231 | 0 | 951 | 13 | 1051 | 2087 | 2037 | 48 | 64 | 952 | 14 | 92 | 291 | 204 | 64 | 2 | 953 +------+---------+---------+---------+--------+--------+ 955 9.2. LFA only 957 The figure below shows the percentage of protected destinations (% 958 prot) and percentage of guaranteed node protected destinations ( % 959 gtd N) for the set of topologies characterized in Section 9.1 960 achieved using only LFA repairs. 962 These statistics were generated by considering each node and then 963 considering each link to each next hop to each destination. The 964 percentage of such links across the entire network that are protected 965 against link failure was determined. This is the percentage of 966 protected destinations. If a link is protected against the failure 967 of the next hop node, this is considered guaranteed node protecting 968 (GNP) and percentage of guaranteed node protected destinations is 969 calculated using the same method used for calculating the link 970 protection coverage. 972 GNP is identical to Node-protecting as defined in [RFC5714] and does 973 not include the additional node protection coverage obtained by the 974 de facto node-protecting condition described in [RFC6571]. 976 +------+--------+---------+ 977 | topo | % prot | % gtd N | 978 +------+--------+---------+ 979 | 1 | 78.5 | 36.9 | 980 | 2 | 97.3 | 52.4 | 981 | 3 | 99.3 | 58 | 982 | 4 | 83.1 | 63.1 | 983 | 5 | 99 | 59.1 | 984 | 6 | 86.4 | 21.4 | 985 | 7 | 93.9 | 35.4 | 986 | 8 | 95.3 | 48.1 | 987 | 9 | 82.2 | 49.5 | 988 | 10 | 98.5 | 14.9 | 989 | 11 | 99.6 | 24.8 | 990 | 12 | 99.5 | 62.4 | 991 | 13 | 92.4 | 51.6 | 992 | 14 | 99.3 | 48.6 | 993 +------+--------+---------+ 995 9.3. RLFA 997 The figure below shows the percentage of protected destinations (% 998 prot) and % guaranteed node protected destinations ( % gtd N) for 999 RLFA protection in the topologies studies. In addition, it show the 1000 percentage of destinations using an RLFA repair (% PQ) together with 1001 the total number of unidirectional RLFA targeted LDP session 1002 established (# PQ), the number of PQ sessions which would be required 1003 for complete protection, but which could not be established because 1004 there was no PQ node, i.e. the number of cases whether neither LFA or 1005 RLFA protection was possible (no PQ). It also shows the 50 (p50), 90 1006 (p90) and 100 (p100) percentiles for the number of individual LDP 1007 sessions terminating at an individual node (whether used for TX, RX 1008 or both). 1010 For example, if there were LDP sessions required A->B, A->C, C->A, 1011 C->D, these would be counted as 2, 1, 2, 1 at nodes A,B,C and D 1012 respectively because:- 1014 A has two sessions (to nodes B and C) 1016 B has one session (to node A) 1018 C has two sessions (to nodes A and D) 1020 D has one session (to node D) 1022 In this study, remote LFA is only used when necessary. i.e. when 1023 there is at least one destination which is not reparable by a per 1024 destination LFA, and a single remote LFA tunnel is used (if 1025 available) to repair traffic to all such destinations. The remote 1026 LFA repair target points are computed using extended P space and 1027 choosing the PQ node which has the lowest metric cost from the 1028 repairing node. 1030 +------+--------+--------+------+------+-------+-----+-----+------+ 1031 | topo | % prot |% gtd N | % PQ | # PQ | no PQ | p50 | p90 | p100 | 1032 +------+--------+--------+------+------+-------+-----+-----+------+ 1033 | 1 | 99.7 | 53.3 | 21.2 | 295 | 3 | 1 | 5 | 14 | 1034 | 2 | 97.5 | 52.4 | 0.2 | 7 | 40 | 0 | 0 | 2 | 1035 | 3 | 99.999 | 58.4 | 0.7 | 63 | 5 | 0 | 1 | 5 | 1036 | 4 | 99 | 74.8 | 16 | 1424 | 54 | 1 | 3 | 23 | 1037 | 5 | 99.5 | 59.5 | 0.5 | 151 | 7 | 0 | 2 | 7 | 1038 | 6 | 100 | 34.9 | 13.6 | 63 | 0 | 1 | 2 | 6 | 1039 | 7 | 99.999 | 40.6 | 6.1 | 16 | 2 | 0 | 2 | 4 | 1040 | 8 | 99.5 | 50.2 | 4.3 | 350 | 39 | 0 | 2 | 15 | 1041 | 9 | 99.5 | 55 | 17.3 | 428 | 5 | 1 | 2 | 67 | 1042 | 10 | 99.6 | 14.1 | 1 | 49 | 7 | 1 | 2 | 5 | 1043 | 11 | 99.9 | 24.9 | 0.3 | 85 | 1 | 0 | 2 | 8 | 1044 | 12 | 99.999 | 62.8 | 0.5 | 512 | 4 | 0 | 0 | 3 | 1045 | 13 | 97.5 | 54.6 | 5.1 | 1188 | 95 | 0 | 2 | 27 | 1046 | 14 | 100 | 48.6 | 0.7 | 79 | 0 | 0 | 2 | 4 | 1047 +------+--------+--------+------+------+-------+-----+-----+------+ 1049 Another study[ISOCORE2010] confirms the significant coverage increase 1050 provided by Remote LFAs. 1052 9.4. Comparison of LFA an RLFA results 1054 The table below provides a side by side comparison the LFA and the 1055 remote LFA results. This shows a significant improvement in the 1056 percentage of protected destinations and normally a modest 1057 improvement in the percentage of guaranteed node protected 1058 destinations. 1060 +------+--------+--------+---------+---------+ 1061 | topo | LFA | RLFA | LFA | RLFA | 1062 | | % prot | %prot | % gtd N | % gtd N | 1063 +------+--------+--------+---------+---------+ 1064 | 1 | 78.5 | 99.7 | 36.9 | 53.3 | 1065 | 2 | 97.3 | 97.5 | 52.4 | 52.4 | 1066 | 3 | 99.3 | 99.999 | 58 | 58.4 | 1067 | 4 | 83.1 | 99 | 63.1 | 74.8 | 1068 | 5 | 99 | 99.5 | 59.1 | 59.5 | 1069 | 6 | 86.4 |100 | 21.4 | 34.9 | 1070 | 7 | 93.9 | 99.999 | 35.4 | 40.6 | 1071 | 8 | 95.3 | 99.5 | 48.1 | 50.2 | 1072 | 9 | 82.2 | 99.5 | 49.5 | 55 | 1073 | 10 | 98.5 | 99.6 | 14.9 | 14.1 | 1074 | 11 | 99.6 | 99.9 | 24.8 | 24.9 | 1075 | 12 | 99.5 | 99.999 | 62.4 | 62.8 | 1076 | 13 | 92.4 | 97.5 | 51.6 | 54.6 | 1077 | 14 | 99.3 |100 | 48.6 | 48.6 | 1078 +------+--------+--------+---------+---------+ 1080 As shown in the table, remote LFA provides close to 100% prefix 1081 protection against link failure in 11 of the 14 topologies studied, 1082 and provides a significant improvement in two of the remaining three 1083 cases. Note that in an MPLS network the tunnels to the PQ nodes are 1084 always present as a property of an LDP-based deployment. 1086 In the small number of cases where there is no intersection between 1087 the (extended)P-space and the Q-space, a number of solutions to 1088 providing a suitable path between such disjoint regions in the 1089 network have been discussed in the working group. For example an 1090 explicitly routed LSP between P and Q might be set up using RSVP-TE 1091 or using Segment Routing [I-D.filsfils-spring-segment-routing]. Such 1092 extended repair methods are outside the scope of this document. 1094 10. Management and Operational Considerations 1096 The management of LFA and remote LFA is the subject of ongoing work 1097 withing the IETF [I-D.ietf-rtgwg-lfa-manageability] to which the 1098 reader is referred. Management considerations may lead to a 1099 preference for the use of a remote LFA over an available LFA. This 1100 preference is a matter for the network operator, and not a matter of 1101 protocol correctness. 1103 When the network re-converges, microloops [RFC5715] can form due to 1104 transient inconsistencies in the forwarding tables of different 1105 routers. If it is determined that microloops are a significant issue 1106 in the deployment, then a suitable loop free convergence methods such 1107 as one of those described in [RFC5715], [RFC6976], or 1108 [I-D.litkowski-rtgwg-uloop-delay] should be implemented. 1110 11. Historical Note 1112 The basic concepts behind Remote LFA were invented in 2002 and were 1113 later included in [I-D.bryant-ipfrr-tunnels], submitted in 2004. 1115 [I-D.bryant-ipfrr-tunnels], targeted a 100% protection coverage and 1116 hence included additional mechanisms on top of the Remote LFA 1117 concept. The addition of these mechanisms made the proposal very 1118 complex and computationally intensive and it was therefore not 1119 pursued as a working group item. 1121 As explained in [RFC6571], the purpose of the LFA FRR technology is 1122 not to provide coverage at any cost. A solution for this already 1123 exists with MPLS TE FRR. MPLS TE FRR is a mature technology which is 1124 able to provide protection in any topology thanks to the explicit 1125 routing capability of MPLS TE. 1127 The purpose of LFA FRR technology is to provide for a simple FRR 1128 solution when such a solution is possible. The first step along this 1129 simplicity approach was "local" LFA [RFC5286]. This specification of 1130 "Remote LFA" is a natural second step. 1132 12. IANA Considerations 1134 There are no IANA considerations that arise from this architectural 1135 description of IPFRR. The RFC Editor may remove this section on 1136 publication. 1138 13. Security Considerations 1140 The security considerations of [RFC5286] also apply. 1142 Targeted LDP sessions and MPLS tunnels are normal features of an MPLS 1143 network and their use in this application raises no additional 1144 security concerns. 1146 IP repair tunnel endpoints (where used) SHOULD be assigned from a set 1147 of addresses that are not reachable from outside the routing domain. 1148 This would prevent their use as an attack vector. 1150 Other than OAM traffic, used to verify the correct operation of a 1151 repair tunnel, only traffic that is being protected as a result of a 1152 link failure is placed a repair tunnel. The repair tunnel MUST NOT 1153 be advertised by the routing protocol as a link that may be used to 1154 carry normal user traffic, or routing protocol traffic. 1156 14. Acknowledgments 1158 The authors wish to thank Levente Csikor and Chris Bowers for their 1159 contribution to the cost based algorithm text. The authors thank 1160 Alia Atlas, Ross Callon, Stephane Litkowski, Bharath R, Pushpasis 1161 Sarkar and Adrian Farrel for their review of this document. 1163 15. References 1165 15.1. Normative References 1167 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1168 Requirement Levels", BCP 14, RFC 2119, March 1997. 1170 [RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast 1171 Reroute: Loop-Free Alternates", RFC 5286, September 2008. 1173 [RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", RFC 1174 5714, January 2010. 1176 15.2. Informative References 1178 [I-D.bryant-ipfrr-tunnels] 1179 Bryant, S., Filsfils, C., Previdi, S., and M. Shand, "IP 1180 Fast Reroute using tunnels", draft-bryant-ipfrr-tunnels-03 1181 (work in progress), November 2007. 1183 [I-D.filsfils-spring-segment-routing] 1184 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 1185 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 1186 Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, 1187 "Segment Routing Architecture", draft-filsfils-spring- 1188 segment-routing-04 (work in progress), July 2014. 1190 [I-D.ietf-ospf-routable-ip-address] 1191 Xu, X., Chunduri, U., and M. Bhatia, "Carrying Routable IP 1192 Addresses in OSPF RI LSA", draft-ietf-ospf-routable-ip- 1193 address-01 (work in progress), October 2014. 1195 [I-D.ietf-rtgwg-lfa-manageability] 1196 Litkowski, S., Decraene, B., Filsfils, C., Raza, K., 1197 Horneffer, M., and P. Sarkar, "Operational management of 1198 Loop Free Alternates", draft-ietf-rtgwg-lfa- 1199 manageability-07 (work in progress), January 2015. 1201 [I-D.ietf-rtgwg-rlfa-node-protection] 1202 Sarkar, P., Gredler, H., Hegde, S., Bowers, C., Litkowski, 1203 S., and H. Raghuveer, "Remote-LFA Node Protection and 1204 Manageability", draft-ietf-rtgwg-rlfa-node-protection-01 1205 (work in progress), December 2014. 1207 [I-D.litkowski-rtgwg-uloop-delay] 1208 Litkowski, S., Decraene, B., Filsfils, C., and P. 1209 Francois, "Microloop prevention by introducing a local 1210 convergence delay", draft-litkowski-rtgwg-uloop-delay-03 1211 (work in progress), February 2014. 1213 [ISOCORE2010] 1214 So, N., Lin, T., and C. Chen, "LFA (Loop Free Alternates) 1215 Case Studies in Verizon's LDP Network", 2010. 1217 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 1218 dual environments", RFC 1195, December 1990. 1220 [RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic 1221 Routing Encapsulation (GRE)", RFC 1701, October 1994. 1223 [RFC1853] Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995. 1225 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 1227 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 1228 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 1229 Encoding", RFC 3032, January 2001. 1231 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 1232 Specification", RFC 5036, October 2007. 1234 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 1235 Engineering", RFC 5305, October 2008. 1237 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 1238 for IPv6", RFC 5340, July 2008. 1240 [RFC5715] Shand, M. and S. Bryant, "A Framework for Loop-Free 1241 Convergence", RFC 5715, January 2010. 1243 [RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic 1244 Engineering in IS-IS", RFC 6119, February 2011. 1246 [RFC6571] Filsfils, C., Francois, P., Shand, M., Decraene, B., 1247 Uttaro, J., Leymann, N., and M. Horneffer, "Loop-Free 1248 Alternate (LFA) Applicability in Service Provider (SP) 1249 Networks", RFC 6571, June 2012. 1251 [RFC6976] Shand, M., Bryant, S., Previdi, S., Filsfils, C., 1252 Francois, P., and O. Bonaventure, "Framework for Loop-Free 1253 Convergence Using the Ordered Forwarding Information Base 1254 (oFIB) Approach", RFC 6976, July 2013. 1256 [RFC6987] Retana, A., Nguyen, L., Zinin, A., White, R., and D. 1257 McPherson, "OSPF Stub Router Advertisement", RFC 6987, 1258 September 2013. 1260 Authors' Addresses 1262 Stewart Bryant 1263 Cisco Systems 1264 250, Longwater, Green Park, 1265 Reading RG2 6GB, UK 1266 UK 1268 Email: stbryant@cisco.com 1270 Clarence Filsfils 1271 Cisco Systems 1272 De Kleetlaan 6a 1273 1831 Diegem 1274 Belgium 1276 Email: cfilsfil@cisco.com 1278 Stefano Previdi 1279 Cisco Systems 1281 Email: sprevidi@cisco.com 1283 Mike Shand 1284 Independent Contributor 1286 Email: imc.shand@gmail.com 1287 Ning So 1288 Vinci Systems 1290 Email: ning.so@vinci-systems.com