idnits 2.17.1 draft-zinin-microloop-analysis-01.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 3979, Section 5, paragraph 1 on line 642. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 655. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** 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 14 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 15 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 187: '... Routers SHOULD use the symmetric-li...' RFC 2119 keyword, line 188: '... MAY attempt to dynamically determin...' RFC 2119 keyword, line 190: '... protocol, and SHOULD provide the ad...' RFC 2119 keyword, line 255: '... The route SHALL be updated with...' RFC 2119 keyword, line 259: '...delay, the route SHALL be updated with...' (11 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (May 2005) is 6919 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'ISIS' == Outdated reference: A later version (-12) exists of draft-ietf-rtgwg-ipfrr-spec-base-03 Summary: 10 errors (**), 0 flaws (~~), 5 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Alex Zinin 3 Internet Draft Alcatel 4 Expiration Date: November 2005 May 2005 5 File name: draft-zinin-microloop-analysis-01.txt 7 Analysis and Minimization of Microloops in 8 Link-state Routing Protocols 10 draft-zinin-microloop-analysis-01.txt 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 other 21 groups may also distribute working documents as Internet Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than a "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Abstract 36 Link-state routing protocols (e.g. OSPF or IS-IS) are known to 37 converge to a loop-free state within a finite period of time after a 38 change in the topology. It is normal, however, to observe short-term 39 loops during the period of topology update propagation, route 40 recalculation, and forwarding table update, due to the asynchronous 41 nature of link-state protocol operation. This document provides an 42 analysis of formation of such microloops and suggests simple 43 mechanisms to minimize them. 45 1 Introduction 47 Link-state routing protocols, such as [OSPF] and [ISIS] converge to a 48 loop-free state within a finite period of time after a topology 49 change. Additional changes postpone the convergence, but do not get 50 in its way. 52 During the period of convergence, however, link-state protocols 53 exhibit short-term routing table inconsistencies caused by the 54 protocol's asynchronous nature. These incornsistencies may cause 55 short-term packet loops, also known as microloops. For example, see a 56 sample network in Figure 1. 58 +--+ 1 +--+ 59 |A |---------|B | 60 +--+ +--+ 61 | \ 10 | 62 5| ------ |1 63 | \ | 64 +--+ 10 \+--+ 65 |E |---------|C | 66 +--+ +--+ 67 \_ / 68 5 \ /1 (failure) 69 +--+ 70 |D | 71 +--+ 73 Figure 1. Microloop example 75 We are interested in routers A and B and their best paths towards D. 76 Before failure, B's best path to D is B-C-D with cost 2, and A's best 77 path is A-B-C-D with cost 3. When link C-D fails, both C and D 78 announce their link state information with link C-D missing. Within a 79 finite period of time, both A and B shall receive the topology 80 updates and converge on them, installing new best paths: A-E-D (10) 81 for A, and B-A-E-D (11) for B. However, if, due to the timing 82 differences, B calculates and installs its new best path through A 83 before A has a chance to switch from B to E, a microloop will form 84 between A and B for the duration of time required for A to complete 85 its routing table update. 87 Similar microloops may form when other topological changes happen in 88 the network, for example, when a new link or a node is added, a link 89 cost is changed, etc. In summary, whenever a topological change in 90 the network results in changes of the shortest path three (SPT) for 91 more than one node, it is possible for the network to exhibit 92 temporary loops. 94 This document provides an analysis of microloop formation. 95 Specifically, we categorize different types of reconvergence 96 scenarios, and explore their properties. We then show that in certain 97 scenaiors microloops do not form, in others they can be eliminated 98 using simple techniques described in this document, and define 99 scenarios where more sophisticated loop avoidance mechanisms may be 100 necessary. 102 2 Analysis 104 To analyse the behavior of a network during reconvergence, we look at 105 a given router and its neighbors before failure and during the 106 transition to the new routes. More specifically, we analyse whether 107 switching to the new routing information can result in loop formation 108 or not. 110 2.1 Terminology 112 The following terms are used in the draft. 114 Downstream neighbor 115 Neighbor N of router S is considered S's downstream neighbor 116 for destination D, if Dopt(N, D) < Dopt(S, D) 118 Primary neighbor 119 Neighbor N of router S is considered S's primary neighbor for 120 destination D, if N provides the shortest path to D according 121 to the SPF calculation. 123 Loop-free neighbor 124 Neighbor N of router S is considered S's loop-free neighbor 125 for destination D, if Dopt(N, D) < Dopt(N, S) + Dopt(S, D). 126 Note that a loop-free neighbor may be, for example, router's 127 primary before or after failure. 129 2.2 Next hop safety condition 131 We start the analysis with the following observation: 133 When router X learns about a topology change and starts using 134 neighbor Y as its new primary neighbor for a given destination, a 135 microloop between X and Y can only form if the topology before 136 failure or topology after failure are such that Y uses X as its 137 primary neighbor for the same destination. 139 Indeed, if the topologies before and after failure are such that Y 140 does not use X as it's next hop, then there is no moment in time 141 before Y learned about the failure or after it learned about it 142 when it would forward traffic to X. Hence, at least one of the two 143 topologies must be such that Y uses X as its next hop for a 144 microloop between X and Y to form. 146 Based on the above, we can define a safety condition for neighbor Y 147 of router X that has just learned about a topology change. Note that 148 the condition must satisfy the topological criteria above, and be 149 non-recursive, i.e. not lead to loops if both X and Y follow it. 151 Next-hop safety condition: 153 For networks with symmetric link costs, after a topology 154 change, it is safe for router X to switch to neigbor Y as its 155 next-hop for a specific destination if the path through Y sat- 156 isfies both of the following criteria: 158 1. X considered Y as its loop-free neighbor based on the 159 topology before change AND 161 2: X considers Y as its downstream neighbor based on the 162 topology after change. 164 The first requirement ensures that Y has not been forwarding 165 traffic to X before the change occured and both X and Y used 166 old topology. The second requirement makes sure Y does not 167 forward traffic to X when Y learns the new topology. 169 The difference in the conditions before and after failure is 170 there to make sure that X and Y do not recursively consider 171 each other as safe next-hops when they learn about the fail- 172 ure. 174 For networks with asymmetric link costs, the safety condition is mod- 175 ified as follows: 177 Y is X's downstream neighbor based on the topology both before 178 AND after the change. 180 Whether a given router uses a the safety condition for symmetric or 181 assymetric link costs will affect micro-loop coverage. Generally, the 182 stricter condition for asymmetric link costs will result in poorer 183 coverage, however using the less strict (symmetric-link) condition in 184 networks with asymmetric link costs may result in transformation of 185 single-hop loops into multi-hop ones rather than their removal. 187 Routers SHOULD use the symmetric-link safety condition by default, 188 MAY attempt to dynamically determine the method that needs to be 189 applied based on the topological information from the routing 190 protocol, and SHOULD provide the administrator an opportunity to man- 191 ually override this setting. 193 2.3 Transition types 195 Here, we analyse different types of scenarios that a given router may 196 find itself in after learning about a topology change. 198 For each topological change, the network will have three major types 199 of nodes categorized by the degree of safety of their old primary, 200 new primary, and other neighbors. 202 Type A 204 Routers whose new primary next-hops after the topology change 205 are safe and transition to them will not create a microloop. 206 Two subtypes are recognized: 208 A1: Routers whose primaries haven't changed as a result of 209 the topology change 211 A2: Routers whose new primary satisfies the safety condition 213 Type B 215 Routers whose new primary next-hops after the topology change 216 do not satisfy the safety condition, but that have at least 217 one other neighbor that does. Note that such a neighbor can be 218 the router's old primary (type B1) or a neighbor that is nei- 219 ther old nor new primary (type B2). 221 Type C 223 Routers that have no neighbor that satisfies the safety condi- 224 tion. 226 It is clear that type-A routers can immediately switch to their new 227 primary next hops once they are calculated after the topology change. 229 It can also be shown that if type-B routers do not immediately switch 230 to their new primaries, but use their safe next-hops for some time, 231 switching to the new primaries later will not create loops, provided 232 that their downstream routers have also switched to the safe hops or 233 have already switched to the new primaries. 235 The following section formally defines the mechanism. 237 3. Loop prevention mechanism 239 3.1 Basic procedures 241 For a description of several architectural constants used in this 242 document (named as "DELAY_xxx"), refer to section 3.4. 244 On receiving a topology update, the router delays its SPF calculation 245 by DELAY_SPF time in order to collect the remaining updates that 246 relate to the same topological event (e.g. update from the router 247 connected to the second end of a point-to-point link). 249 Upon expiration of DELAY_SPF, the router calculates the new SPT, the 250 new routes, checks the safety status of each neighbor using the con- 251 ditions in section 3.1, and applies the following logic for each 252 route depending on the type of role it finds itself in: 254 Type A: 255 The route SHALL be updated with the new primary next-hops 256 without an additional delay. 258 Type B: 259 Without an additional delay, the route SHALL be updated with 260 one or more temporary next-hops that satisfy the safety condi- 261 tion. These temporary next-hops SHALL be used for the duration 262 of DELAY_TYPEB. After DELAY_TYPEB, the route SHALL be updated 263 with the new primary next-hops. 265 Type C: 266 The route's old (primary) next-hops SHALL continue to be used 267 for DELAY_TYPEC. After DELAY_TYPEC, the route SHALL be 268 updated with the new primary next-hops. 270 If, after expiration of DELAY_SPF, the router receives a topology 271 update sooner than DELAY_STABLE after the previous one, the router 272 MUST fall back to the regular convergence mechanisms (immediate 273 installation of the new primary next-hops) aborting any transition 274 processes initiated as part of procedures described here (i.e., if 275 DELAY_TYPEB or DELAY_TYPEC timers are still running), MUST recalcu- 276 late its routing table as soon as practical, and MUST refrain from 277 using the mechanisms described here until it has seen no topological 278 updates for at least DELAY_STABLE. This is a safeguard mechanism to 279 ensure that procedures described here are applied only when a single 280 failure is experienced and that the network converges in a situation 281 where multiple topological events or network instabilities are expe- 282 rienced. 284 3.2 Equal Cost Multipath Considerations 286 In situations where more than one primary next-hop is available after 287 the topology change, there are several possible combination of their 288 safety properties: 290 1) All new next-hops satisfy the safery condition (a pure type-A 291 situation) 293 2) Some of the new next-hops satisfy the safety condition, some 294 of them do not (a combination of type-A and type-B, or type-A 295 and type-C) 297 3) None of the new next-hops satisfy the safety condition, how- 298 ever, there's at least one other neighbor that satisfies it (a 299 type-B situation) 301 4) None of the new next-hops satisfy the safety condition, and 302 there is no other neighbor that satisfies it (a pure type-C 303 situation). 304 For situations 1, 3, and 4 above, the implementation merely follows 305 the basic procedures described in section 3.1 307 For situation 2 (an A/B or an A/C combination), the implementation: 309 1) SHALL update the route with the new next-hops that satisfy the 310 safety condition without an additional delay 312 2) SHALL add the remaining new next-hops after DELAY_TYPEB. 314 3.3 IP Fast Reroute Considerations 316 If the router implements [IPFRR] and performs local failure repair, 317 procedures describes in this document still need to be applied in 318 order to prevent micro-loops while reconverging on the new topology. 320 After initiating the local repair, the router directly attached to 321 the point of failure follows the procedures described in this docu- 322 ment--it delays its SPF calculation to collect updates from other 323 routers, calculates new routes, and classifies the next-hops. 325 The difference with routers that learn about the failure from the 326 routing protocol updates, is that one or more of the repairing 327 router's old next-hops has become unavailable, and hence cannot be 328 considered as the temporary safe next-hops for type-B operation. 329 Also, if the router was able to locally repair the failure, and the 330 new primary next-hops do not satisfy the safety condition, the router 331 should consider itself in the middle of type-B operation with the 332 temporary safe neighbor engaged as part of IP Fast Reroute operation. 334 Another difference is when the router could not repair the failure, 335 the new primary next-hops do not satisfy the safety condition, and 336 there's no other neighbor that does, i.e. a type-C situation. Unlike 337 other routers in the network, the router directly connected to the 338 network does not have the old next-hop any more, and cannot continue 339 using it. In this situation, the router MUST revert to the regular 340 convergence procedures, and update the route with the new next-hops 341 with no additional delay. 343 As a result, there are the following possible scenarios: 345 1) If the new primary next-hops satisfy the safery condition, the 346 router updates the routes without an additional delay. 348 2) Otherwise, if the failure could be repaired locally by IP Fast 349 Reroute, the router continues to use the repair path for 350 DELAY_TYPEB and updates the routes with the new primary next- 351 hops after it expires. 353 3) Otherwise (new next-hops are not safe, and failure couldn't be 354 repaired), the router reverts to the regular procedures and 355 updates the route with new next-hops without an additional 356 delay. 358 3.4 Architectural Constants 360 The following architectural constants have been used in the descrip- 361 tion of the algorithm above: 363 DELAY_SPF 364 The delay between the moment the router receives a topology 365 update after a period of stability and the moment it starts 366 its routing table recalculation. This delay is necessary to 367 collect multiple updates originated by different routers that 368 relate to the same topological event. 370 DELAY_STABLE 371 Period of time, during which the network topology is consid- 372 ered to be stable if the router receives no topological 373 updates. When the first update after DELAY_STABLE is received, 374 all other updates that fit within DELAY_SPF are considered as 375 related to a single topological event. 377 DELAY_TYPEB and DELAY_TYPEC 378 Periods of time used by the router to delay installation of 379 new primary next-hops after a topology change when the router 380 has (type-B) or has not (type-C) a safe neighbor to temporary 381 divert the traffic to in the meantime. 383 While correctness and effectiveness of the algorithm described here 384 does not depend on the actual values assigned to the architectural 385 constants, it does depend on the relationship between them, and the 386 assumption that all routers in the same network use the same values. 388 To satisfy these constrains, and yet allow these delays to be 389 decreased as implementations continue to improve towards faster con- 390 vergence, this document defines the architectural constants as con- 391 figurable, specifies the required relationship between the values, 392 and the default values that should be used by the implementations. 394 The following equations define the relationship between the constants 395 that needs to be maintained in order for the mechanism described here 396 to provide desireable results: 398 DELAY_SPF > update-propagation-time 400 DELAY_STABLE > DELAY_TYPEB > DELAY_TYPEC > fault-propagation-time 402 where: 404 o update-propagation-time is the time it is expected to take 405 routers in the network to detect the failure, and originate 406 and propagate new link-state information. 408 o fault-propagation-time is update-propagation plus the time it 409 is expected to take routers in the network to calculate the 410 new SPT, check the safety condition of the neighbors, and 411 install required FIB entries. 413 Because fault-propagation-time includes update-propagation-time, and 414 DELAY_SPF (since every router will delay its SPF according to this 415 document): 417 fault-propagation-time > DELAY_SPF + update-propagation-time 419 and hence the equations above can be converted to one: 421 DELAY_STABLE > DELAY_TYPEB > DELAY_TYPEC > (DELAY_SPF + update-prop- 422 agation-time) 423 The implementations SHOULD use the following default values for the 424 architectural constants: 426 Constant Default val 427 ---------------------------------------- 428 DELAY_SPF 500 msec 429 DELAY_TYPEC 2 sec 430 DELAY_TYPEB 4 sec 431 DELAY_STABLE 10 sec 433 4 Coverage analysis 435 The above algorithm minimizes the probability of loop formation. More 436 specifically, loops will only be possible when two neighboring 437 routers both experience the type C condition after the topology 438 change. Appendix A shows that transitions between A-A, A-B, A-C, and 439 B-C routers are loop-free. 441 While this mechanism does not remove all possible micro-loops, it 442 addresses the majority of them in topologies with a reasonable level 443 of physical redundancy. Topologically, micro-loop coverage provided 444 by this algorithm is 446 5 Security Considerations 448 The mechanism described in this document does not modify any routing 449 protocol messages, and hence no new threats related to packet modifi- 450 cations or replay attacks are introduced. The mechanism changes cer- 451 tain delays used in node-local algorithms and introduces partial 452 event ordering after a topology change has occured. This, however, 453 does not introduce new security risks. For type-B situations, traffic 454 to certain destinations can be temporarily routed via next-hop 455 routers that would not be used with the same topology change if this 456 mechanism wasn't employed. However, these next-hop routers can be 457 used anyway when a different topological change occurs, and hence 458 this can't be viewed as a new security threat. 460 Acknowledgements 462 The author would like to thank Don Fedyk, Chris Martin, Mike Shand, 463 Alex Audu, Olivier Bonaventure, Stefano Previdi, and other members of 464 the IETF RTGWG for their useful comments. Special thanks go to Alia 465 Atlas who, among other things, was instrumental in fine-tuning the 466 safety condition. 468 References 470 [OSPF] J. Moy. OSPF version 2. Technical Report RFC 2328, Internet 471 Engineering Task Force, 1998. 473 [ISIS] ISO, "Intermediate system to Intermediate system routeing 474 information exchange protocol for use in conjunction with the 475 Protocol for providing the Connectionless-mode Network Service 476 (ISO 8473)," ISO/IEC 10589:1992. 478 [IPFRR] Atlas, A., "Basic Specification for IP Fast-Reroute: 479 Loop-free Alternates", Internet Engineering Task Force, Work 480 in Progress, draft-ietf-rtgwg-ipfrr-spec-base-03.txt 482 Author's Address 484 Alex Zinin 485 Alcatel 486 701 E Middlefield Rd 487 Mountain View, CA 94043 488 E-mail: zinin@psg.com 490 Appendix A. Loop formation analysis 492 S is the calculating router discovering the failure through a link-state 493 update. P is the old primary, NP is the new primary. 495 BF: 496 <------ 497 [P]----------------[S]----------------[NP] 498 ...>? 500 AF: 502 ------> 503 [P]----------------[S]----------------[NP] 504 ?<... 506 To analyze possible loop formation, we need to check the following: 508 1) if it is possible for P to start forwarding packets to S 509 before S switches to NP 511 2) if it is possible for NP to be forwarding packets back to S 512 before or after S starts using it 514 Assumptions are that type-As switch-over to NP immediately, and type- 515 Bs and type-Cs wait certain amount of time so that: 517 DELAY_TYPEB > DELAY_TYPEC > fault-propagation-time 519 1. S is type A: 521 BF analysis: 523 1.1 If P is another type-A, then S cannot be its new primary, since 524 S has not been P's LFA before (since it's been fwd'ing through P). 525 Hence, P will not route through S AF, and the will be no loops 526 between P and S. 528 1.2 If P is a type-B, then S hasn't been P's LF neighbor BF, and P 529 will not forward through S at least for DELAY_TYPEB, which gives S 530 enough time to switch to NP. After DELAY_TYPEB P may start using S 531 as it's new primary. 533 1.3 If P is a type-C, then it hasn't been forwarding traffic to S 534 BF, and will not use S as its new primary at least for DELAY_TYPEC, 535 which should give S enough time to switch to NP. 537 1.4 Consequently, no loops will form between a type-A node and it's 538 old primary before the type-A nodes switches to its new primary. 540 AF analysis: 542 1.5 Regardless of its type, NP has not been forwarding packets to S 543 BF and will not do so AF by definition of type-A. 545 1.6 Consequently, no loops will form between a type-A node and it's 546 new primary before or after the type-A nodes switches to it. 548 2. S is type B: 550 BF analysis: 552 2.1 If P is a type-A, then similarly to 1.1 above, there will be no 553 routes between P and S. 555 2.2 If P is another type-B, then similarly to 1.2, S will not be 556 used by P for at least DELAY_TYPEB, and S will have enough time to 557 switch to its safe hops or NP. 559 2.3 If P is a type-C, then similarly to 1.3, S hasn't been receiv- 560 ing traffic from P BF, and will not AF for at least DELAY_TYPEC, 561 which should give S enough time to switch to its safe hops or NP. 563 2.4 Consequently, no loops will form between a type-B node and it's 564 old primary before the type-B nodes switches to its new primary. 566 AF analysis: 568 2.5 If NP is a type-A, then because of the DELAY_TYPEB NP must have 569 had enough time to switch to its new NP, which cannot be S by defi- 570 nition of SPT considering that NP is S's new nexthop in the SPT AF. 572 2.6 If NP is another type-B, then because of DELAY_TYPEB, NP must 573 have had enough time to switch from its old primary and can equally 574 likely be routing through either its safe hops, or its new primary. 575 Neither of the two can be S by definition of a downstream node (for 576 safe hops) and SPT (for new primary). 578 2.7 If NP is a type-C, then because DELAY_TYPEB > DELAY_TYPEC, NP 579 must have had enough time to switch to its new primary, which can't 580 be S by definition of SPT and considering that NP is S's nexthop in 581 the SPT AF. 583 2.8 Consequently, no loops will form between a type-B node and it's 584 new primary before or after the type-A nodes switches to it. 586 3. S is type C: 588 BF analysis: 590 3.1 If P is a type-A, then similarly to 1.1 before, S has not been 591 P's LF neighbor before and hence won't be its new primary, so no 592 loops will form between P and S. 594 3.2 If P is a type-B, then similarly to 1.2, S will not be used by 595 P for at least DELAY_TYPEB, and because DELAY_TYPEB > DELAY_TYPEC, 596 S will have enough time to switch to NP. 598 3.3 If P is another type-C, then it hasn't been using S as its pri- 599 mary BF, but it is possible for P to consider S as its new primary 600 AF and to install routes before S after their DELAY_TYPEC expires. 601 Hence, a microloop is possible between P and S. 603 3.4 Consequently, a microloop between a type-C node and its old 604 primary is possible only if the old primary is also a type-C node 605 and it considers S as its new primary AF. Note that DELAY_TYPEC 606 only delays probably loop formation, but does not increase its 607 duration, as both neighboring routers are using the same delay. 609 AF analysis: 611 3.5 If NP is a type-A, then because of the DELAY_TYPEC NP must have 612 had enough time to switch to its new NP, which cannot be S by defi- 613 nition of SPT considering that NP is S's new nexthop in the SPT AF. 615 3.6 If NP is a type-B, then because of DELAY_TYPEC, NP must have 616 had enough time to switch to its safe hops, which can't be S by 617 definition of a downstream node and considering that NP is S's new 618 SPT next-hop. 620 3.7 If NP is another type-C, a loop is possible if S's DELAY_TYPEC 621 expires before that on NP and NP has been using S as its primary 622 BF. 624 3.8 Consequently, a microloop between a type-C node and its new 625 primary is possible only if the new primary is also a type-C node 626 and S was NP's primary BF. 628 4. Given the above analysis, it can be noted that, for a given fail- 629 ure, presence of single type-C nodes in the network does not create 630 microloops. 631 It is the C-C combination that introduces this potential. 633 IPR Disclaimer 635 The IETF takes no position regarding the validity or scope of any 636 Intellectual Property Rights or other rights that might be claimed to 637 pertain to the implementation or use of the technology described in 638 this document or the extent to which any license under such rights 639 might or might not be available; nor does it represent that it has 640 made any independent effort to identify any such rights. Information 641 on the procedures with respect to rights in RFC documents can be 642 found in BCP 78 and BCP 79. 644 Copies of IPR disclosures made to the IETF Secretariat and any assur- 645 ances of licenses to be made available, or the result of an attempt 646 made to obtain a general license or permission for the use of such 647 proprietary rights by implementers or users of this specification can 648 be obtained from the IETF on-line IPR repository at 649 http://www.ietf.org/ipr. 651 The IETF invites any interested party to bring to its attention any 652 copyrights, patents or patent applications, or other proprietary 653 rights that may cover technology that may be required to implement 654 this standard. Please address the information to the IETF at ietf- 655 ipr@ietf.org. 657 Full Copyright Statement 658 Copyright (C) The Internet Society (2005). This document is subject 659 to the rights, licenses and restrictions contained in BCP 78, and 660 except as set forth therein, the authors retain all their rights. 662 This document and the information contained herein are provided on an 663 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 664 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 665 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 666 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFOR- 667 MATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES 668 OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.