idnits 2.17.1 draft-ietf-rtgwg-ipfrr-framework-07.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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 666. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 567. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 574. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 580. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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 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 (June 2007) is 6153 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 (-12) exists of draft-ietf-rtgwg-ipfrr-spec-base-06 == Outdated reference: A later version (-11) exists of draft-ietf-bfd-base-06 -- Unexpected draft version: The latest known version of draft-bryant-shand-lf-conv-frmwk is -03, but you're referring to -04. == Outdated reference: A later version (-11) exists of draft-ietf-rtgwg-ipfrr-notvia-addresses-01 == Outdated reference: A later version (-03) exists of draft-bryant-ipfrr-tunnels-02 -- Unexpected draft version: The latest known version of draft-atlas-ip-local-protect is -00, but you're referring to -03. Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group M. Shand 2 Internet Draft S. Bryant 3 Expiration Date: Dec 2007 Cisco Systems 5 June 2007 7 IP Fast Reroute Framework 9 draft-ietf-rtgwg-ipfrr-framework-07.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that other 20 groups may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress". 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Copyright Notice 35 Copyright (C) The IETF Trust (2007). All rights reserved. 37 Abstract 39 This document provides a framework for the development of IP 40 fast-reroute mechanisms which provide protection against link or 41 router failure by invoking locally determined repair paths. Unlike 42 MPLS Fast-reroute, the mechanisms are applicable to a network 43 employing conventional IP routing and forwarding. An essential part 44 of such mechanisms is the prevention of packet loss caused by the 45 loops which normally occur during the re-convergence of the network 46 following a failure. 48 Terminology 50 This section defines words and acronyms used in this draft and other 51 drafts discussing IP Fast-reroute. 53 D Used to denote the destination router under 54 discussion. 56 Distance_opt(A,B) The distance of the shortest path from A 57 to B. 59 Downstream Path This is a subset of the loop-free alternates 60 where the neighbor N meet the following 61 condition:- 63 Distance_opt(N, D) < Distance_opt(S,D) 65 E Used to denote the router which is the 66 primary next-hop neighbor to get from S to 67 the destination D. Where there is an ECMP set 68 for the shortest path from S to D, these are 69 referred to as E_1, E_2, etc. 71 ECMP Equal cost multi-path: Where, for a 72 particular destination D, multiple primary 73 next-hops are used to forward traffic because 74 there exist multiple shortest paths from S 75 via different output layer-3 interfaces. 77 FIB Forwarding Information Base. The database 78 used by the packet forwarder to determine 79 what actions to perform on a packet. 81 IPFRR IP fast-reroute 83 Link(A->B) A link connecting router A to router B. 85 Loop-Free This is a neighbor N, that is not a primary 86 Alternate next-hop neighbor E, whose shortest path to 87 the destination D does not go back through 88 the router S. The neighbor N must meet the 89 following condition:- 91 Distance_opt(N, D) < Distance_opt(N, S) + 92 Distance_opt(S, D) 94 Loop-Free A neighbor N_i, which is not the particular 95 Neighbor primary neighbor E_k under discussion, and 96 whose shortest path to D does not traverse S. 97 For example, if there are two primary 98 neighbors E_1 and E_2, E_1 is a loop-free 99 neighbor with regard to E_2 and vice versa. 101 Loop-Free This is a path via a Loop-Free Neighbor N_i 102 Link-Protecting which does not go through the particular link 103 Alternate of S which is being protected to reach the 104 destination D. 106 Loop-Free This is a path via a Loop-Free Neighbor N_i 107 Node-Protecting which does not go through the particular 108 Alternate primary neighbor of S which is being 109 protected to reach the destination D. 111 Micro-loop A temporary forwarding loop which exists 112 during a routing transition as a result of 113 temporary inconsistencies between FIBs. 115 N_i The ith neighbor of S. 117 Primary Neighbor A neighbor N_i of S which is one of the next 118 hops for destination D in S's FIB prior to 119 any failure. 121 R_i_j The jth neighbor of N_i. 123 Routing The process whereby routers converge on a new 124 transition topology. In conventional networks this 125 process frequently causes some disruption to 126 packet delivery. 128 RPF Reverse Path Forwarding. I.e. checking that a 129 packet is received over the interface which 130 would be used to send packets addressed to 131 the source address of the packet. 133 S Used to denote a router that is the source of 134 a repair that is computed in anticipation of 135 the failure of a neighboring router denoted 136 as E, or of the link between S and E. It is 137 the viewpoint from which IP Fast-Reroute is 138 described. 140 S_i The set of neighbors of E, in addition to S, 141 which will independently take the role of S 142 for the traffic they carry. 144 SPF Shortest Path First, e.g. Dijkstra's 145 algorithm. 147 SPT Shortest path tree 149 Upstream This is a forwarding loop which involves a 150 Forwarding Loop set of routers, none of which are directly 151 connected to the link which has caused the 152 topology change that triggered a new SPF in 153 any of the routers. 155 1. Introduction 157 When a link or node failure occurs in a routed network, there is 158 inevitably a period of disruption to the delivery of traffic until 159 the network re-converges on the new topology. Packets for 160 destinations which were previously reached by traversing the failed 161 component may be dropped or may suffer looping. Traditionally such 162 disruptions have lasted for periods of at least several seconds, and 163 most applications have been constructed to tolerate such a quality of 164 service. 166 Recent advances in routers have reduced this interval to under a 167 second for carefully configured networks using link state IGPs. 168 However, new Internet services are emerging which may be sensitive to 169 periods of traffic loss which are orders of magnitude shorter than 170 this. 172 Addressing these issues is difficult because the distributed nature 173 of the network imposes an intrinsic limit on the minimum convergence 174 time which can be achieved. 176 However, there is an alternative approach, which is to compute backup 177 routes that allow the failure to be repaired locally by the router(s) 178 detecting the failure without the immediate need to inform other 179 routers of the failure. In this case, the disruption time can be 180 limited to the small time taken to detect the adjacent failure and 181 invoke the backup routes. This is analogous to the technique employed 182 by MPLS Fast-Reroute [MPLSFRR], but the mechanisms employed for the 183 backup routes in pure IP networks are necessarily very different. 185 This document provides a framework for the development of this 186 approach. 188 2. Problem Analysis 190 The duration of the packet delivery disruption caused by a 191 conventional routing transition is determined by a number of factors: 193 1. The time taken to detect the failure. This may be of the order 194 of a few mS when it can be detected at the physical layer, up to 195 several tens of seconds when a routing protocol hello is 196 employed. During this period packets will be unavoidably lost. 198 2. The time taken for the local router to react to the failure. 199 This will typically involve generating and flooding new routing 200 updates, perhaps after some hold-down delay, and re-computing 201 the router's FIB. 203 3. The time taken to pass the information about the failure to 204 other routers in the network. In the absence of routing protocol 205 packet loss, this is typically between 10mS and 100mS per hop. 207 4. The time taken to re-compute the forwarding tables. This is 208 typically a few mS for a link state protocol using Dijkstra's 209 algorithm. 211 5. The time taken to load the revised forwarding tables into the 212 forwarding hardware. This time is very implementation dependant 213 and also depends on the number of prefixes affected by the 214 failure, but may be several hundred mS. 216 The disruption will last until the routers adjacent to the failure 217 have completed steps 1 and 2, and then all the routers in the network 218 whose paths are affected by the failure have completed the remaining 219 steps. 221 The initial packet loss is caused by the router(s) adjacent to the 222 failure continuing to attempt to transmit packets across the failure 223 until it is detected. This loss is unavoidable, but the detection 224 time can be reduced to a few tens of mS as described in section 3.1. 226 Subsequent packet loss is caused by the "micro-loops" which form 227 because of temporary inconsistencies between routers' forwarding 228 tables. These occur as a result of the different times at which 229 routers update their forwarding tables to reflect the failure. These 230 variable delays are caused by steps 3, 4 and 5 above and in many 231 routers it is step 5 which is both the largest factor and which has 232 the greatest variance between routers. The large variance arises from 233 implementation differences and from the differing impact that a 234 failure has on each individual router. For example, the number of 235 prefixes affected by the failure may vary dramatically from one 236 router to another. 238 In order to achieve packet disruption times which are commensurate 239 with the failure detection times it is necessary to perform two 240 distinct tasks: 242 1. Provide a mechanism for the router(s) adjacent to the failure to 243 rapidly invoke a repair path, which is unaffected by any 244 subsequent re-convergence. 246 2. Provide a mechanism to prevent the effects of micro-loops during 247 subsequent re-convergence. 249 Performing the first task without the second will result in the 250 repair path being starved of traffic and hence being redundant. 251 Performing the second without the first will result in traffic being 252 discarded by the router(s) adjacent to the failure. Both tasks are 253 necessary for an effective solution to the problem. 255 However, repair paths can be used in isolation where the failure is 256 short-lived. The repair paths can be kept in place until the failure 257 is repaired and there is no need to advertise the failure to other 258 routers. 260 Similarly, micro-loop avoidance can be used in isolation to prevent 261 loops arising from pre-planned management action, because the link or 262 node being shut down can remain in service for a short time after its 263 removal has been announced into the network, and hence it can 264 function as its own "repair path". 266 Note that micro-loops can also occur when a link or node is restored 267 to service and thus a micro-loop avoidance mechanism is required for 268 both link up and link down cases. 270 3. Mechanisms for IP Fast-reroute 272 The set of mechanisms required for an effective solution to the 273 problem can be broken down into the following sub-problems. 275 3.1. Mechanisms for fast failure detection 277 It is critical that the failure detection time is minimized. A number 278 of approaches are possible, such as: 280 1. Physical detection; for example, loss of light. 282 2. Routing protocol independent protocol detection; for example, 283 The Bidirectional Failure Detection protocol [BFD]. 285 3. Routing protocol detection; for example, use of "fast hellos". 287 3.2. Mechanisms for repair paths 289 Once a failure has been detected by one of the above mechanisms, 290 traffic which previously traversed the failure is transmitted over 291 one or more repair paths. The design of the repair paths should be 292 such that they can be pre-calculated in anticipation of each local 293 failure and made available for invocation with minimal delay. There 294 are three basic categories of repair paths: 296 1. Equal cost multi-paths (ECMP). Where such paths exist, and one 297 or more of the alternate paths do not traverse the failure, they 298 may trivially be used as repair paths. 300 2. Loop free alternate paths. Such a path exists when a direct 301 neighbor of the router adjacent to the failure has a path to the 302 destination which can be guaranteed not to traverse the failure. 304 3. Multi-hop repair paths. When there is no feasible loop free 305 alternate path it may still be possible to locate a router, 306 which is more than one hop away from the router adjacent to the 307 failure, from which traffic will be forwarded to the destination 308 without traversing the failure. 310 ECMP and loop free alternate paths (as described in [BASE]) offer the 311 simplest repair paths and would normally be used when they are 312 available. It is anticipated that around 80% of failures (see section 313 3.2.2) can be repaired using these basic methods alone. 315 Multi-hop repair paths are more complex, both in the computations 316 required to determine their existence, and in the mechanisms required 317 to invoke them. They can be further classified as: 319 1. Mechanisms where one or more alternate FIBs are pre-computed in 320 all routers and the repaired packet is instructed to be 321 forwarded using a "repair FIB" by some method of per packet 322 signaling such as detecting a "U-turn" [U-TURNS, FIFR] or by 323 marking the packet [SIMULA]. 325 2. Mechanisms functionally equivalent to a loose source route which 326 is invoked using the normal FIB. These include tunnels 327 [TUNNELS], alternative shortest paths [ALT-SP] and label based 328 mechanisms. 330 3. Mechanisms employing special addresses or labels which are 331 installed in the FIBs of all routers with routes pre-computed to 332 avoid certain components of the network. For example [NOT-VIA]. 334 In many cases a repair path which reaches two hops away from the 335 router detecting the failure will suffice, and it is anticipated that 336 around 98% of failures (see section 3.2.2) can be repaired by this 337 method. However, to provide complete repair coverage some use of 338 longer multi-hop repair paths is generally necessary. 340 3.2.1. Scope of repair paths 342 A particular repair path may be valid for all destinations which 343 require repair or may only be valid for a subset of destinations. If 344 a repair path is valid for a node immediately downstream of the 345 failure, then it will be valid for all destinations previously 346 reachable by traversing the failure. However, in cases where such a 347 repair path is difficult to achieve because it requires a high order 348 multi-hop repair path, it may still be possible to identify lower 349 order repair paths (possibly even loop free alternate paths) which 350 allow the majority of destinations to be repaired. When IPFRR is 351 unable to provide complete repair, it is desirable that the extent of 352 the repair coverage can be determined and reported via network 353 management. 355 There is a tradeoff to be achieved between minimizing the number of 356 repair paths to be computed, and minimizing the overheads incurred in 357 using higher order multi-hop repair paths for destinations for which 358 they are not strictly necessary. However, the computational cost of 359 determining repair paths on an individual destination basis can be 360 very high. 362 It will frequently be the case that the majority of destinations may 363 be repaired using only the "basic" repair mechanism, leaving a 364 smaller subset of the destinations to be repaired using one of the 365 more complex multi-hop methods. Such a hybrid approach may go some 366 way to resolving the conflict between completeness and complexity. 368 The use of repair paths may result in excessive traffic passing over 369 a link, resulting in congestion discard. This reduces the 370 effectiveness of IPFRR. Mechanisms to influence the distribution of 371 repaired traffic to minimize this effect are therefore desirable. 373 3.2.2. Analysis of repair coverage 375 In some cases the repair strategy will permit the repair of all 376 single link or node failures in the network for all possible 377 destinations. This can be defined as 100% coverage. However, where 378 the coverage is less than 100% it is important for the purposes of 379 comparisons between different proposed repair strategies to define 380 what is meant by such a percentage. There are four possibilities: 382 1. The percentage of links (or nodes) which can be fully protected 383 for all destinations. This is appropriate where the requirement 384 is to protect all traffic, but some percentage of the possible 385 failures may be identified as being un-protectable. 387 2. The percentage of destinations which can be fully protected for 388 all link (or node) failures. This is appropriate where the 389 requirement is to protect against all possible failures, but 390 some percentage of destinations may be identified as being 391 un-protectable. 393 3. For all destinations (d) and for all failures (f), the 394 percentage of the total potential failure cases (d*f) which are 395 protected. This is appropriate where the requirement is an 396 overall "best effort" protection. 398 4. The percentage of packets normally passing though the network 399 that will continue to reach their destination. This requires a 400 traffic matrix for the network as part of the analysis. 402 The coverage obtained is dependent on the repair strategy and highly 403 dependent on the detailed topology and metrics. Any figures quoted in 404 this document are for illustrative purposes only. 406 3.2.3. Link or node repair 408 A repair path may be computed to protect against failure of an 409 adjacent link, or failure of an adjacent node. In general, link 410 protection is simpler to achieve. A repair which protects against 411 node failure will also protect against link failure for all 412 destinations except those for which the adjacent node is a single 413 point of failure. 415 In some cases it may be necessary to distinguish between a link or 416 node failure in order that the optimal repair strategy is invoked. 417 Methods for link/node failure determination may be based on 418 techniques such as BFD. This determination may be made prior to 419 invoking any repairs, but this will increase the period of packet 420 loss following a failure unless the determination can be performed as 421 part of the failure detection mechanism itself. Alternatively, a 422 subsequent determination can be used to optimise an already invoked 423 default strategy. 425 3.2.4. Maintenance of Repair paths 427 In order to meet the response time goals, it is expected (though not 428 required) that repair paths, and their associated FIB entries, will 429 be pre-computed and installed ready for invocation when a failure is 430 detected. Following invocation the repair paths remain in effect 431 until they are no longer required. This will normally be when the 432 routing protocol has re-converged on the new topology taking into 433 account the failure, and traffic will no longer be using the repair 434 paths. 436 The repair paths have the property that they are unaffected by any 437 topology changes resulting from the failure which caused their 438 instantiation. Therefore there is no need to re-compute them during 439 the convergence period. They may be affected by an unrelated 440 simultaneous topology change, but such events are out of scope of 441 this work (see section 3.2.5). 443 Once the routing protocol has re-converged it is necessary for all 444 repair paths to take account of the new topology. Various 445 optimizations may permit the efficient identification of repair paths 446 which are unaffected by the change, and hence do not require full 447 re-computation. Since the new repair paths will not be required until 448 the next failure occurs, the re-computation may be performed as a 449 background task and be subject to a hold-down, but excessive delay in 450 completing this operation will increase the risk of a new failure 451 occurring before the repair paths are in place. 453 3.2.5. Multiple failures and Shared Risk Link Groups 455 Complete protection against multiple unrelated failures is out of 456 scope of this work. However, it is important that the occurrence of a 457 second failure while one failure is undergoing repair should not 458 result in a level of service which is significantly worse than that 459 which would have been achieved in the absence of any repair strategy. 461 Shared Risk Link Groups are an example of multiple related failures, 462 and the more complex aspects of their protection is a matter for 463 further study. 465 One specific example of an SRLG which is clearly within the scope of 466 this work is a node failure. This causes the simultaneous failure of 467 multiple links, but their closely defined topological relationship 468 makes the problem more tractable. 470 3.3. Local Area Networks 472 Protection against partial or complete failure of LANs is more 473 complex than the point to point case. In general there is a tradeoff 474 between the simplicity of the repair and the ability to provide 475 complete and optimal repair coverage. 477 3.4. Mechanisms for micro-loop prevention 479 Control of micro-loops is important not only because they can cause 480 packet loss in traffic which is affected by the failure, but because 481 by saturating a link with looping packets they can also cause 482 congestion loss of traffic flowing over that link which would 483 otherwise be unaffected by the failure. 485 A number of solutions to the problem of micro-loop formation have 486 been proposed and are summarized in [MICROLOOP]. The following 487 factors are significant in their classification: 489 1. Partial or complete protection against micro-loops. 491 2. Delay imposed upon convergence. 493 3. Tolerance of multiple failures (from node failures, and in 494 general). 496 4. Computational complexity (pre-computed or real time). 498 5. Applicability to scheduled events. 500 6. Applicability to link/node reinstatement. 502 4. Management Considerations 504 While many of the management requirements will be specific to 505 particular IPFRR solutions, the following general aspects need to be 506 addressed: 508 1. Configuration 510 a. Enabling/disabling IPFRR support. 512 b. Enabling/disabling protection on a per link/node basis. 514 c. Expressing preferences regarding the links/nodes used for 515 repair paths. 517 d. Configuration of failure detection mechanisms. 519 e. Configuration of loop avoidance strategies. 521 2. Monitoring 523 a. Notification of links/nodes/destinations which cannot be 524 protected. 526 b. Notification of pre-computed repair paths, and anticipated 527 traffic patterns. 529 c. Counts of failure detections, protection invocations and 530 packets forwarded over repair paths. 532 5. Scope and applicability 534 The initial scope of this work is in the context of link state IGPs. 535 Link state protocols provide ubiquitous topology information, which 536 facilitates the computation of repairs paths. 538 Provision of similar facilities in non-link state IGPs and BGP is a 539 matter for further study, but the correct operation of the repair 540 mechanisms for traffic with a destination outside the IGP domain is 541 an important consideration for solutions based on this framework 543 6. IANA considerations 545 There are no IANA considerations that arise from this framework 546 document. 548 7. Security Considerations 550 This framework document does not itself introduce any security 551 issues, but attention must be paid to the security implications of 552 any proposed solutions to the problem. 554 8. IPR Disclosure Acknowledgement 556 Certain IPR may be applicable to the mechanisms outlined in this 557 document. Please check the detailed specifications for possible IPR 558 notices. 560 The IETF takes no position regarding the validity or scope of any 561 Intellectual Property Rights or other rights that might be claimed to 562 pertain to the implementation or use of the technology described in 563 this document or the extent to which any license under such rights 564 might or might not be available; nor does it represent that it has 565 made any independent effort to identify any such rights. Information 566 on the procedures with respect to rights in RFC documents can be 567 found in BCP 78 and BCP 79. 569 Copies of IPR disclosures made to the IETF Secretariat and any 570 assurances of licenses to be made available, or the result of an 571 attempt made to obtain a general license or permission for the use of 572 such proprietary rights by implementers or users of this 573 specification can be obtained from the IETF on-line IPR repository at 574 http://www.ietf.org/ipr. 576 The IETF invites any interested party to bring to its attention any 577 copyrights, patents or patent applications, or other proprietary 578 rights that may cover technology that may be required to implement 579 this standard. Please address the information to the IETF at 580 ietf-ipr@ietf.org. 582 9. Acknowledgements 584 The authors would like to acknowledge contributions made by Alia 585 Atlas and Alex Zinin. 587 10. Normative References 589 Internet-drafts are works in progress available from 590 http://www.ietf.org/internet-drafts/ 592 11. Informative References 594 Internet-drafts are works in progress available from 595 http://www.ietf.org/internet-drafts/ 597 [ALT-SP] Tian, A., Chen, N., "Fast Reroute using 598 Alternative Shortest Paths", draft-tian-frr- 599 alt-shortest-path-01.txt, (work in progress) 601 [BASE] Atlas, A., Zinin, A., "Basic Specification 602 for IP Fast-Reroute: Loop-free Alternates", 603 draft-ietf-rtgwg-ipfrr-spec-base-06.txt, 604 (work in progress) 606 [BFD] Katz, D. and Ward, D., "Bidirectional 607 Forwarding Detection", 608 draft-ietf-bfd-base-06.txt, (work in 609 progress). 611 [FIFR] S. Nelakuditi, S. Lee, Y. Yu, Z.-L. Zhang, 612 and C.-N. Chuah, "Fast local rerouting for 613 handling transient link failures.," Tech. 614 Rep. TR-2004-004, University of South 615 Carolina, 2004. 617 [MPLSFRR] Pan, P. et al, "Fast Reroute Extensions to 618 RSVP-TE for LSP Tunnels", RFC 4090. 620 [MICROLOOP] Bryant, S. and Shand, M., "A Framework for 621 Loop-free Convergence", 622 draft-bryant-shand-lf-conv-frmwk-04.txt, 623 (work in progress). 625 [NOT-VIA] Bryant, S., Previdi, S., Shand, M., "IP Fast 626 Reroute Using Notvia Addresses", 627 draft-ietf-rtgwg-ipfrr-notvia-addresses- 628 01.txt, (work in progress). 630 [SIMULA] Lysne, O., et al, "Fast IP Network Recovery 631 using Multiple Routing Configurations", 632 http://folk.uio.no/amundk/infocom06.pdf 634 [TUNNELS] Bryant, S. et al, "IP Fast Reroute using 635 tunnels", draft-bryant-ipfrr-tunnels-02.txt, 636 (work in progress). 638 [U-TURNS] Atlas, A. et al, "IP/LDP Local Protection", 639 draft-atlas-ip-local-protect-03.txt, (work in 640 progress). 642 12. Authors' Addresses 644 Stewart Bryant 645 Cisco Systems, 646 250, Longwater Avenue, 647 Green Park, 648 Reading, RG2 6GB, 649 United Kingdom. Email: stbryant@cisco.com 651 Mike Shand 652 Cisco Systems, 653 250, Longwater Avenue, 654 Green Park, 655 Reading, RG2 6GB, 656 United Kingdom. Email: mshand@cisco.com 658 Disclaimer of Validity 660 This document and the information contained herein are provided on an 661 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 662 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 663 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 664 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 665 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 666 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 668 Copyright statement 669 Copyright (C) The IETF Trust (2007). This document is subject to the 670 rights, licenses and restrictions contained in BCP 78, and except as 671 set forth therein, the authors retain all their rights.