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