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