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