idnits 2.17.00 (12 Aug 2021) /tmp/idnits41845/draft-bryant-ipfrr-tunnels-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1272. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1283. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1290. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1296. 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 Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 16, 2007) is 5293 days in the past. Is this intentional? Checking references for intended status: Historic ---------------------------------------------------------------------------- == Missing Reference: 'L' is mentioned on line 795, but not defined == Missing Reference: 'D' is mentioned on line 795, but not defined == Missing Reference: 'S' is mentioned on line 905, but not defined == Missing Reference: 'E' is mentioned on line 909, but not defined == Missing Reference: 'X' is mentioned on line 909, but not defined == Missing Reference: 'Y' is mentioned on line 909, but not defined == Missing Reference: 'Z' is mentioned on line 909, but not defined == Unused Reference: 'I-D.ietf-rtgwg-ipfrr-notvia-addresses' is defined on line 1181, but no explicit reference was found in the text == Outdated reference: draft-ietf-bfd-base has been published as RFC 5880 == Outdated reference: draft-ietf-rtgwg-ipfrr-framework has been published as RFC 5714 == Outdated reference: draft-ietf-rtgwg-ipfrr-notvia-addresses has been published as RFC 6981 == Outdated reference: draft-ietf-rtgwg-ipfrr-spec-base has been published as RFC 5286 == Outdated reference: draft-ietf-rtgwg-lf-conv-frmwk has been published as RFC 5715 Summary: 1 error (**), 0 flaws (~~), 15 warnings (==), 7 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: Historic S. Previdi 5 Expires: May 19, 2008 M. Shand 6 Cisco Systems 7 November 16, 2007 9 IP Fast Reroute using tunnels 10 draft-bryant-ipfrr-tunnels-03 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on May 19, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 This draft describes an IP fast re-route mechanism that provides 44 backup connectivity in the event of a link or router failure. In the 45 absence of single points of failure and asymmetric costs, the 46 mechanism provides complete protection against any single failure. 47 If perfect repair is not possible, the identity of all the 48 unprotected links and routers is known in advance. 50 This IP Fast Reroute advanced method was invented in 2002 and draft 51 (draft-bryant-ipfrr-tunnels-00.txt) describing it was submitted to 52 the IETF in May 2004. It was one of the first methods of achieving 53 full repair coverage in an IP Network, and as such the draft has been 54 widely referenced in the academic literature. 56 The authors DO NOT propose that this IPFRR method be implemented 57 since better IPFRR advanced method capable of achieving full repair 58 coverage have subsequently been invented. 60 Requirements Language 62 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 63 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 64 document are to be interpreted as described in RFC2119 [RFC2119]. 66 Table of Contents 68 1. History . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 4. Goals, non-goals, limitations and constraints . . . . . . . . 6 72 4.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 6 73 4.2. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 6 74 4.3. Limitations . . . . . . . . . . . . . . . . . . . . . . . 7 75 4.4. Constraints . . . . . . . . . . . . . . . . . . . . . . . 7 76 5. Repair Paths . . . . . . . . . . . . . . . . . . . . . . . . . 7 77 5.1. Tunnels as Repair Paths . . . . . . . . . . . . . . . . . 8 78 5.2. Tunnel Requirements . . . . . . . . . . . . . . . . . . . 10 79 5.2.1. Setup . . . . . . . . . . . . . . . . . . . . . . . . 10 80 5.2.2. Multipoint . . . . . . . . . . . . . . . . . . . . . . 11 81 5.2.3. Directed forwarding . . . . . . . . . . . . . . . . . 11 82 5.2.4. Security . . . . . . . . . . . . . . . . . . . . . . . 11 83 6. Construction of Repair Paths . . . . . . . . . . . . . . . . . 11 84 6.1. Identifying Repair Path Targets . . . . . . . . . . . . . 11 85 6.2. Determining Tunneled Repair Paths . . . . . . . . . . . . 12 86 6.2.1. Computing Repair Paths . . . . . . . . . . . . . . . . 13 87 6.2.2. Extended P-space . . . . . . . . . . . . . . . . . . . 14 88 6.2.3. Loop-free Alternates . . . . . . . . . . . . . . . . . 14 89 6.2.4. Selecting Repair Paths . . . . . . . . . . . . . . . . 14 90 6.3. Assigning Traffic to Repair Paths . . . . . . . . . . . . 14 91 6.4. When no Repair Path is Possible . . . . . . . . . . . . . 15 92 6.4.1. Unreachable Target . . . . . . . . . . . . . . . . . . 16 93 6.4.2. Asymmetric Link Costs . . . . . . . . . . . . . . . . 16 94 6.4.3. Interference Between Potential Node Repair Paths . . . 16 95 6.5. Multi-homed Prefixes . . . . . . . . . . . . . . . . . . . 19 96 6.6. LANs and pseudo-nodes . . . . . . . . . . . . . . . . . . 20 97 6.6.1. The Link between Routers S and E is a LAN . . . . . . 20 98 6.6.2. A LAN exists at the release point . . . . . . . . . . 22 99 6.6.3. A LAN between E and its neighbors . . . . . . . . . . 22 100 6.6.4. The LAN is a Transit Subnet . . . . . . . . . . . . . 23 101 7. Failure Detection and Repair Path Activation . . . . . . . . . 23 102 7.1. Failure Detection . . . . . . . . . . . . . . . . . . . . 23 103 7.2. Repair Path Activation . . . . . . . . . . . . . . . . . . 23 104 7.3. Node Failure Detection Mechanism . . . . . . . . . . . . . 23 105 8. Loop Free Transition . . . . . . . . . . . . . . . . . . . . . 24 106 9. IPFRR Capability . . . . . . . . . . . . . . . . . . . . . . . 24 107 10. Enhancements to routing protocols . . . . . . . . . . . . . . 25 108 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 109 12. Security Considerations . . . . . . . . . . . . . . . . . . . 25 110 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 111 14. Security Considerations . . . . . . . . . . . . . . . . . . . 26 112 15. Informative References . . . . . . . . . . . . . . . . . . . . 26 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 114 Intellectual Property and Copyright Statements . . . . . . . . . . 29 116 1. History 118 This IP Fast Reroute advanced method was invented in 2002 and draft 119 (draft-bryant-ipfrr-tunnels-00.txt) describing it was submitted to 120 the IETF in May 2004. It was one of the first methods of achieving 121 full repair coverage in an IP Network, and as such the draft has been 122 widely referenced in the academic literature. Since IETF drafts are 123 ephemeral, the authors have requested the IETF Editor to publish this 124 as a historic RFC so that it is available for reference. 126 The authors DO NOT propose that this IPFRR method be implemented. 127 Better IPFRR advanced method capable of achieving full repair 128 coverage have since been invented, and are the subject of work in 129 progress in the IETF. 131 One final note, in some versions of the draft the abstract term P was 132 renamed F, and the abstract term Q was renamed G. For reasons of 133 personal preference this version of the document reverts to the terms 134 P and Q. 136 2. Terminology 138 This draft uses the terms defined in 139 [I-D.ietf-rtgwg-ipfrr-framework]. This section defines additional 140 words, acronyms, and actions used in this draft. 142 Directed Forwarding 144 The ability of the repairing router (S) to specify the 145 next hop (Q) on exit from a tunnel end-point (P). 147 Extended P-space 149 The union of the P-space of the neighbours of a 150 specific router with respect to a common component. 152 Extended P-space does not include the additional space 153 reachable though directed forwarding. 155 P The router in P-space to which a packet is tunnelled 156 for repair. 158 PQ A router that is in both P and Q-space and hence does 159 not need directed forwarding. 161 P-space P-space is the set of routers reachable from a 162 specific router without any path (including equal cost 163 path splits) transiting a specified component. 165 For example, the P-space of S, is the set of routers 166 that S can reach without using E (router failure case) 167 or the S-E link failure case). 169 Q The router in Q-space, to which the packet is directed 170 by router P on exit from the repair tunnel. Q will 171 always be adjacent to P, or P itself. 173 Q-space Q-space is the set of routers from which a specific 174 router can be reached without any path (including 175 equal cost path splits) transiting a specified 176 component. 178 Interference The condition where the network costs are such that a 179 repairing router cannot tunnel a packet sufficiently 180 far from a failed node such that it is not attracted 181 back to the failed node via another of that node's 182 neighbours. 184 3. Introduction 186 When a link or node failure occurs in a routed network, there is 187 inevitably a period of disruption to the delivery of traffic until 188 the network re-converges on the new topology. Packets for 189 destinations which were previously reached by traversing the failed 190 component may be dropped or may suffer looping. Traditionally such 191 disruptions have lasted for periods of at least several seconds, and 192 most applications have been constructed to tolerate such a quality of 193 service. 195 Recent advances in routers have reduced this interval to under a 196 second for carefully configured networks using link state IGPs. 197 However, new Internet services are emerging which may be sensitive to 198 periods of traffic loss which are orders of magnitude shorter than 199 this. 201 Addressing these issues is difficult because the distributed nature 202 of the network imposes an intrinsic limit on the minimum convergence 203 time which can be achieved. 205 However, there is an alternative approach, which is to compute backup 206 routes that allow the failure to be repaired locally by the router(s) 207 detecting the failure without the immediate need to inform other 208 routers of the failure. In this case, the disruption time can be 209 limited to the small time taken to detect the adjacent failure and 210 invoke the backup routes. This is analogous to the technique 211 employed by MPLS Fast Reroute [RFC4090], but the mechanisms employed 212 for the backup routes in pure IP networks are necessarily very 213 different. 215 A framework for IP Fast Reroute [I-D.ietf-rtgwg-ipfrr-framework] 216 provides a summary of the proposed IPFRR solutions, and a partial 217 solution using equal cost multi-path and loop-free alternate case is 218 described in [I-D.ietf-rtgwg-ipfrr-spec-base]. 220 This draft describes extensions to the basic repair mechanism in 221 which we propose the use of tunnels to provide additional logical 222 downstream paths. These mechanisms provide almost 100% repair 223 connectivity in practical networks. 225 4. Goals, non-goals, limitations and constraints 227 4.1. Goals 229 The following are the goals of IPFRR: 231 o Protect against any link or router failure in the network. 233 o No constraints on the network topology or link costs. 235 o Never worse than the existing routing convergence mechanism. 237 o Co-existence with non-IP fast-reroute capable routers in the 238 network. 240 4.2. Non-Goals 242 The following are non-goals of IPFRR: 244 o Protection of a single point of failure. 246 o To provide protection in the presence of multiple concurrent 247 failures other than those that occur due to the failure of a 248 single router. 250 o Shared risk group protection. 252 o Complete fault coverage in networks that make use of asymmetric 253 costs. 255 4.3. Limitations 257 The following limitations apply to IPFRR: 259 o Because the mechanisms described here rely on complete topological 260 information from the link state routing protocol, they will only 261 work within a single link state flooding domain. 263 o Reverse Path Forwarding (RPF) checks cannot be used in conjunction 264 with IPFRR. This is because the use of tunnels may result in 265 packets arriving over different interfaces than expected. 267 4.4. Constraints 269 The following constraints are assumed: 271 o Following a failure, only the routers adjacent to the failure have 272 any knowledge of the failure. 274 o There is insufficient time following a failure to compute a repair 275 strategy based on knowledge of the specific failure that has 276 occurred. 278 o Multiple concurrent failures may not be protected. 280 5. Repair Paths 282 When a router detects an adjacent failure, it uses a set of repair 283 paths in place of the failed component, and continues to use this 284 until the completion of the routing transition. Only routers 285 adjacent to the failed component are aware of the nature of the 286 failure. Once the routing transition has been completed, the router 287 will have no further use for the repair paths since all routers in 288 the network will have revised their forwarding data and the failed 289 link will have been eliminated from this computation. 291 Repair paths are pre-computed in anticipation of later failures so 292 they can be promptly activated when a failure is detected. 294 Three types of repair path are used to achieve the repair: 296 1. Equal cost path-split. 298 2. Loop-free Alternate. 300 3. Tunnel. 302 The operation of equal cost path-split and loop-free alternate is 303 described in [I-D.ietf-rtgwg-ipfrr-spec-base]. A tunnelled repair 304 path tunnels traffic to some staging point from which it will travel 305 to its destination using normal forwarding without looping back. The 306 repair path can be thought of as providing a virtual link, 307 originating at a router adjacent to a failure, and diverting traffic 308 around the failure. This is equivalent to providing a virtual loop- 309 free alternate to supplement the physical loop-free alternates. 311 5.1. Tunnels as Repair Paths 313 The repair strategies described in this draft operate on the basis 314 that if a packet can somehow be sent to the other side of the 315 failure, it will subsequently proceed towards its destination exactly 316 as if it had traversed the failed component. See Figure 1. 318 Repair Path from S to 319 +-----------+ 320 | | 321 | v 322 ---->[S]---//----[E]-----> 324 Figure 1: Simple Link Repair. 326 Creating a repair path from S to E may require a packet to traverse 327 an unnatural route. If a suitable natural path starts at a neighbour 328 (i.e. it is a loop-free alternate), then S can force the packet 329 directly there. If this is not the case, then S may create one by 330 using a tunnel to carry the packet to a point in the network where 331 there is a real loop-free alternate. Note that the tunnel does not 332 have to go from S to E. The tunnel can terminate at any router in the 333 network, provided that S can be sure that the packet will proceed 334 correctly to its destination from that router. 336 A repair path computed for a link failure may not however work 337 satisfactorily when the neighbouring router has, itself, failed. 338 This is illustrated in Figure 2 339 Repair path from S to E 340 +-------------------------+ 341 | | 342 | <------------+ 343 --->[S]---//----[E]----//-----[S1]--> 344 +----------> | 345 | | 346 +-------------------------+ 347 Repair Path from S1 to E 349 Figure 2: Looping Link Repair when Router Fails 351 Consider the case of a router E with just two neighbours S and S1. 352 When router E fails, both S and S1 will observe the failure of their 353 local link to E, but will have no immediate knowledge that E itself 354 has failed. If they were both to attempt to repair traffic around 355 their local link, they would invoke mutual repairs which would loop. 357 Since it is not easy for a router to immediately distinguish between 358 a link failure and the failure of its neighbour, repair paths are 359 calculated in anticipation of adjacent router failure. Thus, for 360 each of its protected links, router S (Figure 3) pre-computes a set 361 of tunnelled repair paths, one for each of the neighbours (S1, S2 and 362 S3) of its neighbour E on the S-E link. The set of destinations that 363 are normally assigned to link S-E will be assigned to a repair path 364 based on the neighbour of E through which router E would have 365 forwarded traffic to them. 367 Repair S-S1 368 +----------->[S1] 369 | | 370 | | 371 | | 372 ----->[S]----//-----[E]---------[S2] 373 || | ^ 374 || | | 375 ||Repair S-S3 | | 376 |+---------->[S3] | 377 | | 378 +-------------------------+ 379 Repair S-S2 381 Figure 3: Repair paths in anticipation of a router failure. 383 The set of repair paths in Figure 3 will function correctly in the 384 case of link and router failure. However, in some network topologies 385 they may not provide a means for traffic to reach router E itself. 386 This is important in cases where E is a single point of failure and E 387 is still functional (i.e. the failure was actually a failure of the 388 S-E link). Hence, in addition to computing repair paths for the 389 neighbours of its neighbour on a protected link, a router also 390 calculates a repair path for the neighbour itself. This is 391 illustrated in Figure 4. 393 Repair S-E 394 +----------------+ 395 | | 396 | Repair S-S1 | 397 |+---------->[S1]| 398 || | / 399 || | / 400 || |/ 401 ----->[S]----//-----[E]---------[S2] 402 || | ^ 403 || | | 404 ||Repair S-S3 | | 405 |+---------->[S3] | 406 | | 407 +-------------------------+ 408 Repair S-S2 410 Figure 4: The full set of S-E repair paths. 412 In the event of a failure, the only traffic that is assigned to the 413 link repair path (the S-E repair) is that traffic which has no other 414 path to its destination except via E. As we have already seen, there 415 is a danger that traffic assigned to this link repair path may loop 416 if E has failed, therefore, when the repair paths are invoked, a loop 417 detection mechanism is used which promptly detects the loop and, upon 418 detection, withdraws the link (S-E) repair path from service. 420 5.2. Tunnel Requirements 422 There are a number of IP in IP tunnel mechanisms that may be used to 423 fulfil the requirements of this design. Suitable candidates include 424 IP-in-IP [RFC1853], GRE[RFC1701]] and L2TPv3 [RFC3931]. The 425 selection of the specific tunnelling mechanism (and any necessary 426 enhancements) used to provide a repair path is outside the scope of 427 this document. However the following sections describe the 428 requirements for the tunnelling mechanism. 430 5.2.1. Setup 432 When a failure is detected, it is necessary to immediately redirect 433 traffic to the repair paths. Consequently, the tunnels used must be 434 provisioned beforehand in anticipation of the failure. IP fast re- 435 route will determine which tunnels it requires. It must therefore be 436 possible to establish tunnels automatically, without management 437 action, and without the need to manually establish context at the 438 tunnel endpoint. 440 5.2.2. Multipoint 442 To reduce the number of tunnel endpoints in the network the tunnels 443 should be multi-point tunnels capable of receiving repair traffic 444 from any IPFRR router in the network. 446 5.2.3. Directed forwarding 448 Directed forwarding must be supported such that the router at the 449 tunnel endpoint (P can be directed by the router at the tunnel source 450 (S) to forward the packet directly to a specific neighbour. 451 Specification of the directed forwarding mechanism is outside the 452 scope of this document. Directed forwarding might be provided using 453 an enhancement to the IP tunnelling encapsulation, or it might be 454 provided through the use of a single MPLS label stack entry [RFC3032] 455 interposed between the IP tunnel header and the packet being 456 repaired. 458 5.2.4. Security 460 A lightweight security mechanism should be supported to prevent the 461 abuse of the repair tunnels by an attacker. This is discussed in 462 more detail in Section 12. 464 6. Construction of Repair Paths 466 6.1. Identifying Repair Path Targets 468 To establish protection for a link or node it is necessary to 469 determine which neighbours of the neighbouring node should be targets 470 of repair paths. Normally all neighbours will be used as repair path 471 targets. However, in some topologies, not all neighbours will be 472 needed as targets because, prior to the failure, no traffic was being 473 forwarded through them by the repairing router. This can be 474 determined by examining the normal shortest path tree (SPT) computed 475 by the repairing router. 477 In addition, the neighbouring router E will also be the target of a 478 repair path for any destinations for which E is a single point of 479 failure. 481 6.2. Determining Tunneled Repair Paths 483 The objective of each tunnelled repair path is to deliver traffic to 484 a target router when a link is observed to have failed. However, it 485 is seldom possible to use the target router itself as the tunnel 486 endpoint because other routers on the repair path, that have not 487 learned of the failure, will forward traffic addressed to it using 488 their least cost path which may be via the failed link. This is 489 illustrated in Figure 5 in which all link costs are one in both 490 directions. Router S's intended repair path for traffic to D when 491 link S-E fails is the path W-X-Y-Z-S1. However, if router S makes S1 492 be the tunnel endpoint and forwards the packet to router W, router W 493 will immediately return it to S because its least cost path to S1 is 494 S-E-S1 (cost 3 versus cost 4) and has no knowledge of the failure of 495 link S-E. 497 [S]--//--[E]-----[S1] 498 | | 499 | | 500 [W]---[X]---[Y]---[Z] 502 Figure 5: Repair path to target router S1. 504 Thus the tunnel endpoint needs to be somewhere on the repair path 505 such that packets addressed to the tunnel end point will not loop 506 back towards router S. In addition, the release point needs to be 507 somewhere such that when packets are released from the tunnel they 508 will flow towards the target router (or their actual destination) 509 without being attracted back to the failed link. By inspection, in 510 Figure 5, suitable tunnel endpoints are routers X, Y, and Z. 512 Note that it is not essential that traffic assigned to a repair path 513 actually traverse the target router for which the repair path was 514 created. If, for example, in Figure 5, if a packet's destination 515 were normally reached via the path S-E-S1-Z-?-?-?, once it was 516 released at any of the possible tunnel endpoints, it would arrive at 517 its destination by the best available route without traversing S1. 519 In general, the properties that are required of tunnel endpoints are: 521 o The end point must be reachable from the tunnel source without 522 traversing the failed link; and 524 o When released, tunnelled packets will proceed towards their 525 destination without being attracted back over the failed link or 526 node. 528 Provided both of these conditions are met, packets forwarded on the 529 repair path will not loop. 531 In some topologies it will not be possible to find a tunnel endpoint 532 that exhibits both the required properties. For example, in 533 Figure 5, if the cost of link X-Y were increased from one to four in 534 both directions, there is no longer a viable endpoint within the 535 fragment of the topology shown. 537 To solve this problem we introduce the concept of directed forwarding 538 from the tunnel endpoint. Directed forwarding allows the originator 539 of a tunnelled packet to instruct that, when it is decapsulated at 540 the end of the tunnel, it be forwarded via a specific adjacency, and 541 not be subjected to the normal forwarding decision process. This 542 effectively allows the tunnel to be extended by one hop. So, for 543 example, in Figure 5 with the cost of link X-Y set to four, it would 544 be possible to select X as the tunnel endpoint with the directive 545 that X always forward the packets it decapsulates via the adjacency 546 to Y. Thus, router X is reached from S using normal forwarding, and 547 directed forwarding is then used to force packets to router Y, from 548 where S1 can be reached using normal forwarding. 550 Provided link costs are symmetrical, it can be proved that it is 551 always possible to compute a tunnelled repair path (possibly using 552 directed forwarding) around a link failure, and that the tunnel 553 endpoint (P) and the release point (Q) will be coincident, or may be 554 separated by at most one hop. 556 6.2.1. Computing Repair Paths 558 For a router S, determining tunnelled repair paths around a 559 neighbouring router E, the set of potential tunnel end points 560 includes all the routers that can be reached from S using normal 561 forwarding without traversing the failed link S-E. This is termed 562 the "P-space" of S with respect to the failure of E. Any router that 563 is on an equal cost path split via the failed link is excluded from 564 this set. 566 The resulting set defines all the possible tunnel end points that 567 could be used in repair paths originating at router S for the failure 568 of link S-E. This set can be obtained by computing an SPT rooted at 569 S and excising the sub-tree reached via the S-E link. The set of 570 possible release points can be determined by computing the set of 571 routers that can reach the repair path target without traversing the 572 failed link. This is termed the "Q-space" of the target with respect 573 to the failure. The Q-space can be obtained by computing a reverse 574 shortest path tree (rSPT) rooted at the repair path target, with the 575 sub-tree which traverses the failed link (or node) excised. The rSPT 576 uses the cost towards the root rather than from it and yields the 577 best paths towards the root from other nodes in the network. 579 The intersection of the target's Q-space with S's P-space includes 580 all the possible release points for any repair path not employing 581 directed forwarding. Where there is no intersection, but there exist 582 a pair of routers, P in S's P-space and Q in the target's Q-space, 583 router P can be used as the tunnel endpoint with directed forwarding 584 to the release point Q. 586 6.2.2. Extended P-space 588 The description in Section 6.2.1 calculated router S's P-space rooted 589 at S itself. However, since router S will only use a repair path 590 when it has detected the failure of the link S-E, the initial hop of 591 the repair path need not be subject to S's normal forwarding decision 592 process. Thus we introduce the concept of extended P- space. Router 593 S's extended P-space is the union of the P-spaces of each of S's 594 neighbours. The use of extended P-space may allow router S to repair 595 to targets that were otherwise unreachable. 597 6.2.3. Loop-free Alternates 599 When a loop-free alternate exists, no tunnelling is required. 601 6.2.4. Selecting Repair Paths 603 The mechanisms described above will identify all the possible release 604 points that can be used to reach each particular target. (The 605 circumstances when no release points exist are described in 606 Section 6.4.) In a well-connected network there are likely to be 607 multiple possible release points for each target, and all will work 608 correctly. For simplicity, one release point per target is chosen. 609 All will deliver the packets correctly so, arguably, it does not 610 matter which is chosen. However, one release point may be preferred 611 over the others on the basis of path cost or some other criteria. 613 It is an implementation matter as to how the release point is 614 selected. 616 6.3. Assigning Traffic to Repair Paths 618 Once the repair path for each target has been selected, it is 619 necessary to determine which of the destinations normally reached via 620 the protected link should be assigned to which of the repair paths 621 when the link fails. 623 This is achieved by recording which neighbour of E would be used to 624 reach each destination reachable over S-E when running the original 625 SPF. Traffic assignment is then simply a matter of assigning the 626 traffic which E would have forwarded via each neighbour to the repair 627 path which has that neighbour as its target. 629 Although the repair paths are calculated based on traffic addressed 630 to specific targets, it can be proved that the traffic assignment 631 algorithm guarantees that the repair path can be used for any traffic 632 assigned to it. 634 Where E would normally split the traffic to a particular destination 635 via two or more of its neighbours, it is an implementation decision 636 whether the repaired traffic should be split across the corresponding 637 set of repair paths. The repair path to E itself is normally used 638 just for traffic destined for E and any prefixes advertised by E. 639 However, under some circumstances, it may be impossible to compute a 640 repair path to one or more of E's neighbours, for example, because E 641 is a single point of failure. In this case traffic for the 642 destinations served by the otherwise irreparable targets is assigned 643 to the repair path with E as its target, in the optimistic assumption 644 that router E is still functioning. If router E is indeed still 645 functioning, this will ensure delivery of the traffic. If, however, 646 router E has failed, the traffic on this repair path will loop as 647 previously shown in Section 5.1. The way this is detected, and the 648 course of action when it is detected, is described in Section 7.3. 650 6.4. When no Repair Path is Possible 652 Under some circumstances, it will not be possible to identify a 653 repair path to one or more of the targets. This can occur for the 654 following reasons: 656 1. The neighbouring router that is presumed to have failed 657 constitutes a single point of failure in the network. 659 2. Severely asymmetric link costs may cause an otherwise viable 660 physical repair path to be unusable. 662 3. Interference may occur between the repair paths of individual 663 targets 665 In practise, these cases are unlikely to be encountered frequently. 666 Networks that will benefit from the mechanisms described here will 667 usually exhibit considerable redundancy and are normally operated 668 with largely symmetric link costs. Note that a router's inability to 669 compute a full set of repair paths for one of its links does not 670 necessarily affect its ability to do so for its other links. 672 Example topologies illustrating each of the three cases above are 673 described in the following subsections. 675 6.4.1. Unreachable Target 677 If the failure of a neighbouring router makes one or more of its 678 neighbours genuinely unreachable, clearly it will not be possible to 679 establish a repair path to such targets. Such single points of 680 failure are not expected to be encountered frequently in properly 681 designed networks, and will probably occur only when the network has 682 previously suffered other failures that have reduced its 683 connectivity. 685 6.4.2. Asymmetric Link Costs 687 When link costs have been set asymmetrically, it is possible that a 688 repair path cannot be constructed even using directed forwarding. 690 Although it is trivial to construct a network fragment with this 691 property, this should not be regarded as a major problem. Firstly, 692 asymmetric link costs are seldom used deliberately. And, secondly, 693 even when an asymmetric link cost prevents one potential repair path 694 being used, there will normally be other ones available. 696 6.4.3. Interference Between Potential Node Repair Paths 698 Under some circumstances the existence of one neighbour may interfere 699 with a potential repair path to another. Consider the topology shown 700 in Figure 6, in which all links have a symmetrical cost of one, with 701 the exception of that between H and I, which has a cost of 3. In 702 this example, the fact that router J is a neighbour of E prevents the 703 discovery of a repair path from router S to router S1 despite the 704 existence of an apparently suitable path. 706 [S]---//---[E]-------[S1] 707 | | | 708 | | | 709 [H]-3-[I]--[J]--[K]--[L] 711 Figure 6: Interference between repair paths 713 A repair path from router S to J can use J itself as the release 714 point by employing directed forwarding from I. However, it is not 715 possible to identify a suitable release point for a repair path to 716 router S1 within the topology shown since there is nowhere that 717 router S can reach that will subsequently forward traffic to router 718 S1 except via the forbidden link E-S1 (J's least cost path to S1 is 719 J-E-S1). This is because the extended P-space of router S is 720 separated by more than one hop from the Q-space of router S1. 722 Since the topology shown in Figure 6 will typically form part of a 723 much larger topology, a different, and possibly more circuitous 724 repair path from S to S1, that does not go via J, may be discovered. 725 This is illustrated in Figure 7. In this enhanced topology, a repair 726 path to S1 using Y as the release point can be used. 728 [S]---//---[B]-------[S1] 729 | | | 730 | | | 731 [H]-3-[I]--[J]--[K]--[L] 732 | | 733 | | 734 [X]--[Y]--[Z] 736 Figure 7: Resolving interference in a larger network 738 Note that, in Figure 6, if the traffic for S1 were assigned to the 739 repair path for J, it would correctly reach S1 because J would assign 740 it to its repair path to S1. That is, packets from S to S1 would 741 travel via two successive tunnels. Consequently, this is referred to 742 as a "secondary repair path". However, it is not always the case 743 that interference can be handled in this fashion and it is possible 744 to create looping repair paths. 746 One possibility of looping repair paths is illustrated in Figure 8. 747 All links have a symmetrical cost of one with the exception of H-I, 748 which is cost 3 in both directions, and K-L and L-S1 which are cost 5 749 in the indicated direction and cost 1 in the other. 751 [S]---//---[E]--------[S1] 752 | | |^ 753 | | |5 754 [H]-3-[I]--[J]--[K]---[L] 755 5> 757 Figure 8: Looping secondary repair paths 759 In this topology, S can establish a repair path to J, but cannot 760 establish a repair path to S1 because of interference. Router S 761 might assign traffic intended for S1 onto its repair path to J 762 expecting it to undergo a secondary repair towards S1. However, 763 because of the asymmetrical link costs, J is unable to establish a 764 repair path to S1. It is only able to establish a repair path to S. 765 If J, like S, elected to forward repaired traffic to S1 using its 766 (only) repair path to S, similarly expecting a secondary repair to 767 get it to its destination, traffic for S1 would loop between S and J. 769 Thus when interference occurs, the possibility of a secondary repair 770 path cannot be relied upon to ensure that traffic reaches its 771 destination. 773 In order to determine the viability of secondary repair paths, it is 774 necessary for each router to take into account the repair paths which 775 the other neighbours of router E can achieve. These can be computed 776 locally by running the repair path computation algorithms rooted at 777 each of those neighbours. It is only necessary to compute the repair 778 paths from the routers to which router S can establish repair paths, 779 with targets of those routers to which repair paths have not yet been 780 established. 782 It is then possible to determine whether all routers can now be 783 reached by invoking secondary (or if necessary tertiary, etc.) repair 784 paths, and if so, to which primary repair path traffic for each 785 target should be assigned. 787 There is another, more subtle, possibility of loops arising when 788 secondary repair paths are used. This is illustrated in Figure 9, 789 where all links are cost 1 with the exception of L-K which has a cost 790 5 in that direction and cost 1 in the direction K-L. 792 [S]---//---[E]--------[S1] 793 | | | 794 | | | 795 [L] | [D] 796 5| | | 797 v| | | 798 [K]---[J]--[I]---[H]--[E] 800 Figure 9: Example of an apparently non-looping secondary repair path 801 which results in a loop. 803 Router S has a primary repair path to I (with a release point of K), 804 and I has a primary repair path to S1 (with a release point of E). 805 It would appear that these form a non-looping secondary repair path 806 from S to S1. As usual, the primary repair path from S to I has been 807 computed on the basis of destinations normally reachable through E-I. 808 However, when making use of the secondary repair path, the traffic 809 inserted in the repair path from S to I will be destined not for one 810 of the routers normally reachable via E-I, but for S1. Hence this 811 repair path is not necessary valid for such traffic and in this 812 example it will have a 50% probability of being forwarded back along 813 the path K-L-S-E-S1, and hence looping. 815 This problem can in general be avoided by choosing a release point 816 for the initial primary repair with the property that traffic for the 817 secondary target (S1) is guaranteed to traverse the primary target 818 (I). This can be achieved by computing the rSTF rooted at the 819 secondary target (S1) and examining the sub-tree which traverses the 820 primary target. It can be proved that in the absence of asymmetric 821 link costs, such a release point will always exist. Where asymmetric 822 link costs prevent this, the traffic can be encapsulated to the 823 intermediate router (I), which may require the use of double 824 encapsulation. On reaching router I, the traffic for S1 is 825 decapsulated and then forwarded in I's primary repair path to S1 (via 826 router E, in the example). 828 6.5. Multi-homed Prefixes 830 Up to this point, it has been assumed that any particular prefix is 831 "attached" to exactly one router in the network, and consequently 832 only the routers in the network need be considered when constructing 833 repair paths, etc. However, in many cases the same prefix will be 834 attached to two or more routers. Common cases are: 836 o The subnet present on a link is advertised from both ends of the 837 link. 839 o Prefixes are propagated from one routing domain to another by 840 multiple routers. 842 o Prefixes are advertised from multiple routers to provide 843 resilience in the event of the failure of one of the routers. 845 In general, this causes no particular problems, and the shortest 846 route to each prefix (and hence which of the routers to which it is 847 attached should be used to reach it) is resolved by the normal SPF 848 process. However, in the particular case where one of the instances 849 of a prefix is attached to router E, or to a router for which router 850 E is a single point of failure, the situation is more complicated. 852 p 853 | 854 | 855 [S]---//---[E]--------[S1] 856 | | p 857 | | | 858 [W]-----[X]----[Y]----[Z]-[I]-[J]-[K]-[L]-[M]-[N] 860 Figure 10: A multi-homed prefix p 862 Consider a prefix p, which is attached to router E and some other 863 router N as illustrated in Figure 10. Before the failure of the link 864 S-E, p is reachable from S via S-E. After the failure it cannot be 865 assumed that E is still reachable. If traffic to p is assigned to a 866 link repair path to E (as it would be if p were attached only to E), 867 and router E has failed, then it would loop and subsequently be 868 dropped. Traffic for p cannot simply be assigned to whatever repair 869 path would be used for traffic to N, because other routers, which are 870 not yet aware of any failure, may direct the traffic back towards E, 871 since the instance of p attached to E is closer. 873 A solution is to treat p itself as a neighbour of E, and compute a 874 repair path with p as a target. However, although correct, this 875 solution may be infeasible where there are a very large number of 876 such prefixes, which would result in an unacceptably large 877 computational overhead. 879 Some simplification is possible where there exist a large number of 880 multi-homed prefixes which all share the same connectivity and 881 metrics. These may be treated as a single router and a single repair 882 path computed for the entire set of prefixes. 884 An alternative solution is to tunnel the traffic for a multi-homed 885 prefix to the router N where it is also attached (see Figure 10). If 886 this involves a repair path that was already tunnelled, then this 887 requires double encapsulation. 889 6.6. LANs and pseudo-nodes 891 In link state protocols a LAN is represented by a construct known as 892 a pseudo-node in IS-IS and a network LSA in OSPF. 894 In order to deal correctly with this representation of LANs, the 895 algorithms described in this draft require certain modifications. 896 There are four cases which require consideration. These are 897 described in the following subsections. 899 6.6.1. The Link between Routers S and E is a LAN 901 In this case, the link which is being protected is a LAN, and the 902 router E which has potentially failed is reachable over the LAN. 903 This is illustrated in Figure 11. 905 [S] 906 | 907 ===================== 908 | | | | 909 [E] [X] [Y] [Z] 911 Figure 11: The link between routers S and E is a LAN 913 There are two possible failure modes in this case. 915 6.6.1.1. Case 1 917 Router E or its interface to the LAN may have failed independently of 918 the rest of the LAN. In this case the remaining routers on the LAN 919 (routers X, Y and Z) will remain reachable from router S. These 920 routers do not appear as direct neighbours of router E in the link 921 state database and are not treated as neighbours of router E for the 922 purposes of this specification because no traffic from router S would 923 be directed through router E to any of these routers. However, each 924 of these neighbouring routers will have router E as a neighbour and 925 they will initiate their own repair paths in the event of the failure 926 of router E or its LAN interface. 928 Repair paths are computed with the non-LAN neighbours of E as 929 targets, and also E itself (the "link-failure" repair path). Note 930 that since the remaining neighbours of S on the LAN are assumed to be 931 still reachable when the link to E has failed, these repair paths may 932 traverse the LAN. 934 A separate set of repair paths is required in anticipation of the 935 potential failure of each router on the LAN. 937 6.6.1.2. Case 2 939 Router S's interface to the LAN may have failed (or the entire LAN 940 may have failed). In either event, simultaneous failures will be 941 observed from router S to all the remaining routers on the LAN 942 (routers E, X, Y and Z). In this case, the pseudo-node itself can be 943 treated as the "adjacent" router (i.e. the router normally referred 944 to as "router E"), and repairs constructed using the normal 945 mechanisms with all the neighbours of the pseudo-node (routers E, X, 946 Y and Z) as repair path targets. If one or more of the routers had 947 failed in addition to the LAN connectivity, treating it as a repair 948 path target would not be viable, but this would be a case of multiple 949 simultaneous failures which is out of scope of this specification. 951 The entire sub-tree over S's LAN interface is the failed component 952 and is excised from the SPT when computing S's extended P-space. For 953 the Q-spaces of the targets, the sub-tree over the LAN interface of 954 the target is excised. 956 6.6.1.3. Simplified LAN repair 958 A simpler alternative strategy is to always consider the LAN and all 959 routers attached to it as failing as a single unit. In this case, a 960 single set of repair paths is computed with targets being the entire 961 set of non-LAN neighbours of all the routers on the LAN, together 962 with "link-repair" paths with all the routers on the LAN as targets. 963 Any failure of one or more LAN adjacencies results in these repair 964 paths being invoked for all neighbours on the LAN. These repair 965 paths must not traverse the LAN, and so must be computed by excising 966 the entire sub-tree reachable over S's LAN interface from S's SPT 967 (i.e. the entire LAN is the failed component). The Q-spaces are 968 computed as normal, with the LAN neighbours or their interface to the 969 LAN being excised as appropriate. This is simpler than the approach 970 proposed above, but will fail to make use of possible repair paths 971 (or even path splits) over the LAN. In particular, if the only 972 viable repair paths involve the LAN, it will prevent any repair being 973 possible. 975 6.6.2. A LAN exists at the release point 977 When computing the viable release points, it may be that one or more 978 of the leaf nodes are actually pseudo-nodes. In this case, the 979 release point is deemed to be any of the parent nodes on the LAN by 980 which the pseudo-node had been reached, and when computing the 981 extended set of release points (reachable by directed forwarding), 982 all the remaining routers on the LAN may be included. 984 6.6.3. A LAN between E and its neighbors 986 If there is a LAN between router E and one or more of E's neighbours 987 (other than router S), then rather than treating each of those 988 neighbours as a separate target to which a repair path must be 989 computed, the pseudo-node itself can be treated as a single target 990 for which a repair path can be computed. If there are other 991 neighbours of E which are directly attached to E, including those 992 which may also be attached to the LAN, they must still be treated as 993 an individual repair path target. 995 Normally a repair path with the pseudo-node as its target will have a 996 release point before the pseudo-node. However it is possible that 997 the release point would be computed as the pseudo-node itself. This 998 will occur if the rSPT rooted at the pseudo-node includes no routers 999 other than itself. In this case a single repair with the pseudo-node 1000 as target is not possible, and it is necessary to compute individual 1001 repair paths whose target are each of the neighbours of E on the LAN. 1003 6.6.4. The LAN is a Transit Subnet 1005 This is the most common case, where a LAN is traversed by a repair 1006 path, but is not in any of the special positions described above. In 1007 this case no special treatment is required, and the normal SPF 1008 mechanisms are applicable. 1010 7. Failure Detection and Repair Path Activation 1012 The details of repair path activation are inherently implementation- 1013 dependent and must be addressed by individual design specifications. 1014 This section describes the implementation independent aspects of the 1015 fail-over to the repair path. 1017 7.1. Failure Detection 1019 The failure detection mechanism must provide timely detection of the 1020 failure and activation of the repair paths. The failure detection 1021 mechanisms may be media specific (for example loss of light), or may 1022 be generic (for example BFD [I-D.ietf-bfd-base]). Multiple detection 1023 mechanisms may be used in order to improve detection latency. Note 1024 that in the case of a LAN it may be necessary to monitor connectivity 1025 to all of the adjacent routers on the LAN. 1027 7.2. Repair Path Activation 1029 The mechanism used by the router to activate the repair path 1030 following failure will be implementation specific. 1032 An implementation that is capable of withdrawing the repair may delay 1033 the start of network convergence in order to minimise network 1034 disruption in the event that the failure was a transient. 1036 7.3. Node Failure Detection Mechanism 1038 When router S detects a failure of the S-E link, it will invoke the 1039 link repair path from itself to router S. This S-E link repair is 1040 always invoked because even if all other traffic can be re-routed, E 1041 is always a single point of failure to itself. If router E has 1042 failed, the S-E link repair can result in a forwarding loop. A node 1043 failure detection mechanism is therefore needed. A suitable 1044 mechanism might be to run BFD ( [I-D.ietf-bfd-base]) between S and E, 1045 over the S-E link repair path. 1047 When the node failure detection mechanism has determined that router 1048 E has failed it withdraws the S-E link repair path. The node failure 1049 detection and revocation of the S-E link repair needs to be 1050 expedited, in order to minimise the duration of collateral damage to 1051 the network cause by packets looping around the S-E link repair path. 1053 If E is a single point of failure to some destinations, then 1054 withdrawing the S-E link repair has no impact on network 1055 connectivity, because those destinations will have been rendered 1056 unreachable by the failure of router E. 1058 If E is not a single point of failure, but traffic to some 1059 destinations is being repaired via the S-E link because of the 1060 inability to provide suitable repair paths, then there are 1061 destinations that are rendered temporarily unreachable by IPFRR. The 1062 IPFRR loop free convergence mechanism delays normal convergence of 1063 the network. Consideration therefore has to be given to the relative 1064 importance of the traffic being protected and the traffic being 1065 black-holed. Depending on the outcome of that consideration, the 1066 IPFRR loop-free strategy may need to be abandoned. 1068 8. Loop Free Transition 1070 Once the repair paths have been activated, data will again be 1071 forwarded correctly. At this stage only the routers directly 1072 adjacent to the failure will be aware of the failure because no 1073 routing information concerning the failure has yet been propagated to 1074 other routers. The network now has to be transitioned to normal 1075 operation using the available components. 1077 During network transition inconsistent state may lead to the 1078 formation of micro-loops. During this period, packets may be 1079 prevented from reaching the repair path, may expire due to transiting 1080 an excessive number of hops, may be subject to excessive delay, and 1081 the resultant congestion may disrupt the passage of other packets 1082 through the network. A loop free transition technique which allows 1083 the network to re-converge without packet loss or disruption is 1084 therefore required. 1086 A number of suitable loop-free convergence techniques are described 1087 in [I-D.ietf-rtgwg-lf-conv-frmwk]. 1089 9. IPFRR Capability 1091 In the previous sections it has been assumed that all routers in the 1092 network are capable of acting as IPFRR routers, performing such tasks 1093 as tunnel termination and directed forwarding. In practise this is 1094 unlikely to be the case, partially because of the heterogeneous 1095 nature of a practical network, and partially because of the need to 1096 progressively deploy such capability. IPFRR therefore needs to 1097 support some form of capability announcement, and the algorithms need 1098 to take these capabilities into account when calculating their path 1099 repair strategies. For example, the ability of routers to function 1100 as tunnel end points and perform directed forwarding will influence 1101 the choice of repair path. However, routers which are simply 1102 traversed by repair paths (tunnelled or not) do not need to be IPFRR 1103 capable in order to guarantee correct operation of the repair paths. 1105 10. Enhancements to routing protocols 1107 It will be seen from the above that a number of enhancements to the 1108 appropriate routing protocols are needed to support IPFRR. The 1109 following possible enhancements have been identified: 1111 o The ability to advertise IPFRR capability 1113 o The ability to advertise tunnel endpoint capability 1115 o The ability to advertise directed forwarding identifiers 1117 o The ability to announce the start of a loop-free transition, and 1118 to abort a loop-free transition. 1120 o The ability to signal transition completion status to neighbours. 1122 o The ability to advertise that a link is protected. 1124 Capability advertisement should make use of existing capability 1125 mechanisms in the routing protocols. The exact set of enhancements 1126 will depend on specific IPFRR design choices. 1128 11. IANA Considerations 1130 There are no IANA considerations that arise from this architectural 1131 description of IPFRR. However there will be changes to the IGPs to 1132 support IPFRR in which there will be IANA considerations. 1134 12. Security Considerations 1136 Changes to the IGPs to support IPFRR do not introduce any additional 1137 security risks. 1139 The security implications of the increased convergence time due to 1140 the loop avoidance strategy depend on the approach to multiple 1141 failures. If the presence of multiple failures results in the 1142 network aborting the loop free strategy, then the convergence time 1143 will be similar to that of a conventional network. On the other 1144 hand, an attacker in a position to disrupt part of a network might 1145 use this to disrupt the repair of a critical path. 1147 The tunnel endpoints need to be secured to prevent their use as a 1148 facility by an attacker. Performance considerations indicate that 1149 tunnels cannot be secured by IPsec [RFC4301]. A system of packet 1150 address policing, both at the tunnel endpoints and at the edges of 1151 the network would prevent an attacker's packet arriving at a tunnel 1152 endpoint and would seem to be the best strategy. 1154 When a fast re-route is in progress, there may be an unacceptable 1155 increase in traffic load over the repair path. Network operators 1156 need to examine the computed repair paths and ensure that they have 1157 sufficient capacity. 1159 13. Acknowledgments 1161 The authors acknowledge the significant technical contributions made 1162 to this work by their colleagues: John Harper and Kevin Miles. 1164 14. Security Considerations 1166 All micro-loop control mechanisms raise significant security issues 1167 which must be addressed in their detailed technical description. 1169 15. Informative References 1171 [I-D.ietf-bfd-base] 1172 Katz, D. and D. Ward, "Bidirectional Forwarding 1173 Detection", draft-ietf-bfd-base-06 (work in progress), 1174 March 2007. 1176 [I-D.ietf-rtgwg-ipfrr-framework] 1177 Shand, M. and S. Bryant, "IP Fast Reroute Framework", 1178 draft-ietf-rtgwg-ipfrr-framework-07 (work in progress), 1179 July 2007. 1181 [I-D.ietf-rtgwg-ipfrr-notvia-addresses] 1182 Bryant, S., "IP Fast Reroute Using Not-via Addresses", 1183 draft-ietf-rtgwg-ipfrr-notvia-addresses-01 (work in 1184 progress), July 2007. 1186 [I-D.ietf-rtgwg-ipfrr-spec-base] 1187 Atlas, A. and A. Zinin, "Basic Specification for IP Fast- 1188 Reroute: Loop-free Alternates", 1189 draft-ietf-rtgwg-ipfrr-spec-base-09 (work in progress), 1190 September 2007. 1192 [I-D.ietf-rtgwg-lf-conv-frmwk] 1193 Bryant, S. and M. Shand, "A Framework for Loop-free 1194 Convergence", draft-ietf-rtgwg-lf-conv-frmwk-01 (work in 1195 progress), July 2007. 1197 [RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic 1198 Routing Encapsulation (GRE)", RFC 1701, October 1994. 1200 [RFC1853] Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995. 1202 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1203 Requirement Levels", BCP 14, RFC 2119, March 1997. 1205 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 1206 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 1207 Encoding", RFC 3032, January 2001. 1209 [RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling 1210 Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005. 1212 [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute 1213 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 1214 May 2005. 1216 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1217 Internet Protocol", RFC 4301, December 2005. 1219 Authors' Addresses 1221 Stewart Bryant 1222 Cisco Systems 1223 250, Longwater, Green Park, 1224 Reading RG2 6GB, UK 1225 UK 1227 Email: stbryant@cisco.com 1228 Clarence Filsfils 1229 Cisco Systems 1230 De Kleetlaan 6a 1231 1831 Diegem, 1232 Belgium 1234 Phone: 1235 Fax: 1236 Email: cfilsfil@cisco.com 1237 URI: 1239 Stefano Previdi 1240 Cisco Systems 1241 Via Del Serafico 200 1242 00142 Roma, 1243 Italy 1245 Phone: 1246 Fax: 1247 Email: sprevidi@cisco.com 1248 URI: 1250 Mike Shand 1251 Cisco Systems 1252 250, Longwater, Green Park, 1253 Reading RG2 6GB, UK 1254 UK 1256 Email: mshand@cisco.com 1258 Full Copyright Statement 1260 Copyright (C) The IETF Trust (2007). 1262 This document is subject to the rights, licenses and restrictions 1263 contained in BCP 78, and except as set forth therein, the authors 1264 retain all their rights. 1266 This document and the information contained herein are provided on an 1267 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1268 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1269 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1270 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1271 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1272 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1274 Intellectual Property 1276 The IETF takes no position regarding the validity or scope of any 1277 Intellectual Property Rights or other rights that might be claimed to 1278 pertain to the implementation or use of the technology described in 1279 this document or the extent to which any license under such rights 1280 might or might not be available; nor does it represent that it has 1281 made any independent effort to identify any such rights. Information 1282 on the procedures with respect to rights in RFC documents can be 1283 found in BCP 78 and BCP 79. 1285 Copies of IPR disclosures made to the IETF Secretariat and any 1286 assurances of licenses to be made available, or the result of an 1287 attempt made to obtain a general license or permission for the use of 1288 such proprietary rights by implementers or users of this 1289 specification can be obtained from the IETF on-line IPR repository at 1290 http://www.ietf.org/ipr. 1292 The IETF invites any interested party to bring to its attention any 1293 copyrights, patents or patent applications, or other proprietary 1294 rights that may cover technology that may be required to implement 1295 this standard. Please address the information to the IETF at 1296 ietf-ipr@ietf.org. 1298 Acknowledgment 1300 Funding for the RFC Editor function is provided by the IETF 1301 Administrative Support Activity (IASA).