idnits 2.17.00 (12 Aug 2021) /tmp/idnits41295/draft-ietf-rtgwg-spf-uloop-pb-statement-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (January 16, 2019) is 1214 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Routing Area Working Group S. Litkowski 3 Internet-Draft Orange Business Service 4 Intended status: Informational B. Decraene 5 Expires: July 20, 2019 Orange 6 M. Horneffer 7 Deutsche Telekom 8 January 16, 2019 10 Link State protocols SPF trigger and delay algorithm impact on IGP 11 micro-loops 12 draft-ietf-rtgwg-spf-uloop-pb-statement-10 14 Abstract 16 A micro-loop is a packet forwarding loop that may occur transiently 17 among two or more routers in a hop-by-hop packet forwarding paradigm. 19 In this document, we are trying to analyze the impact of using 20 different Link State IGP (Interior Gateway Protocol) implementations 21 in a single network, with respect to micro-loops. The analysis is 22 focused on the SPF (Shortest Path First) delay algorithm. 24 Requirements Language 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 27 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 28 "OPTIONAL" in this document are to be interpreted as described in BCP 29 14 [RFC2119] [RFC8174] when, and only when, they appear in all 30 capitals, as shown here. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on July 20, 2019. 49 Copyright Notice 51 Copyright (c) 2019 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Problem statement . . . . . . . . . . . . . . . . . . . . . . 4 68 3. SPF trigger strategies . . . . . . . . . . . . . . . . . . . 5 69 4. SPF delay strategies . . . . . . . . . . . . . . . . . . . . 6 70 4.1. Two steps SPF delay . . . . . . . . . . . . . . . . . . . 6 71 4.2. Exponential backoff . . . . . . . . . . . . . . . . . . . 7 72 5. Mixing strategies . . . . . . . . . . . . . . . . . . . . . . 8 73 6. Benefits of standardized SPF delay behavior . . . . . . . . . 12 74 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 75 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 76 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 77 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 78 10.1. Normative References . . . . . . . . . . . . . . . . . . 14 79 10.2. Informative References . . . . . . . . . . . . . . . . . 14 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 82 1. Introduction 84 Link State IGP protocols are based on a topology database on which 85 the SPF algorithm is run to find a consistent set of non-looping 86 routing paths. 88 Specifications like IS-IS ([RFC1195]) propose some optimizations of 89 the route computation (See Appendix C.1 of [RFC1195]) but not all the 90 implementations follow those non-mandatory optimizations. 92 We will call "SPF triggers", the events that would lead to a new SPF 93 computation based on the topology. 95 Link State IGP protocols, like OSPF ([RFC2328]) and IS-IS 96 ([RFC1195]), are using multiple timers to control the router behavior 97 in case of churn: SPF delay, PRC (Partial Route Computation) delay, 98 LSP (Link State Packet) generation delay, LSP flooding delay, LSP 99 retransmission interval... 101 Some of those timers (values and behavior) are standardized in 102 protocol specifications, while some are not. The SPF computation 103 related timers have generally remained unspecified. 105 For non standardized timers, implementations are free to implement 106 them in any way. For some standardized timers, we can also see that 107 rather than using static configurable values for such timer, 108 implementations may offer dynamically adjusted timers to help control 109 the churn. 111 We will call "SPF delay", the timer that exists in most 112 implementations that specifies the required delay before running SPF 113 computation after a SPF trigger is received. 115 A micro-loop is a packet forwarding loop that may occur transiently 116 among two or more routers in a hop-by-hop packet forwarding paradigm. 117 We can observe that these micro-loops are formed when two routers do 118 not update their Forwarding Information Base (FIB) for a certain 119 prefix at the same time. The micro-loop phenomenon is described in 120 [I-D.ietf-rtgwg-microloop-analysis]. 122 Two micro-loop mitigation techniques have been defined by IETF. 123 [RFC6976] has not been widely implemented, presumably due to the 124 complexity of the technique. [RFC8333] has been implemented. 125 However, it does not prevent all micro-loops that can occur for a 126 given topology and failure scenario. 128 In multi-vendor networks, using different implementations of a link 129 state protocol may favor micro-loops creation during the convergence 130 process due to discrepancies of timers. Service Providers are 131 already aware to use similar timers (values and behavior) for all the 132 network as a best practice, but sometimes it is not possible due to 133 limitations of implementations. 135 This document will present reasons for service providers to have 136 consistent implementations of Link State protocols across vendors. 137 We are particularly analyzing the impact of using different Link 138 State IGP implementations in a single network in regards of micro- 139 loops. The analysis is focused on the SPF delay algorithm. 141 [RFC8405] defines a solution that partially addresses this problem 142 statement and this document captures the reasoning of the provided 143 solution. 145 2. Problem statement 147 S ---- E 148 | | 149 10 | | 10 150 | | 151 D ---- A 152 | 2 153 Px 155 Figure 1 - Network topology suffering from micro-loops 157 Figure 1 represents a small network composed of four routers (S,D,E 158 and A).Router S uses primarily the SD link to reach the prefixes 159 behind router D (named Px). When the SD link fails, the IGP 160 convergence occurs. If S converges before E, S will forward the 161 traffic to Px through E, but as E has not converged yet, E will loop 162 back traffic to S, leading to a micro-loop. 164 The micro-loop appears due to the asynchronous convergence of nodes 165 in a network when an event occurs. 167 Multiple factors (or a combination of these factors) may increase the 168 probability for a micro-loop to appear: 170 o the delay of failure notification: the greater the time gap 171 between E and S being advised of the failure, the more a micro- 172 loop may have a chance to appear. 174 o the SPF delay: most implementations support a delay for the SPF 175 computation to try to catch as many events as possible. If S uses 176 an SPF delay timer of x msec and E uses an SPF delay timer of y 177 msec and x < y, E would start converging after S leading to a 178 potential micro-loop. 180 o the SPF computation time: mostly a matter of CPU power and 181 optimizations like incremental SPF. If S computes its SPF faster 182 than E, there is a chance for a micro-loop to appear. CPUs are 183 today fast enough to consider SPF computation time as negligible 184 (on the order of milliseconds in a large network). 186 o the SPF computation ordering: an SPF trigger can be common to 187 multiple IGP areas or levels (e.g., IS-IS Level1/Level2) or for 188 multiple address families with multi-topologies. There is no 189 specified order for SPF computation today and it is implementation 190 dependent. In such scenarios, if the order of SPF computation 191 done in S and E for each area/level/topology/SPF-algorithm is 192 different, there is a possibility for a micro-loop to appear. 194 o the RIB and FIB prefix insertion speed or ordering. This is 195 highly dependent on the implementation. 197 Even if all of these factors may increase the probability for a 198 micro-loop to appear, the SPF delay, especially in case of churn, 199 plays a significant role. As the number of IGP events increase, the 200 delta between SPF delay values used by routers becomes significant 201 and the dominating factor (especially when one router increases its 202 timer exponentially while another one increases it in a more smoother 203 way). Another important factor is the time to update the FIB. As of 204 today, total FIB update time is the major factor for IGP convergence. 205 However, for micro-loops, what matters is not the total time, but the 206 difference to install the same prefix between nodes. The time to 207 update the FIB may be the main part for the first iteration but is 208 not for subsequent IGP events. In addition, the time to update the 209 FIB is very implementation specific and difficult/impossible to 210 standardize, while the SPF delay algorithm may be standardized. 212 As a consequence, this document will focus on the analysis of the SPF 213 delay behavior and associated triggers. 215 3. SPF trigger strategies 217 Depending on the change advertised in LSPDU (Link State Protocol Data 218 Unit) or LSA (Link State Advertisement), the topology may be affected 219 or not. An implementation may avoid running the SPF computation (and 220 may only run an IP reachability computation instead) if the 221 advertised change does not affect the topology. 223 Different strategies exists to trigger the SPF computation: 225 1. An implementation may always run a full SPF for any type of 226 change. 228 2. An implementation may run a full SPF only when required. For 229 example, if a link fails, a local node will run an SPF for its 230 local LSP update. If the LSP from the neighbor (describing the 231 same failure) is received after SPF has started, the local node 232 can decide that a new full SPF is not required as the topology 233 has not changed. 235 3. If the topology does not change, an implementation may only 236 recompute the IP reachability. 238 As noted in Section 1, SPF optimizations are not mandatory in 239 specifications. This has led to the implementation of different 240 strategies. 242 4. SPF delay strategies 244 Implementations of link state routing protocols use different 245 strategies to delay the SPF computation. The two most common SPF 246 delay behaviors are the following: 248 1. Two phase SPF delay. 250 2. Exponential backoff delay. 252 These behaviors will be explained in the next sections. 254 4.1. Two steps SPF delay 256 The SPF delay is managed by four parameters: 258 o Rapid delay: amount of time to wait before running SPF, after the 259 initial SPF trigger event. 261 o Rapid runs: the number of consecutive SPF runs that can use the 262 rapid delay. When the number is exceeded, the delay moves to the 263 slow delay value. 265 o Slow delay: amount of time to wait before running SPF. 267 o Wait time: amount of time to wait without receiving SPF trigger 268 events before going back to the rapid delay. 270 Example: Rapid delay (RD) = 50msec, Rapid runs = 3, Slow delay (SD) = 271 1sec, Wait time = 2sec 272 SPF delay time 273 ^ 274 | 275 | 276 SD- | x xx x 277 | 278 | 279 | 280 RD- | x x x x 281 | 282 +---------------------------------> Events 283 | | | | || | | 284 < wait time > 286 Figure 2 - Two phase delay algorithm 288 4.2. Exponential backoff 290 The algorithm has two modes: the fast mode and the backoff mode. In 291 the fast mode, the SPF delay is usually delayed by a very small 292 amount of time (fast reaction). When an SPF computation has run in 293 the fast mode, the algorithm automatically moves to the backoff mode 294 (a single SPF run is authorized in the fast mode). In the backoff 295 mode, the SPF delay is increasing exponentially at each run. When 296 the network becomes stable, the algorithm moves back to the fast 297 mode. The SPF delay is managed by four parameters: 299 o First delay: amount of time to wait before running SPF. This 300 delay is used only when SPF is in fast mode. 302 o Incremental delay: amount of time to wait before running SPF. 303 This delay is used only when SPF is in backoff mode and increments 304 exponentially at each SPF run. 306 o Maximum delay: maximum amount of time to wait before running SPF. 308 o Wait time: amount of time to wait without events before going back 309 to the fast mode. 311 Example: First delay (FD) = 50msec, Incremental delay (ID) = 50msec, 312 Maximum delay (MD) = 1sec, Wait time = 2sec 313 SPF delay time 314 ^ 315 MD- | xx x 316 | 317 | 318 | 319 | 320 | 321 | x 322 | 323 | 324 | 325 | x 326 | 327 FD- | x x x 328 ID | 329 +---------------------------------> Events 330 | | | | || | | 331 < wait time > 332 FM->BM -------------------->FM 334 Figure 3 - Exponential delay algorithm 336 5. Mixing strategies 338 In Figure 1, we consider a flow of packet from S to D. We consider 339 that S is using optimized SPF triggering (Full SPF is triggered only 340 when necessary), and two steps SPF delay (rapid=150ms,rapid-runs=3, 341 slow=1s). As implementation of S is optimized, Partial Reachability 342 Computation (PRC) is available. We consider the same timers as SPF 343 for delaying PRC. We consider that E is using a SPF trigger strategy 344 that always compute a Full SPF for any change, and uses the 345 exponential backoff strategy for SPF delay (start=150ms, inc=150ms, 346 max=1s) 348 We also consider the following sequence of events: 350 o t0=0 ms: a prefix is declared down in the network. We consider 351 this event to happen at time=0. 353 o 200ms: the prefix is declared as up. 355 o 400ms: a prefix is declared down in the network. 357 o 1000ms: S-D link fails. 359 +--------+--------------------+------------------+------------------+ 360 | Time | Network Event | Router S events | Router E events | 361 +--------+--------------------+------------------+------------------+ 362 | t0=0 | Prefix DOWN | | | 363 | 10ms | | Schedule PRC (in | Schedule SPF (in | 364 | | | 150ms) | 150ms) | 365 | | | | | 366 | | | | | 367 | 160ms | | PRC starts | SPF starts | 368 | 161ms | | PRC ends | | 369 | 162ms | | RIB/FIB starts | | 370 | 163ms | | | SPF ends | 371 | 164ms | | | RIB/FIB starts | 372 | 175ms | | RIB/FIB ends | | 373 | 178ms | | | RIB/FIB ends | 374 | | | | | 375 | 200ms | Prefix UP | | | 376 | 212ms | | Schedule PRC (in | | 377 | | | 150ms) | | 378 | 214ms | | | Schedule SPF (in | 379 | | | | 150ms) | 380 | | | | | 381 | | | | | 382 | 370ms | | PRC starts | | 383 | 372ms | | PRC ends | | 384 | 373ms | | | SPF starts | 385 | 373ms | | RIB/FIB starts | | 386 | 375ms | | | SPF ends | 387 | 376ms | | | RIB/FIB starts | 388 | 383ms | | RIB/FIB ends | | 389 | 385ms | | | RIB/FIB ends | 390 | | | | | 391 | 400ms | Prefix DOWN | | | 392 | 410ms | | Schedule PRC (in | Schedule SPF (in | 393 | | | 300ms) | 300ms) | 394 | | | | | 395 | | | | | 396 | | | | | 397 | | | | | 398 | 710ms | | PRC starts | SPF starts | 399 | 711ms | | PRC ends | | 400 | 712ms | | RIB/FIB starts | | 401 | 713ms | | | SPF ends | 402 | 714ms | | | RIB/FIB starts | 403 | 716ms | | RIB/FIB ends | RIB/FIB ends | 404 | | | | | 405 | 1000ms | S-D link DOWN | | | 406 | 1010ms | | Schedule SPF (in | Schedule SPF (in | 407 | | | 150ms) | 600ms) | 408 | | | | | 409 | | | | | 410 | 1160ms | | SPF starts | | 411 | 1161ms | | SPF ends | | 412 | 1162ms | Micro-loop may | RIB/FIB starts | | 413 | | start from here | | | 414 | 1175ms | | RIB/FIB ends | | 415 | | | | | 416 | | | | | 417 | | | | | 418 | | | | | 419 | 1612ms | | | SPF starts | 420 | 1615ms | | | SPF ends | 421 | 1616ms | | | RIB/FIB starts | 422 | 1626ms | Micro-loop ends | | RIB/FIB ends | 423 +--------+--------------------+------------------+------------------+ 425 Table 1 - Route computation when S and E use the different behaviors 426 and multiple events appear 428 In the Table 1, we can see that due to discrepancies in the SPF 429 management, after multiple events of a different type, the values of 430 the SPF delay are completely misaligned between node S and node E, 431 leading to the creation of micro-loops. 433 The same issue can also appear with only a single type of event as 434 shown below: 436 +--------+--------------------+------------------+------------------+ 437 | Time | Network Event | Router S events | Router E events | 438 +--------+--------------------+------------------+------------------+ 439 | t0=0 | Link DOWN | | | 440 | 10ms | | Schedule SPF (in | Schedule SPF (in | 441 | | | 150ms) | 150ms) | 442 | | | | | 443 | | | | | 444 | 160ms | | SPF starts | SPF starts | 445 | 161ms | | SPF ends | | 446 | 162ms | | RIB/FIB starts | | 447 | 163ms | | | SPF ends | 448 | 164ms | | | RIB/FIB starts | 449 | 175ms | | RIB/FIB ends | | 450 | 178ms | | | RIB/FIB ends | 451 | | | | | 452 | 200ms | Link DOWN | | | 453 | 212ms | | Schedule SPF (in | | 454 | | | 150ms) | | 455 | 214ms | | | Schedule SPF (in | 456 | | | | 150ms) | 457 | | | | | 458 | | | | | 459 | 370ms | | SPF starts | | 460 | 372ms | | SPF ends | | 461 | 373ms | | | SPF starts | 462 | 373ms | | RIB/FIB starts | | 463 | 375ms | | | SPF ends | 464 | 376ms | | | RIB/FIB starts | 465 | 383ms | | RIB/FIB ends | | 466 | 385ms | | | RIB/FIB ends | 467 | | | | | 468 | 400ms | Link DOWN | | | 469 | 410ms | | Schedule SPF (in | Schedule SPF (in | 470 | | | 150ms) | 300ms) | 471 | | | | | 472 | | | | | 473 | 560ms | | SPF starts | | 474 | 561ms | | SPF ends | | 475 | 562ms | Micro-loop may | RIB/FIB starts | | 476 | | start from here | | | 477 | 568ms | | RIB/FIB ends | | 478 | | | | | 479 | | | | | 480 | 710ms | | | SPF starts | 481 | 713ms | | | SPF ends | 482 | 714ms | | | RIB/FIB starts | 483 | 716ms | Micro-loop ends | | RIB/FIB ends | 484 | | | | | 485 | 1000ms | Link DOWN | | | 486 | 1010ms | | Schedule SPF (in | Schedule SPF (in | 487 | | | 1s) | 600ms) | 488 | | | | | 489 | | | | | 490 | | | | | 491 | | | | | 492 | 1612ms | | | SPF starts | 493 | 1615ms | | | SPF ends | 494 | 1616ms | Micro-loop may | | RIB/FIB starts | 495 | | start from here | | | 496 | 1626ms | | | RIB/FIB ends | 497 | | | | | 498 | | | | | 499 | | | | | 500 | | | | | 501 | 2012ms | | SPF starts | | 502 | 2014ms | | SPF ends | | 503 | 2015ms | | RIB/FIB starts | | 504 | 2025ms | Micro-loop ends | RIB/FIB ends | | 505 | | | | | 506 | | | | | 507 +--------+--------------------+------------------+------------------+ 509 Table 2 - Route computation upon multiple link down events when S and 510 E use the different behaviors 512 6. Benefits of standardized SPF delay behavior 514 Using the same event sequence as in Table 1, we may expect fewer and/ 515 or shorter micro-loops using a standardized SPF delay. 517 +--------+--------------------+------------------+------------------+ 518 | Time | Network Event | Router S events | Router E events | 519 +--------+--------------------+------------------+------------------+ 520 | t0=0 | Prefix DOWN | | | 521 | 10ms | | Schedule PRC (in | Schedule PRC (in | 522 | | | 150ms) | 150ms) | 523 | | | | | 524 | | | | | 525 | 160ms | | PRC starts | PRC starts | 526 | 161ms | | PRC ends | | 527 | 162ms | | RIB/FIB starts | PRC ends | 528 | 163ms | | | RIB/FIB starts | 529 | 175ms | | RIB/FIB ends | | 530 | 176ms | | | RIB/FIB ends | 531 | | | | | 532 | 200ms | Prefix UP | | | 533 | 212ms | | Schedule PRC (in | | 534 | | | 150ms) | | 535 | 213ms | | | Schedule PRC (in | 536 | | | | 150ms) | 537 | | | | | 538 | | | | | 539 | 370ms | | PRC starts | PRC starts | 540 | 372ms | | PRC ends | | 541 | 373ms | | RIB/FIB starts | PRC ends | 542 | 374ms | | | RIB/FIB starts | 543 | 383ms | | RIB/FIB ends | | 544 | 384ms | | | RIB/FIB ends | 545 | | | | | 546 | 400ms | Prefix DOWN | | | 547 | 410ms | | Schedule PRC (in | Schedule PRC (in | 548 | | | 300ms) | 300ms) | 549 | | | | | 550 | | | | | 551 | | | | | 552 | | | | | 553 | 710ms | | PRC starts | PRC starts | 554 | 711ms | | PRC ends | PRC ends | 555 | 712ms | | RIB/FIB starts | | 556 | 713ms | | | RIB/FIB starts | 557 | 716ms | | RIB/FIB ends | RIB/FIB ends | 558 | | | | | 559 | 1000ms | S-D link DOWN | | | 560 | 1010ms | | Schedule SPF (in | Schedule SPF (in | 561 | | | 150ms) | 150ms) | 562 | | | | | 563 | | | | | 564 | 1160ms | | SPF starts | | 565 | 1161ms | | SPF ends | SPF starts | 566 | 1162ms | Micro-loop may | RIB/FIB starts | SPF ends | 567 | | start from here | | | 568 | 1163ms | | | RIB/FIB starts | 569 | 1175ms | | RIB/FIB ends | | 570 | 1177ms | Micro-loop ends | | RIB/FIB ends | 571 +--------+--------------------+------------------+------------------+ 573 Table 3 - Route computation when S and E use the same standardized 574 behavior 576 As displayed above, there could be some other parameters like router 577 computation power, flooding timers that may also influence micro- 578 loops. In all the examples in this document comparing the SPF timer 579 behavior of router S and router E, we have made router E a bit slower 580 than router S. This can lead to micro-loops even when both S and E 581 use a common standardized SPF behavior. However, we expect that by 582 aligning implementations of the SPF delay, service providers may 583 reduce the number and the duration of micro-loops. 585 7. Security Considerations 587 This document does not introduce any security consideration. 589 8. Acknowledgements 591 Authors would like to thank Mike Shand and Chris Bowers for their 592 useful comments. 594 9. IANA Considerations 596 This document has no action for IANA. 598 10. References 600 10.1. Normative References 602 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 603 dual environments", RFC 1195, DOI 10.17487/RFC1195, 604 December 1990, . 606 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 607 Requirement Levels", BCP 14, RFC 2119, 608 DOI 10.17487/RFC2119, March 1997, 609 . 611 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 612 DOI 10.17487/RFC2328, April 1998, 613 . 615 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 616 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 617 May 2017, . 619 [RFC8405] Decraene, B., Litkowski, S., Gredler, H., Lindem, A., 620 Francois, P., and C. Bowers, "Shortest Path First (SPF) 621 Back-Off Delay Algorithm for Link-State IGPs", RFC 8405, 622 DOI 10.17487/RFC8405, June 2018, 623 . 625 10.2. Informative References 627 [I-D.ietf-rtgwg-microloop-analysis] 628 Zinin, A., "Analysis and Minimization of Microloops in 629 Link-state Routing Protocols", draft-ietf-rtgwg-microloop- 630 analysis-01 (work in progress), October 2005. 632 [RFC6976] Shand, M., Bryant, S., Previdi, S., Filsfils, C., 633 Francois, P., and O. Bonaventure, "Framework for Loop-Free 634 Convergence Using the Ordered Forwarding Information Base 635 (oFIB) Approach", RFC 6976, DOI 10.17487/RFC6976, July 636 2013, . 638 [RFC8333] Litkowski, S., Decraene, B., Filsfils, C., and P. 639 Francois, "Micro-loop Prevention by Introducing a Local 640 Convergence Delay", RFC 8333, DOI 10.17487/RFC8333, March 641 2018, . 643 Authors' Addresses 645 Stephane Litkowski 646 Orange Business Service 648 Email: stephane.litkowski@orange.com 650 Bruno Decraene 651 Orange 653 Email: bruno.decraene@orange.com 655 Martin Horneffer 656 Deutsche Telekom 658 Email: martin.horneffer@telekom.de