idnits 2.17.1 draft-bryant-shand-lf-conv-frmwk-00.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 3667, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 565. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 537. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 544. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 550. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 13 longer pages, the longest (page 5) being 78 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 13 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (Oct 2004) is 7127 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) == Missing Reference: 'RFC2119' is mentioned on line 46, but not defined == Missing Reference: 'MPLS-TE' is mentioned on line 109, but not defined -- Obsolete informational reference (is this intentional?): RFC 3036 (ref. 'LDP') (Obsoleted by RFC 5036) Summary: 6 errors (**), 0 flaws (~~), 7 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group S. Bryant 2 Internet Draft M. Shand 3 Expiration Date: Apr 2005 Cisco Systems 5 Oct 2004 7 A Framework for Loop-free Convergence 8 10 Status of this Memo 12 By submitting this Internet-Draft, we certify that any applicable 13 patent or other IPR claims of which we are aware have been 14 disclosed, or will be disclosed, and any of which we become aware 15 will be disclosed, in accordance with RFC 3668. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as 20 Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other 24 documents at any time. It is inappropriate to use Internet-Drafts 25 as reference material or to cite them other than a "work in 26 progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/1id-abstracts.html 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 Abstract 35 This draft describes mechanisms that may be used to prevent or to 36 suppress the formation of micro-loops when an IP or MPLS network 37 undergoes topology change due to failure, repair or management 38 action. 40 Conventions used in this document 42 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 43 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 44 this document are to be interpreted as described in RFC 2119 45 [RFC2119]. 47 Table of Contents 48 1. Introduction........................................................3 50 2. The Nature of Micro-loops...........................................4 52 3. Micro-loop Control Strategies.......................................5 54 4. Micro-loop Prevention...............................................5 55 4.1. Incremental Cost Advertisement..................................6 56 4.2. Single Tunnel Per Router........................................6 57 4.3. Distributed Tunnels.............................................8 58 4.4. Ordered SPFs....................................................8 59 4.5. Synchronised FIB Updates........................................9 60 5. Loop Suppression....................................................9 62 6. Loop mitigation....................................................10 64 7. Compatibility Issues...............................................11 66 8. IANA considerations................................................11 68 9. Security Considerations............................................11 70 10. Intellectual Property Statement...................................12 72 11. Full copyright statement..........................................12 74 12. Normative References..............................................12 76 13. Informative References............................................13 78 14. Authors' Addresses................................................13 79 1. Introduction 81 When the topology of a network changes (due to link or router 82 failure, recovery or management action), the routers need to 83 converge on a common view of the new topology. During this process, 84 referred to as a routing transition, packet delivery between 85 certain source/destination pairs may be disrupted. This occurs due 86 to the time it takes for the topology change to be propagated 87 around the network plus the time it takes each individual router to 88 determine and then update the forwarding information base (FIB) for 89 the affected destinations. During this transition, packets are lost 90 due to the continuing attempts to use of the failed component, and 91 due to forwarding loops. Forwarding loops arise due to the 92 inconsistent FIBs that occur as a result of the difference in time 93 taken by routers to execute the transition process. This is a 94 problem that occurs in both IP networks and MPLS networks that use 95 LDP [LDP] as the label switched path (LSP) signaling protocol. 97 The service failures caused by routing transitions are largely 98 hidden by higher-level protocols that retransmit the lost data. 99 However new Internet services are emerging which are more sensitive 100 to the packet disruption that occurs during a transition. To make 101 the transition transparent to their users, these services require a 102 short routing transition. Ideally, routing transitions would be 103 completed in zero time with no packet loss. 105 Regardless of how optimally the mechanisms involved have been 106 designed and implemented, it is inevitable that a routing 107 transition will take some minimum interval that is greater than 108 zero. This has lead to the development of a TE fast-reroute 109 mechanism for MPLS [MPLS-TE]. Alternative mechanisms that might be 110 deployed in an MPLS network and mechanisms that may be used in an 111 IP network are work in progress in the IETF [IPFRR]. Any repair 112 mechanism may however be disrupted by the formation of micro-loops 113 during the period between the time when the failure is announced, 114 and the time when all FIBs have been updated to reflect the new 115 topology. 117 The disruptive effect of micro-loops is not confined to periods 118 when there is a component failure. Micro-loops can, for example, 119 form when a component is put back into service following repair. 120 Micro-loops can also form as a result of a network maintenance 121 action such as adding a new network component, removing a network 122 component or modifying a link cost. 124 There is an emerging need for extremely reliable networks, with 125 fast repair. However there is little point in providing this level 126 of reliability without also deploying mechanisms that prevent the 127 disruptive effects of micro-loops which may starve the repair or 128 cause congestion loss as a result of looping packets. 130 This framework provides a summary of the mechanisms that have been 131 proposed to address the micro-loop issue. 133 2. The Nature of Micro-loops 135 Micro-loops form during the periods when a network is reconverging 136 following a topology change, and are caused by inconsistent FIBs in 137 the routers. Micro-loops may occur over a single link between a 138 pair of routers that have each other as the next hop for a prefix. 139 Micro-loops may also form when a cycle of routers have the next 140 router in the cycle as a next hop for a prefix. Cyclic micro-loops 141 always include at least one link with an asymmetric cost, and/or at 142 least two symmetric cost link cost changes. 144 Micro-loops have two undesirable side-effects, congestion and 145 repair starvation. A looping packet consumes bandwidth until it 146 either escapes as a result of the re-synchronization of the FIBs, 147 or its TTL expires. This transiently increases the traffic over a 148 link by as much as 128 times, and may cause the link to congest. 149 This congestion reduces the bandwidth available to other traffic 150 (which is not otherwise affected by the topology change). As a 151 result the "innocent" traffic using the link experiences increased 152 latency, and is liable to congestive packet loss. 154 In cases where the link or node failure has been protected by a 155 fast re-route repair, the inconsistency in the FIBs prevents some 156 traffic from reaching the failure and hence being repaired. The 157 repair may thus become starved of traffic and hence become 158 ineffective. Thus in addition to the congestive damage, the repair 159 is rendered ineffective by the micro-loop. Similarly, if the 160 topology change is the result of management action the link could 161 have been retained in service throughout the transition (i.e. the 162 link acts as its own repair path), however, if micro-loops form, 163 they prevent productive forwarding during the transition. 165 Unless otherwise controlled, micro-loops may form in any part of 166 the network that forwards (or in the case of a new link, will 167 forward) packets over a path that includes the affected topology 168 change. The time taken to propagate the topology change through the 169 network, and the non-uniform time taken by each router to calculate 170 the new SPT and update its FIB may significantly extend the 171 duration of the packet disruption caused by the micro-loops. In 172 some cases a packet may be subject to disruption from microloops 173 which occur sequentially at links along the path, thus further 174 extending the period of disruption beyond that required to resolve 175 a single loop. 177 3. Micro-loop Control Strategies. 179 Micro-loop control strategies fall into three basic classes: 181 1. Micro-loop prevention 183 2. Micro-loop suppression 185 3. Micro-loop mitigation 187 A micro-loop prevention mechanism controls the re-convergence of 188 network in such a way that no micro-loops form. Such a micro-loop 189 prevention mechanism allows the continued use of any fast repair 190 method until the network has converged on its new topology, and 191 prevents the collateral damage that occurs to other traffic for the 192 duration of each micro-loop. These mechanisms normally extend the 193 duration of the re-convergence process. In the case of a fast 194 re-route repair this means that the network requires the repair to 195 remain in place longer than would otherwise be the case. This 196 causes extended problems to any traffic which is NOT repaired by an 197 imperfect repair (as does ANY method which delays re-convergence). 199 When a component is returned to service, or when a network 200 management action has taken place, this additional delay does not 201 cause traffic disruption, because there is no repair involved. 202 However the extended delay is undesirable because it leaves the 203 network vulnerable to multiple failures for a longer period. 205 A micro-loop suppression mechanism attempts to eliminate the 206 collateral damage done by micro-loops to other traffic. This may be 207 achieved by, for example, using a packet monitoring method, which 208 detects that a packet is looping and drops it. Such schemes make no 209 attempt to productively forward the packet throughout the network 210 transition. 212 A micro-loop mitigation scheme works by converging the network in 213 such a way that it reduces, but does not eliminate, the formation 214 of micro-loops. Such schemes cannot guarantee the productive 215 forwarding of packets during the transition. 217 4. Micro-loop Prevention 219 Five micro-loop prevention strategies have been proposed: 221 o Incremental cost advertisement 223 o Single Tunnel 225 o Distributed Tunnels 227 o Ordered SPF 228 o Synchronised FIBS 230 4.1. Incremental Cost Advertisement 232 When a link fails, the cost of the link is normally changed from 233 its assigned metric to "infinity". However it can be proved that: 234 if the link cost is increased in suitable increments, and the 235 network is allowed to stabilize before the next cost increment is 236 advertised, then no micro-loops will form. Once the link cost has 237 been increased to a value greater than that of the lowest 238 alternative cost around the link, the link may be disabled without 239 causing a micro-loop. 241 This approach has the advantage that it requires no change to the 242 routing protocol and hence will work in any network that uses a 243 link-state IGP. However the method can be extremely slow, 244 particularly if large metrics are used. For the duration of the 245 transition some parts of the network continue to use the old 246 forwarding path, and hence use any repair mechanism for an extended 247 period. In the case of a failure that cannot be fully repaired, 248 some destinations may become unreachable for an extended period. 250 Where the micro-loop prevention mechanism was being used to support 251 a fast re-route repair the network may be vulnerable to a second 252 failure for the duration of the controlled re-convergence. This is 253 because of the difficulty of producing non-conflicting repair 254 paths. 256 Where the micro-loop prevention mechanism was being used to support 257 a reconfiguration of the network the extended time is of less of an 258 issue. In this case, because the real forwarding path is available 259 throughout the whole transition, there is no conflict between 260 concurrent change actions throughout the network. 262 It will be appreciated that when a link is returned to service, its 263 cost is reduced in small steps from "infinity" to its final cost, 264 thereby providing similar micro-loop prevention during a 265 "good-news" event. 267 4.2. Single Tunnel Per Router 269 This mechanism works by creating an overlay network using tunnels 270 whose path is not effected by the topology change and carrying the 271 traffic affected by the change in that new network. When all the 272 traffic is in the new, tunnel based, network, the real network is 273 allowed to converge on the new topology. Because all the traffic 274 that would be affected by the change is carried in the overlay 275 network no micro-loops form. When all micro-loop preventing routers 276 have their tunnels in place, all the routers in the network are 277 informed of the change in the normal way, at which point 278 micro-loops may form within isolated islands of non-micro-loop 279 preventing routers. However, only traffic entering the network via 280 such routers can micro-loop. All traffic entering the network via a 281 micro-loop preventing router will be tunneled correctly to the 282 nearest repairing router, including, if necessary being tunneled 283 via a non-micro-loop preventing router, and will not micro-loop. 284 When all the non-micro-loop preventing routers have converged, the 285 micro-loop preventing routers can change from tunneling the packets 286 to forwarding normally according to the new topology. This 287 transition can occur in any order without micro-loops forming. 289 When a failure is detected (or a link is withdrawn from service), 290 the router adjacent to the failure issues a new ("covert") routing 291 message announcing the topology change. This message is propagated 292 through the network by all routers, but is only understood by 293 routers capable of using one of the tunnel based micro-loop 294 prevention mechanisms. 296 Each of the micro-loop preventing routers builds a tunnel to the 297 closest router adjacent to the failure. They then determine which 298 of their traffic would transit the failure and place that traffic 299 in the tunnel. When all of these tunnels are in place, the failure 300 is then announced as normal. Because these tunnels will be 301 unaffected by the transition, and because the routers protecting 302 the link will continue the repair (or forward across the link being 303 withdrawn), no traffic will be disrupted by the failure. When the 304 network has converged these tunnels are withdrawn, allowing traffic 305 to be forwarded along its new "natural" path. The order of tunnel 306 insertion and withdrawal is not important, provided that the 307 tunnels are all in place before the normal announcement is issued. 309 This method is faster then the incremental cost method because it 310 completes in fewer flood-SPF-FIBupdate cycles, and more importantly 311 completes in bounded time. 313 This technique has the disadvantage that it requires traffic to be 314 tunneled during the transition. This is an issue in IP networks 315 because not all router designs are capable of high performance IP 316 tunneling. It is also an issue in MPLS networks because the 317 encapsulating router has to know the labels set that the 318 decapsulating router is distributing. 320 A further disadvantage of this method is that it requires 321 co-operation from all the routers within the routing domain to 322 fully protect the network against micro-loops. However it can be 323 shown that these micro-loops will be confined to contiguous groups 324 of routers not executing this micro-loop prevention mechanism, and 325 that it will only affect traffic arriving at the network through 326 one of those routers. 328 It can be shown that this mechanism also works correctly when a 329 link is repaired or a new link added. 331 When a management change to the topology is required, again exactly 332 the same mechanism protects against micro-looping of packets by the 333 micro-loop preventing routers. 335 4.3. Distributed Tunnels 337 This is similar to the single tunnel per router approach except 338 that all micro-loop preventing routers calculate a set of link 339 failure paths using the methods described in [TUNNEL]. 341 This reduces the load on the tunnel endpoints, but the length of 342 time taken to calculate the repairs increases the convergence time. 344 This method suffers from the same disadvantages as the single 345 tunnel method. 347 4.4. Ordered SPFs 349 Micro loops occur when a node closer to the failed component 350 revises its routes to take account of the failure before a node 351 which is further away. By analyzing the reverse spanning tree over 352 which traffic is directed to the failed component, it is possible 353 to determine a strict ordering which ensures that nodes closer to 354 the root always process the failure after any nodes further away, 355 and hence micro loops are prevented. 357 When the failure has been announced, each router waits a multiple 358 of some time delay value. The multiple is determined by the nodes 359 position in the reverse spanning tree, and the delay value is 360 chosen to guarantee that a node can complete its processing within 361 this time. The convergence time may be reduced by employing a 362 signaling mechanism to notify the parent when all the children have 363 completed their processing, and hence when it was safe for the 364 parent to instantiate its new routes. 366 The property of this approach is therefore that it imposes a delay 367 which is bounded by the network diameter although in most cases it 368 will be much less. 370 When a link is returned to service the convergence process above is 371 reversed. A router first calculates the reverse spanning tree 372 rooted at the far end of the new link, and determines its distance 373 from the new link (in hops). It then waits a time that is 374 proportional to that distance before updating its FIB. It will be 375 seen that network management actions can similarly be undertaken by 376 treating a cost increase in a manner similar to a failure and a 377 cost decrease similar to a restoration. 379 The ordered SPF mechanism requires all nodes in the domain to 380 operate according to these procedures, and the presence of non 381 co-operating nodes can give rise to loops for any traffic which 382 traverses them (not just traffic which is originated through them). 383 Without additional mechanisms these loops could remain in place for 384 a significant time. 386 It should be noted that this method requires per router ordering, 387 but not per prefix ordering. A router must wait its turn to update 388 its FIB, but it should then update its entire FIB. 390 Another way of viewing the operation of this method is to realize 391 that there is a horizon of routers affected by the failure. Routers 392 beyond the horizon do not send packets via the failure. Routers at 393 the horizon have a neighbor that does not send packets via the 394 failure. It is then obvious that routers on the horizon can use 395 that neighbor as a loop free alternate to the destination and can 396 update their FIBs immediately. Once these routers have updated 397 their FIBs, they move over the horizon and it is their neighbors 398 closer to the failure that becomes the new horizon routers. 400 Only routers within the horizon need to change their FIBs and hence 401 only those routers need to delay changing their FIBs. 403 4.5. Synchronised FIB Updates 405 Micro-loops form because of the asynchronous nature of the FIB 406 update process during a network transition. In many router 407 architectures it is the time taken to update the FIB itself that is 408 the dominant term. One approach would be to have two FIBs and, in a 409 synchronized action throughout the network, to switch from the old 410 to the new. 412 This approach has a number of major issues. Firstly two complete 413 FIBs are needed which may create a scaling issue and secondly a 414 suitable network wide synchronization method is needed. However, 415 neither of these are insurmountable problems. 417 Since the FIB change synchronization will not be perfect there may 418 be some interval during which micro-loops form. Whether this scheme 419 is classified as a micro-loop prevention mechanism or a micro-loop 420 avoidance mechanism within this taxonomy is therefore dependent on 421 the degree of synchronization achieved. 423 5. Loop Suppression 425 A micro-loop suppression mechanism recognizes that a packet is 426 looping and drops it. One such approach would be for a router to 427 recognize, by some means, that it had seen the same packet before. 428 It is difficult to see how sufficiently reliable discrimination 429 could be achieved without some form of per-router signature such as 430 route recording. A packet recognizing approach therefore seems 431 infeasible. 433 An alternative approach would be to recognize that a packet was 434 looping by recognizing that it was being sent back to the place 435 that it had just come from. This would work for the types of loop 436 that form in symmetric cost networks, but would not suppress the 437 cyclic loops that form in asymmetric networks. 439 The problem with this class of micro-loop control strategies is 440 that whilst they prevent collateral damage they do nothing to 441 enhance the productive forwarding of packets during the network 442 transition. 444 6. Loop mitigation 446 The only known loop mitigation approach is described in [ZININ]. A 447 micro-loop free Next-hop safety condition is defined: 449 After a topology change, it is safe for router X to switch to 450 neighbor Y as its next-hop for a specific destination if the path 451 through Y satisfies both of the following criteria: 453 1. X considered Y as its loop-free neighbor based on the 454 topology before change AND 456 2. X considers Y as its downstream neighbor based on the 457 topology after change. 459 Based on this criteria, routers are then classified into three 460 classes: 462 Type A routers: Routers unaffected by the change and also routers 463 whose next hop after the change satisfies the safety criteria. 465 Type B routers: Routers whose new primary next-hops after the 466 topology change do not satisfy the safety condition, but that have 467 at least one other neighbor that does. 469 Type C routers: All other routers. 471 Following a topology change, Type A routers immediately change to 472 the new topology. Type B routers immediately change to the next hop 473 that satisfies the safety criteria, even though this is not the 474 shortest path. Type B routers continue to use this path until all 475 Type C routers have switched to their new next hop. Type C routers 476 wait for the Type B routers to switch to their intermediate (safe) 477 next hop, and then change to their new next hop. 479 Simulations indicate that this approach produces a significant 480 reduction in the number of links that are subject to micro-looping. 481 However unlike all of the micro-loop prevention methods it is only 482 a partial solution. In particular, micro-loops may form on any link 483 joining a pair of type C routers. 485 Although type C routers delay their FIB update, they will however 486 route towards the failure during the time when the type B routers 487 are changing, and hence will continue to productively forward 488 packets provided that viable repair paths exist. 490 A backwards compatibility issue arises with the safe-next-hop 491 scheme. If a router is not capable of micro-loop control, it will 492 not correctly delay it's FIB update. If all such routers were type 493 A routers this loop migration mechanism would work as it was 494 designed. Alternatively, if all such incapable were type C routers, 495 the "covert" announcement mechanism used to trigger the tunnel 496 based schemes could be used to cause the A and B routers to 497 configure themselves, with the incapable and type C routers 498 delaying until they received the "real" announcement. 499 Unfortunately, these two approaches are mutually incompatible. 501 It should be noted that the classification of a router as type A, B 502 or C is a per-destination classification. Routers update their FIBs 503 in three phases. A router first updates destinations for which it 504 is classified as type A or type B, it then updates destinations for 505 which it is type C, and finally it corrects the temporary next hop 506 used for destinations for which it is type B. 508 7. Compatibility Issues 510 Deployment of any micro-loop control mechanism is a major change to 511 a network. Full consideration must be given to interoperation 512 between routers that are capable of micro-loop control, and those 513 that are not. Additionally there may be a desire to limit the 514 complexity of micro-loop control by choosing a method based purely 515 on its simplicity. Any such decision must take into account that if 516 a more capable scheme is needed in the future, its deployment will 517 be complicated by interaction with the scheme previously deployed. 519 8. IANA considerations 521 There are no IANA considerations that arise from this draft. 523 9. Security Considerations 525 All micro-loop control mechanisms raise significant security issues 526 which must be addressed in their detailed technical description. 528 10. Intellectual Property Statement 530 The IETF takes no position regarding the validity or scope of any 531 Intellectual Property Rights or other rights that might be claimed 532 to pertain to the implementation or use of the technology described 533 in this document or the extent to which any license under such 534 rights might or might not be available; nor does it represent that 535 it has made any independent effort to identify any such rights. 536 Information on the procedures with respect to rights in RFC 537 documents can be found in BCP 78 and BCP 79. 539 Copies of IPR disclosures made to the IETF Secretariat and any 540 assurances of licenses to be made available, or the result of an 541 attempt made to obtain a general license or permission for the use 542 of such proprietary rights by implementers or users of this 543 specification can be obtained from the IETF on-line IPR repository 544 at http://www.ietf.org/ipr. 546 The IETF invites any interested party to bring to its attention any 547 copyrights, patents or patent applications, or other proprietary 548 rights that may cover technology that may be required to implement 549 this standard. Please address the information to the IETF at 550 ietf-ipr@ietf.org. 552 11. Full copyright statement 554 Copyright (C) The Internet Society (2004). This document is subject 555 to the rights, licenses and restrictions contained in BCP 78, and 556 except as set forth therein, the authors retain all their rights. 558 This document and the information contained herein are provided on 559 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 560 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 561 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 562 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 563 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 564 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 565 PARTICULAR PURPOSE. 567 12. Normative References 569 There are no normative references. 571 13. Informative References 573 Internet-drafts are works in progress available from 574 576 [IPFRR] Shand, M., "IP Fast-reroute Framework", 577 , June 578 2004, (work in progress). 580 [LDP] Andersson, L., Doolan, P., Feldman, N., 581 Fredette, A. and B. Thomas, "LDP 582 Specification", RFC 3036, 583 January 2001. 585 MPLS-TE] Ping Pan, et al, "Fast Reroute Extensions to 586 RSVP-TE for LSP Tunnels", 587 , 588 (work in progress). 590 [TUNNEL] Bryant, S., Shand, M., "IP Fast Reroute using 591 tunnels", , 592 May 2004 (work in progress). 594 [ZININ] Zinin, A., "Analysis and Minimization of 595 Microloops in Link-state Routing Protocols", 596 , 597 October 2004 (work in progress). 599 14. Authors' Addresses 601 Mike Shand 602 Cisco Systems, 603 250, Longwater, 604 Green Park, 605 Reading, RG2 6GB, 606 United Kingdom. Email: mshand@cisco.com 608 Stewart Bryant 609 Cisco Systems, 610 250, Longwater, 611 Green Park, 612 Reading, RG2 6GB, 613 United Kingdom. Email: stbryant@cisco.com