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