idnits 2.17.1 draft-ietf-rtgwg-remote-lfa-02.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 -- The document date (May 23, 2013) is 3991 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 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 24, 2013 Cisco Systems 6 M. Shand 7 Independent Contributor 8 N. So 9 Tata Communications 10 May 23, 2013 12 Remote LFA FRR 13 draft-ietf-rtgwg-remote-lfa-02 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 link failures when none can be provided by the basic 20 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, 2013. 45 Copyright Notice 47 Copyright (c) 2013 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 1. Terminology 62 This draft uses the terms defined in [RFC5714]. This section defines 63 additional terms used in this draft. 65 Extended P-space 67 The union of the P-space of the neighbours of a 68 specific router with respect to the protected link. 70 P-space P-space is the set of routers reachable from a 71 specific router without any path (including equal cost 72 path splits) transiting the protected link. 74 For example, the P-space of S, is the set of routers 75 that S can reach without using the protected link S-E. 77 PQ node A node which is a member of both the extended P-space 78 and the Q-space. 80 Q-space Q-space is the set of routers from which a specific 81 router can be reached without any path (including 82 equal cost path splits) transiting the protected link. 84 Repair tunnel A tunnel established for the purpose of providing a 85 virtual neighbor which is a Loop Free Alternate. 87 Remote LFA The tail-end of a repair tunnel. This tail-end is a 88 member of both the extended-P space the Q space. It 89 is also termed a "PQ" node. 91 In this document we use the notation X-Y to mean the path from X to Y 92 over the link directly connecting X and Y, whilst the notation X->Y 93 refers to the shortest path from X to Y via some set of unspecified 94 nodes including the null set (i.e. including over a link directly 95 connecting X and Y). 97 2. Introduction 99 RFC 5714 [RFC5714] describes a framework for IP Fast Re-route and 100 provides a summary of various proposed IPFRR solutions. A basic 101 mechanism using loop-free alternates (LFAs) is described in [RFC5286] 102 that provides good repair coverage in many 103 topologies[I-D.filsfils-rtgwg-lfa-applicability], especially those 104 that are highly meshed. However, some topologies, notably ring based 105 topologies are not well protected by LFAs alone. This is illustrated 106 in Figure 1 below. 108 S---E 109 / \ 110 A D 111 \ / 112 B---C 114 Figure 1: A simple ring topology 116 If all link costs are equal, the link S-E cannot be fully protected 117 by LFAs. The destination C is an ECMP from S, and so can be 118 protected when S-E fails, but D and E are not protectable using LFAs 120 This draft describes extensions to the basic repair mechanism in 121 which tunnels are used to provide additional logical links which can 122 then be used as loop free alternates where none exist in the original 123 topology. For example if a tunnel is provided between S and C as 124 shown in Figure 2 then C, now being a direct neighbor of S would 125 become an LFA for D and E. The non-failure traffic distribution is 126 not disrupted by the provision of such a tunnel since it is only used 127 for repair traffic and MUST NOT be used for normal traffic. 129 S---E 130 / \ \ 131 A \ D 132 \ \ / 133 B---C 135 Figure 2: The addition of a tunnel 137 The use of this technique is not restricted to ring based topologies, 138 but is a general mechanism which can be used to enhance the 139 protection provided by LFAs. 141 This technique describes in this document is directed at providing 142 repairs in the case of link failures. Considerations regarding node 143 failures are discussed in Section 6. 145 3. Repair Paths 147 As with LFA FRR, when a router detects an adjacent link failure, it 148 uses one or more repair paths in place of the failed link. Repair 149 paths are pre-computed in anticipation of later failures so they can 150 be promptly activated when a failure is detected. 152 A tunneled repair path tunnels traffic to some staging point in the 153 network from which it is assumed that, in the absence of multiple 154 failures, it will travel to its destination using normal forwarding 155 without looping back. This is equivalent to providing a virtual 156 loop-free alternate to supplement the physical loop-free alternates. 157 Hence the name "Remote LFA FRR". When a link cannot be entirely 158 protected with local LFA neighbors, the protecting router seeks the 159 help of a remote LFA staging point. 161 3.1. Tunnels as Repair Paths 163 Consider an arbitrary protected link S-E. In LFA FRR, if a path to 164 the destination from a neighbor N of S does not cause a packet to 165 loop back over the link S-E (i.e. N is a loop-free alternate), then 166 S can send the packet to N and the packet will be delivered to the 167 destination using the pre-failure forwarding information. If there 168 is no such LFA neighbor, then S may be able to create a virtual LFA 169 by using a tunnel to carry the packet to a point in the network which 170 is not a direct neighbor of S from which the packet will be delivered 171 to the destination without looping back to S. In this document such 172 a tunnel is termed a repair tunnel. The tail-end of this tunnel is 173 called a "remote LFA" or a "PQ node". 175 Note that the repair tunnel terminates at some intermediate router 176 between S and E, and not E itself. This is clearly the case, since 177 if it were possible to construct a tunnel from S to E then a 178 conventional LFA would have been sufficient to effect the repair. 180 3.2. Tunnel Requirements 182 There are a number of IP in IP tunnel mechanisms that may be used to 183 fulfil the requirements of this design, such as IP-in-IP [RFC1853] 184 and GRE[RFC1701] . 186 In an MPLS enabled network using LDP[RFC5036], a simple label 187 stack[RFC3032] may be used to provide the required repair tunnel. In 188 this case the outer label is S's neighbor's label for the repair 189 tunnel end point, and the inner label is the repair tunnel end 190 point's label for the packet destination. In order for S to obtain 191 the correct inner label it is necessary to establish a directed LDP 192 session[RFC5036] to the tunnel end point. 194 The selection of the specific tunnelling mechanism (and any necessary 195 enhancements) used to provide a repair path is outside the scope of 196 this document. The authors simply note that deployment in an MPLS/ 197 LDP environment is extremely simple and straight-forward as an LDP 198 LSP from S to the PQ node is readily available, and hence does not 199 require any new protocol extension or design change. This LSP is 200 automatically established as a basic property of LDP behavior. The 201 performance of the encapsulation and decapsulation is also excellent 202 as encapsulation is just a push of one label (like conventional MPLS 203 TE FRR) and the decapsulation occurs naturally at the penultimate hop 204 before the PQ node. 206 When a failure is detected, it is necessary to immediately redirect 207 traffic to the repair path. Consequently, the repair tunnel used 208 must be provisioned beforehand in anticipation of the failure. Since 209 the location of the repair tunnels is dynamically determined it is 210 necessary to establish the repair tunnels without management action. 211 Multiple repairs may share a tunnel end point. 213 4. Construction of Repair Paths 215 4.1. Identifying Required Tunneled Repair Paths 217 Not all links will require protection using a tunneled repair path. 218 Referring to Figure 1, if E can already be protected via an LFA, S-E 219 does not need to be protected using a repair tunnel, since all 220 destinations normally reachable through E must therefore also be 221 protectable by an LFA. Such an LFA is frequently termed a "link 222 LFA". Tunneled repair paths are only required for links which do not 223 have a link LFA. 225 4.2. Determining Tunnel End Points 227 The repair tunnel endpoint needs to be a node in the network 228 reachable from S without traversing S-E. In addition, the repair 229 tunnel end point needs to be a node from which packets will normally 230 flow towards their destination without being attracted back to the 231 failed link S-E. 233 Note that once released from the tunnel, the packet will be 234 forwarded, as normal, on the shortest path from the release point to 235 its destination. This may result in the packet traversing the router 236 E at the far end of the protected link S-E., but this is obviously 237 not required. 239 The properties that are required of repair tunnel end points are 240 therefore: 242 o The repair tunneled point MUST be reachable from the tunnel source 243 without traversing the failed link; and 245 o When released, tunneled packets MUST proceed towards their 246 destination without being attracted back over the failed link. 248 Provided both these requirements are met, packets forwarded over the 249 repair tunnel will reach their destination and will not loop. 251 In some topologies it will not be possible to find a repair tunnel 252 endpoint that exhibits both the required properties. For example if 253 the ring topology illustrated in Figure 1 had a cost of 4 for the 254 link B-C, while the remaining links were cost 1, then it would not be 255 possible to establish a tunnel from S to C (without resorting to some 256 form of source routing). 258 4.2.1. Computing Repair Paths 260 The set of routers which can be reached from S without traversing S-E 261 is termed the P-space of S with respect to the link S-E. The P-space 262 can be obtained by computing a shortest path tree (SPT) rooted at S 263 and excising the sub-tree reached via the link S-E (including those 264 which are members of an ECMP). In the case of Figure 1 the P-space 265 comprises nodes A and B only. Expressed in cost terms the set of 266 routers {P} are those for which the shortest path cost S->P is 267 strictly less than the shortest path cost S->E->P. 269 The set of routers from which the node E can be reached, by normal 270 forwarding, without traversing the link S-E is termed the Q-space of 271 E with respect to the link S-E. The Q-space can be obtained by 272 computing a reverse shortest path tree (rSPT) rooted at E, with the 273 sub-tree which traverses the failed link excised (including those 274 which are members of an ECMP). The rSPT uses the cost towards the 275 root rather than from it and yields the best paths towards the root 276 from other nodes in the network. In the case of Figure 1 the Q-space 277 comprises nodes C and D only. Expressed in cost terms the set of 278 routers {Q} are those for which the shortest path cost E->Q is 279 strictly less than the shortest path cost E->S->Q. In Figure 1 the 280 intersection of the E's Q-space with S's P-space defines the set of 281 viable repair tunnel end-points, known as "PQ nodes". As can be 282 seen, for the case of Figure 1 there is no common node and hence no 283 viable repair tunnel end-point. 285 Note that the Q-space calculation could be conducted for each 286 individual destination and a per-destination repair tunnel end point 287 determined. However this would, in the worst case, require an SPF 288 computation per destination which is not currently considered to be 289 scalable. We therefore use the Q-space of E as a proxy for the 290 Q-space of each destination. This approximation is obviously correct 291 since the repair is only used for the set of destinations which were, 292 prior to the failure, routed through node E. This is analogous to 293 the use of link-LFAs rather than per-prefix LFAs. 295 4.2.2. Extended P-space 297 The description in Section 4.2.1 calculated router S's P-space rooted 298 at S itself. However, since router S will only use a repair path 299 when it has detected the failure of the link S-E, the initial hop of 300 the repair path need not be subject to S's normal forwarding decision 301 process. Thus we introduce the concept of extended P-space. Router 302 S's extended P-space is the union of the P-spaces of each of S's 303 neighbours. This may be calculated by computing the an SPT at each 304 of S's neighbors (N) (excluding E) and excising the subtree reached 305 via the path N->S->E. The use of extended P-space may allow router S 306 to reach potential repair tunnel end points that were otherwise 307 unreachable. In cost terms a router is in extended P-space if the 308 shortest path cost S-N->P is strictly less than the shortest path 309 cost S-E->P. 311 Another way to describe extended P-space is that it is the union of ( 312 un-extended ) P-space and the set of destinations for which S has a 313 per-prefix LFA protecting the link S-E. i.e. the repair tunnel end 314 point can be reached either directly or using a per-prefix LFA. 316 Since in the case of Figure 1 node A is a per-prefix LFA for the 317 destination node C, the set of extended P-space nodes comprises nodes 318 A, B and C. Since node C is also in E's Q-space, there is now a node 319 common to both extended P-space and Q-space which can be used as a 320 repair tunnel end-point to protect the link S-E. 322 4.2.3. Selecting Repair Paths 324 The mechanisms described above will identify all the possible repair 325 tunnel end points that can be used to protect a particular link. In 326 a well-connected network there are likely to be multiple possible 327 release points for each protected link. All will deliver the packets 328 correctly so, arguably, it does not matter which is chosen. However, 329 one repair tunnel end point may be preferred over the others on the 330 basis of path cost or some other selection criteria. 332 There is no technical requirement for the selection criteria to be 333 consistent across all routers, but such consistency may be desirable 334 from an operational point of view. In general there are advantages 335 in choosing the repair tunnel end point closest (shortest metric) to 336 S. Choosing the closest maximises the opportunity for the traffic to 337 be load balanced once it has been released from the tunnel. For 338 consistency in behavior is RECOMMENDED that member of the set of 339 routers {P} with the lowest cost S->P be the default choice for P. 340 In the event of a tie the router with the lowest node identifier 341 SHOULD be selected. 343 5. Example Application of Remote LFAs 345 An example of a commonly deployed topology which is not fully 346 protected by LFAs alone is shown in Figure 3. PE1 and PE2 are 347 connected in the same site. P1 and P2 may be geographically 348 separated (inter-site). In order to guarantee the lowest latency 349 path from/to all other remote PEs, normally the shortest path follows 350 the geographical distance of the site locations. Therefore, to 351 ensure this, a lower IGP metric (5) is assigned between PE1 and PE2. 352 A high metric (1000) is set on the P-PE links to prevent the PEs 353 being used for transit traffic. The PEs are not individually dual- 354 homed in order to reduce costs. 356 This is a common topology in SP networks. 358 When a failure occurs on the link between PE1 and P2, PE1 does not 359 have an LFA for traffic reachable via P1. Similarly, by symmetry, if 360 the link between PE2 and P1 fails, PE2 does not have an LFA for 361 traffic reachable via P2. 363 Increasing the metric between PE1 and PE2 to allow the LFA would 364 impact the normal traffic performance by potentially increasing the 365 latency. 367 | 100 | 368 -P2---------P1- 369 \ / 370 1000 \ / 1000 371 PE1---PE2 372 5 374 Figure 3: Example SP topology 376 Clearly, full protection can be provided, using the techniques 377 described in this draft, by PE1 choosing P2 as a PQ node, and PE2 378 choosing P1 as a PQ node. 380 6. Node Failures 382 When the failure is a node failure rather than a link failure there 383 is a danger that the RLFA repair will loop. This is discussed in 384 detail in [I-D.bryant-ipfrr-tunnels]. In summary problem is that two 385 of more of E's neighbors each with E as the next hop to some 386 destination D may attempt to repair a packet addressed to destination 387 D via the other neighbor and then E, thus causing a loop to form. As 388 will be noted from [I-D.bryant-ipfrr-tunnels], this can rapidly 389 become a complex problem to address. 391 There are a number of ways to minimize the probability of a loop 392 forming when a node failure occurs and there exists the possibility 393 that two of E's neighbors may form a mutual repair. 395 1. Detect when a packet has arrived on some interface I that is also 396 the interface used to reach the first hop on the RLFA path to PQ, 397 and drop the packet. This is useful in the case of a ring 398 topology. 400 2. Require that the path from PQ to destination D never passes 401 through E (including in the ECMP case), i.e. only use node 402 protecting paths in which the cost PQ to D is strictly less than 403 the cost PQ to E plus the cost E to D. 405 3. Require that where the packet may pass through another neighbor 406 of E, that node is down stream (i.e. strictly closer to D than 407 the repairing node). This means that some neighbor of E (X) can 408 repair via some other neighbor of E (Y), but Y cannot repair via 409 X. 411 Case 1 accepts that loops may form and suppresses them by dropping 412 packets. Dropping packets may be considered less detrimental than 413 looping packets. Cases 2 and 3 above prevent the formation of a 414 loop, but at the expense of a reduced repair coverage and at the cost 415 of additional complexity in the algorithm to compute the repair path. 417 The probability of a node failure and the consequences of node 418 failure in any particular topology will depend on the node design, 419 the particular topology in use, and node failure strategy (including 420 the null strategy). It is recommended that a network operator 421 perform an analysis of the consequences and probability of node 422 failure in their network, and determine whether the incidence and 423 consequence of occurrence are acceptable. 425 7. Operation in an LDP environment 427 Where this technique is used in an MPLS network using LDP [RFC5036], 428 S will need to push two labels onto the repair packet. First it 429 needs to push PQ's label to the destination, and then it needs to 430 push its own label for PQ. In the example Section 3.1 S already has 431 the first hop (B) label for the PQ node (C) as a result of the 432 ordinary operation of LDP. To get the PQ node (C) label for the 433 destination (D), S needs to establish a targeted LDP session with C. 435 The label stack for normal operation and RLFA operation is shown 436 below in Figure 4. 438 +-----------------+ +-----------------+ +-----------------+ 439 | datalink | | datalink | | datalink | 440 +-----------------+ +-----------------+ +-----------------+ 441 | S's label for D | | E's label for D | | C's label for D | 442 +-----------------+ +-----------------+ +-----------------+ 443 | Payload | | Payload | | B's label for C | 444 +-----------------+ +-----------------+ +-----------------+ 445 X Y | Payload | 446 +-----------------+ 447 Z 449 X = Normal label stack packet arriving at S 450 Y = Normal label stack packet leaving S 451 Z = RLFA label stack to D via C as PQ node 453 Figure 4 455 To establish an targeted LDP session with a candidate PQ node the 456 repairing node (S) needs to know what IP address PQ is willing to use 457 for targeted LDP sessions. This in turn requires PQ to advertise 458 this address in the IGP in use. What address is used, how this is 459 advertised in the IGP, and whether this is a special IP address or an 460 IP address also used for some other purpose is out of scope for this 461 document and must be specified in an IGP specific RFC. 463 8. Historical Note 465 The basic concepts behind Remote LFA were invented in 2002 and were 466 later included in [I-D.bryant-ipfrr-tunnels], submitted in 2004. 468 [I-D.bryant-ipfrr-tunnels], targeted a 100% protection coverage and 469 hence included additional mechanisms on top of the Remote LFA 470 concept. The addition of these mechanisms made the proposal very 471 complex and computationally intensive and it was therefore not 472 pursued as a working group item. 474 As explained in [I-D.filsfils-rtgwg-lfa-applicability], the purpose 475 of the LFA FRR technology is not to provide coverage at any cost. A 476 solution for this already exists with MPLS TE FRR. MPLS TE FRR is a 477 mature technology which is able to provide protection in any topology 478 thanks to the explicit routing capability of MPLS TE. 480 The purpose of LFA FRR technology is to provide for a simple FRR 481 solution when such a solution is possible. The first step along this 482 simplicity approach was "local" LFA [RFC5286]. We propose "Remote 483 LFA" as a natural second step. The following section motivates its 484 benefits in terms of simplicity, incremental deployment and 485 significant coverage increase. 487 9. Benefits 489 Remote LFAs preserve the benefits of RFC5286: simplicity, incremental 490 deployment and good protection coverage. 492 9.1. Simplicity 494 The remote LFA algorithm is simple to compute. 496 o The extended P space does not require any new computation (it is 497 known once per-prefix LFA computation is completed). 499 o The Q-space is a single reverse SPF rooted at the neighbor. 501 o The directed LDP session is automatically computed and 502 established. 504 In edge topologies (square, ring), the directed LDP session position 505 and number is deterministic and hence troubleshooting is simple. 507 In core topologies, our simulation indicates that the 90th percentile 508 number of LDP sessions per node to achieve the significant Remote LFA 509 coverage observed in section 7.3 is <= 6. This is insignificant 510 compared to the number of LDP sessions commonly deployed per router 511 which is frequently is in the several hundreds. 513 9.2. Incremental Deployment 515 The establishment of the directed LDP session to the PQ node does not 516 require any new technology on the PQ node. Indeed, routers commonly 517 support the ability to accept a remote request to open a directed LDP 518 session. The new capability is restricted to the Remote-LFA 519 computing node (the originator of the LDP session). 521 9.3. Significant Coverage Extension 523 The previous sections have already explained how Remote LFAs provide 524 protection for frequently occurring edge topologies: square and 525 rings. In the core, we extend the analysis framework in section 4.3 526 of [I-D.filsfils-rtgwg-lfa-applicability]and provide hereafter the 527 Remote LFA coverage results for the 11 topologies: 529 +----------+--------------+----------------+------------+ 530 | Topology | Per-link LFA | Per-prefix LFA | Remote LFA | 531 +----------+--------------+----------------+------------+ 532 | T1 | 45% | 77% | 78% | 533 | T2 | 49% | 99% | 100% | 534 | T3 | 88% | 99% | 99% | 535 | T4 | 68% | 84% | 92% | 536 | T5 | 75% | 94% | 99% | 537 | T6 | 87% | 99% | 100% | 538 | T7 | 16% | 67% | 96% | 539 | T8 | 87% | 100% | 100% | 540 | T9 | 67% | 80% | 98% | 541 | T10 | 98% | 100% | 100% | 542 | T11 | 59% | 77% | 95% | 543 | Average | 67% | 89% | 96% | 544 | Median | 68% | 94% | 99% | 545 +----------+--------------+----------------+------------+ 547 Another study[ISOCORE2010] confirms the significant coverage increase 548 provided by Remote LFAs. 550 10. Complete Protection 552 As shown in the previous table, Remote LFA provides for 96% average 553 (99% median) protection in the 11 analyzed SP topologies. 555 In an MPLS network, this is achieved without any scalability impact 556 as the tunnels to the PQ nodes are always present as a property of an 557 LDP-based deployment. 559 In the very few cases where P and Q spaces have an empty 560 intersection, one could select the closest node in the Q space and 561 signal an explicitely-routed RSVP TE LSP to that Q node. A directed 562 LDP session is then established with the selected Q node and the rest 563 of the solution is identical to that described elsewhere in this 564 document. 566 The drawbacks of this solution are: 568 1. only available for MPLS network; 570 2. the addition of LSPs in the SP infrastructure. 572 This extension is described for exhaustivity. In practice, the 573 "Remote LFA" solution should be preferred for three reasons: its 574 simplicity, its excellent coverage in the analyzed backbones and its 575 complete coverage in the most frequent access/aggregation topologies 576 (box or ring). 578 11. IANA Considerations 580 There are no IANA considerations that arise from this architectural 581 description of IPFRR. The RFC Editor may remove this section on 582 publication. 584 12. Security Considerations 586 The security considerations of RFC 5286 also apply. 588 To prevent their use as an attack vector the repair tunnel endpoints 589 SHOULD be assigned from a set of addresses that are not reachable 590 from outside the routing domain. 592 13. Acknowledgments 594 The authors acknowledge the technical contributions made to this work 595 by Stefano Previdi. 597 14. Informative References 599 [I-D.bryant-ipfrr-tunnels] 600 Bryant, S., Filsfils, C., Previdi, S., and M. Shand, "IP 601 Fast Reroute using tunnels", draft-bryant-ipfrr-tunnels-03 602 (work in progress), November 2007. 604 [I-D.filsfils-rtgwg-lfa-applicability] 605 Filsfils, C., Francois, P., Shand, M., Decraene, B., 606 Uttaro, J., Leymann, N., and M. Horneffer, "LFA 607 applicability in SP networks", draft-filsfils-rtgwg-lfa- 608 applicability-00 (work in progress), March 2010. 610 [ISOCORE2010] 611 So, N., Lin, T., and C. Chen, "LFA (Loop Free Alternates) 612 Case Studies in Verizon's LDP Network", 2010. 614 [RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic 615 Routing Encapsulation (GRE)", RFC 1701, October 1994. 617 [RFC1853] Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995. 619 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 620 Requirement Levels", BCP 14, RFC 2119, March 1997. 622 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 623 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 624 Encoding", RFC 3032, January 2001. 626 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 627 Specification", RFC 5036, October 2007. 629 [RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast 630 Reroute: Loop-Free Alternates", RFC 5286, September 2008. 632 [RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", RFC 633 5714, January 2010. 635 Authors' Addresses 637 Stewart Bryant 638 Cisco Systems 639 250, Longwater, Green Park, 640 Reading RG2 6GB, UK 641 UK 643 Email: stbryant@cisco.com 645 Clarence Filsfils 646 Cisco Systems 647 De Kleetlaan 6a 648 1831 Diegem 649 Belgium 651 Email: cfilsfil@cisco.com 653 Stefano Previdi 654 Cisco Systems 656 Email: sprevidi@cisco.com 658 Mike Shand 659 Independent Contributor 661 Email: imc.shand@gmail.com 662 Ning So 663 Tata Communications 664 Mobile Broadband Services 666 Email: Ning.So@tatacommunications.com