Routing Area Working GroupInternet Engineering Task Force (IETF) S. LitkowskiInternet-DraftRequest for Comments: 8541 Orange Business ServiceIntended status:Category: Informational B. DecraeneExpires: July 20, 2019ISSN: 2070-1721 Orange M. Horneffer Deutsche TelekomJanuary 16,February 2019Link State protocols SPF triggerImpact of Shortest Path First (SPF) Trigger anddelay algorithm impactDelay Strategies on IGPmicro-loops draft-ietf-rtgwg-spf-uloop-pb-statement-10Micro-loops Abstract A micro-loop is apacket forwardingpacket-forwarding loop that may occur transiently among two or more routers in a hop-by-hoppacket forwardingpacket-forwarding paradigm.In this document, we are trying to analyzeThis document analyzes the impact of using differentLink Statelink state IGP(Interior Gateway Protocol)implementations in a singlenetwork,network with respect to micro-loops. The analysis is focused on theSPF (ShortestShortest PathFirst)First (SPF) delayalgorithm. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.algorithm but also mentions the impact of SPF trigger strategies. Status of This Memo ThisInternet-Draftdocument issubmitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documentsnot an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF).Note that other groups may also distribute working documents as Internet-Drafts. The listIt represents the consensus ofcurrent Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draftthe IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documentsvalidapproved by the IESG are candidates fora maximumany level of Internet Standard; see Section 2 of RFC 7841. Information about the current status ofsix monthsthis document, any errata, and how to provide feedback on it may beupdated, replaced, or obsoleted by other documentsobtained atany time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on July 20, 2019.https://www.rfc-editor.org/info/rfc8541. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. ProblemstatementStatement . . . . . . . . . . . . . . . . . . . . . .43 3. SPFtrigger strategiesTrigger Strategies . . . . . . . . . . . . . . . . . . . 5 4. SPFdelay strategiesDelay Strategies . . . . . . . . . . . . . . . . . . . .65 4.1.Two stepsTwo-Step SPFdelayDelay . . . . . . . . . . . . . . . . . . . 6 4.2. Exponentialbackoff . . . .Back-Off Delay . . . . . . . . . . . . . . .76 5. MixingstrategiesStrategies . . . . . . . . . . . . . . . . . . . . . . 8 6. Benefits ofstandardizedStandardized SPFdelay behaviorDelay Behavior . . . . . . . . .1211 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8.Acknowledgements .IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 9.IANA ConsiderationsReferences . . . . . . . . . . . . . . . . . . . . . . . . . 1310.9.1. Normative References . . . . . . . . . . . . . . . . . . 13 9.2. Informative References . . . . . . .14 10.1. Normative References .. . . . . . . . . . 13 Acknowledgements . . . . . . .14 10.2. Informative References. . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . .1514 1. Introduction LinkStatestate IGP protocols are based on a topology database on which the SPF algorithm is run to find a consistent set of non-looping routing paths. Specifications like IS-IS([RFC1195])[RFC1195] propose some optimizations of the route computation(See(see Appendix C.1 of[RFC1195])[RFC1195]), but not alltheimplementations follow those non-mandatory optimizations.We will call "SPF triggers",In this document, we refer to the events thatwouldlead to a new SPF computation based on thetopology.topology as "SPF triggers". LinkStatestate IGP protocols, like OSPF([RFC2328])[RFC2328] and IS-IS([RFC1195]), are using[RFC1195], use multiple timers to control the router behavior in case of churn: SPF delay,PRC (PartialPartial RouteComputation)Computation (PRC) delay,LSP (LinkLink StatePacket)Packet (LSP) generation delay, LSP flooding delay, and LSP retransmissioninterval...interval. Some ofthose timers (valuesthe values andbehavior)behaviors of these timers are standardized in protocol specifications,whileand some are not. The SPFcomputationcomputation- related timers have generally remained unspecified.For non standardized timers, implementationsImplementations are free to implementthemnon-standardized timers in any way. For some standardized timers,we can also see that rather than using static configurable values for such timer,implementations may offer dynamically adjusted timers to help control thechurn. We will callchurn rather than use static configurable values. "SPFdelay",delay" refers to the timerthat existsin most implementations that specifies the required delay before running an SPF computation afteraan SPF trigger is received. A micro-loop is apacket forwardingpacket-forwarding loop that may occur transiently among two or more routers in a hop-by-hoppacket forwardingpacket-forwarding paradigm.We can observe that theseThese micro-loops are formed when two routers do not update their Forwarding InformationBase (FIB)Bases (FIBs) for a certain prefix at the same time. The micro-loop phenomenon is described in[I-D.ietf-rtgwg-microloop-analysis].[MICROLOOP-LSRP]. Two micro-loop mitigation techniques have been defined by IETF. The mechanism in [RFC6976] has not been widely implemented, presumably due to the complexity of the technique. The mechanism in [RFC8333] has been implemented. However, it does not prevent all micro-loops that can occur for a given topology and failure scenario. In multi-vendor networks, using different implementations of a link state protocol may favormicro-loopsmicro-loop creation during the convergence process due to discrepanciesofin timers. ServiceProviders areproviders alreadyawareknow to usesimilartimers(valueswith similar values andbehavior)behaviors for all of the network as a best practice, butsometimes itthis is sometimes not possible due to the limitations of implementations. This documentwill presentpresents reasons for service providers to have consistentimplementationsimplementation ofLink Statelink state protocols across vendors.We are particularly analyzingIn particular, this document analyzes the impact of using differentLink Statelink state IGP implementations in a single networkin regards ofwith regard to micro- loops. The analysisis focusedfocuses on the SPF delay algorithm. [RFC8405] defines a solution that partially addresses this problemstatementstatement, and this document captures the reasoning of the provided solution. 2. ProblemstatementStatement S ---- E | | 10 | | 10 | | D ---- A | 2 Px Figure1 -1: Networktopology suffering from micro-loopsTopology Experiencing Micro-loops Figure 1 represents a small network composed of four routers(S,D,E(S, D, E, andA).RouterA). Router Susesprimarily uses the SD link to reach the prefixes behind router D (named Px). When the SD link fails, the IGP convergence occurs. If S converges before E, S will forward the traffic to Px throughE, but asE; however, because E has not converged yet, E will loopbackthe traffic back to S, leading to a micro-loop. The micro-loop appears due to the asynchronous convergence of nodes in a network when an event occurs. Multiple factors (or a combination ofthesefactors) may increase the probabilityforof a micro-loopto appear:appearing: othe delayDelay of failure notification:theThe greater the time gap between E and S being advised of the failure, themoregreater the chance that amicro- loopmicro-loop mayhave a chance toappear. otheSPF delay:mostMost implementations support a delay for the SPF computation totry tocatch as many events as possible. If S uses an SPF delay timer of xmsec andms, E uses an SPF delay timer of ymsecms, and x < y, E would start converging afterSS, leading to a potentialmicro-loop.micro- loop. otheSPF computation time: This is mostly a matter of CPU power and optimizations like incremental SPF. If S computes its SPF faster than E, there is a chance for a micro-loop to appear. Today, CPUs aretodayfast enough to consider the SPF computation time as negligible (on the order of milliseconds in a large network). otheSPF computation ordering:anAn SPF trigger can be common to multiple IGP areas or levels (e.g., IS-ISLevel1/Level2)Level 1 and Level 2) orforto multiple address families with multi-topologies. There is no specified order for SPF computationtodaytoday, and it is implementation dependent. In such scenarios, if the order of SPF computation done in S and E for eacharea/level/topology/SPF-algorithmarea, level, topology, or SPF algorithm is different, there is a possibility for a micro-loop to appear. otheRIB and FIB prefix insertion speed orordering.ordering: This is highly dependent on the implementation. Even if all of these factorsmayincrease the probabilityforof a micro-loopto appear,appearing, the SPFdelay,delay plays a significant role, especially in case ofchurn, plays a significant role.churn. As the number of IGP eventsincrease,increases, the delta between the SPF delay values used by routers becomessignificant andsignificant; in fact, it becomes the dominating factor (especially when one router increases its timer exponentially while another one increases it in amoresmoother way). Another important factor is the time to update the FIB. As of today, the total FIB update time is the major factor for IGP convergence. However, for micro-loops, what matters is not the totaltime,time but the differenceto installin installing the same prefix between nodes. The time to update the FIB may be the main part for the first iteration butisnot for subsequent IGP events. In addition, the time to update the FIB is very implementation specific anddifficult/impossibledifficult or impossible to standardize, while the SPF delay algorithm may be standardized. As a consequence, this document will focus onthean analysis oftheSPF delay behavior and associated triggers. 3. SPFtrigger strategiesTrigger Strategies Depending on the change advertised inLSPDU (Link State Protocol Data Unit)the LSP or LSA (Link State Advertisement), the topology maybe affectedornot.may not be affected. An implementation may avoid running the SPF computation (and may only run an IP reachability computation instead) if the advertised change does not affect the topology. Different strategiesexists tocan trigger the SPF computation: 1. An implementation may always run a full SPF for any type of change. 2. An implementation may run a full SPF only when required. For example, if a link fails, a local node will run an SPF for its local LSP update. If the LSP from the neighbor (describing the same failure) is received after SPF has started, the local node can decide that a new full SPF is not required as the topology has not changed. 3. If the topology does not change, an implementation may only recompute the IP reachability. As noted in Section 1, SPF optimizations are not mandatory in specifications. This has led to the implementation of different strategies. 4. SPFdelay strategiesDelay Strategies Implementations of link state routing protocols use different strategies to delaytheSPF computation. The two most common SPF delay behaviors are the following: 1.Two phaseTwo-step SPFdelay.delay 2. Exponentialbackoff delay.back-off delay These behaviorswill beare explained in thenextfollowing sections. 4.1.Two stepsTwo-Step SPFdelayDelay The SPF delay is managed by four parameters: oRapidrapid delay: the amount of time to wait before runningSPF,SPF after the initial SPF trigger event. oRapidrapid runs: the number of consecutive SPF runs that can use the rapid delay. When the number is exceeded, the delay moves to the slow delay value. oSlowslow delay: the amount of time to wait before running an SPF. oWaitwait time: the amount of time to wait withoutreceivingdetecting SPF trigger events before going back to the rapid delay.Example: RapidFigure 2 displays the evolution of the SPF delay timer (based on a two-step delay algorithm) upon the reception of multiple events. Figure 2 considers the following parameters for the algorithm: rapid delay (RD) =50msec, Rapid50 ms, rapid runs = 3,Slowslow delay (SD) =1sec, Wait1 s, wait time =2sec2 s. SPF delay time ^ | | SD- | x xx x | | | RD- | x x x x | +---------------------------------> Events | | | | || | | < wait time > Figure2 - Two phase delay algorithm2: Two-Step SPF Delay Algorithm 4.2. ExponentialbackoffBack-Off Delay The algorithm has two modes:thefast mode andthe backoffback-off mode. Inthefast mode, the SPF delay is usually delayed by a very small amount of time (fast reaction). When an SPF computationhasis run inthefast mode, the algorithm automatically moves tothe backoffback-off mode (a single SPF run is authorized inthefast mode). Inthe backoffback-off mode, the SPF delayis increasingincreases exponentiallyatin each run. When the network becomes stable, the algorithm moves back tothefast mode. The SPF delay is managed by four parameters: oFirstfirst delay: amount of time to wait before running SPF. This delay is used only when SPF is in fast mode. oIncrementalincremental delay: amount of time to wait before running SPF. This delay is used only when SPF is inbackoffback-off mode and increments exponentially at each SPF run. oMaximummaximum delay: maximum amount of time to wait before running SPF. oWaitwait time: amount of time to wait without events before going back tothefast mode.Example: FirstFigure 3 displays the evolution of the SPF delay timer (based on an exponential back-off delay algorithm) upon the reception of multiple events. Figure 3 considers the following parameters for the algorithm: first delay (FD) =50msec, Incremental50 ms, incremental delay (ID) =50msec, Maximum50 ms, maximum delay (MD) =1sec, Wait1 s, wait time =2sec2 s SPF delay time ^ MD- | xx x | | | | | | x | | | | x | FD- | x x x ID | +---------------------------------> Events | | | | || | | < wait time > FM->BM -------------------->FM Figure3 -3: Exponentialdelay algorithmBack-Off Delay Algorithm 5. Mixingstrategies InStrategies Figure1, we consider1 illustrates a flow ofpacketpackets from S to D.We consider thatSis usinguses optimized SPF triggering(Full(full SPF is triggered only whennecessary),necessary) andtwo stepstwo- step SPF delay(rapid=150ms,rapid-runs=3, slow=1s).(rapid delay = 150 ms, rapid runs = 3, slow delay = 1 s). As the implementation of S is optimized,Partial Reachability Computation (PRC)PRC is available.WeFor PRC delay, we consider the same timers asSPFfordelaying PRC. We consider thatSPF delay. Eis using auses an SPF trigger strategy that alwayscomputecomputes aFullfull SPF for anychange,change and uses the exponentialbackoffback-off strategy for SPF delay(start=150ms, inc=150ms, max=1s) We also consider(first delay = 150 ms, incremental delay = 150 ms, maximum delay = 1 s). Consider the following sequence of events: o t0=0 ms:aA prefix is declared down in the network.We consider thisThis eventto happenhappens at time=0. o200ms: the200 ms: The prefix is declaredasup. o400ms: a400 ms: The prefix is declared down in the network. o1000ms:1000 ms: S-D link fails.+--------+--------------------+------------------+------------------++---------+-------------------+------------------+------------------+ | Time | Network Event | Router SeventsEvents | Router EeventsEvents |+--------+--------------------+------------------+------------------++---------+-------------------+------------------+------------------+ | t0=0 | Prefix DOWN | | | |10ms10 ms | | Schedule PRC (in | Schedule SPF (in | | | |150ms)150 ms) |150ms)150 ms) | | | | | | | | | | | |160ms160 ms | | PRC starts | SPF starts | |161ms161 ms | | PRC ends | | |162ms162 ms | | RIB/FIB starts | | |163ms163 ms | | | SPF ends | |164ms164 ms | | | RIB/FIB starts | |175ms175 ms | | RIB/FIB ends | | |178ms178 ms | | | RIB/FIB ends | | | | | | |200ms200 ms | Prefix UP | | | |212ms212 ms | | Schedule PRC (in | | | | |150ms)150 ms) | | |214ms214 ms | | | Schedule SPF (in | | | | |150ms)150 ms) | | | | | | | | | | | |370ms370 ms | | PRC starts | | |372ms372 ms | | PRC ends | | |373ms373 ms | | | SPF starts | |373ms373 ms | | RIB/FIB starts | | |375ms375 ms | | | SPF ends | |376ms376 ms | | | RIB/FIB starts | |383ms383 ms | | RIB/FIB ends | | |385ms385 ms | | | RIB/FIB ends | | | | | | |400ms400 ms | Prefix DOWN | | | |410ms410 ms | | Schedule PRC (in | Schedule SPF (in | | | |300ms)300 ms) |300ms)300 ms) | | | | | | | | | | | | | | | | | | | | | |710ms710 ms | | PRC starts | SPF starts | |711ms711 ms | | PRC ends | | |712ms712 ms | | RIB/FIB starts | | |713ms713 ms | | | SPF ends | |714ms714 ms | | | RIB/FIB starts | |716ms716 ms | | RIB/FIB ends | RIB/FIB ends | | | | | | |1000ms1000 ms | S-D link DOWN | | | |1010ms1010 ms | | Schedule SPF (in | Schedule SPF (in | | | |150ms)150 ms) |600ms)600 ms) | | | | | | | | | | | |1160ms1160 ms | | SPF starts | | |1161ms1161 ms | | SPF ends | | |1162ms1162 ms | Micro-loop may | RIB/FIB starts | | | | start from here | | | |1175ms1175 ms | | RIB/FIB ends | | | | | | | | | | | | | | | | | | | | | | |1612ms1612 ms | | | SPF starts | |1615ms1615 ms | | | SPF ends | |1616ms1616 ms | | | RIB/FIB starts | |1626ms1626 ms | Micro-loop ends | | RIB/FIB ends |+--------+--------------------+------------------+------------------++---------+-------------------+------------------+------------------+ Table1 -1: Routecomputation whenComputation When S and Euse the different behaviorsUse Different Behaviors andmultiple events appearMultiple Events Appear IntheTable 1,we can see thatdue to discrepancies in the SPFmanagement,management and after multiple events ofadifferenttype,types, the values of the SPF delay are completely misaligned between node S and node E, leading to the creation of micro-loops. The same issue can also appear with only a single type of event as shown below:+--------+--------------------+------------------+------------------++---------+-------------------+------------------+------------------+ | Time | Network Event | Router SeventsEvents | Router EeventsEvents |+--------+--------------------+------------------+------------------++---------+-------------------+------------------+------------------+ | t0=0 | Link DOWN | | | |10ms10 ms | | Schedule SPF (in | Schedule SPF (in | | | |150ms)150 ms) |150ms)150 ms) | | | | | | | | | | | |160ms160 ms | | SPF starts | SPF starts | |161ms161 ms | | SPF ends | | |162ms162 ms | | RIB/FIB starts | | |163ms163 ms | | | SPF ends | |164ms164 ms | | | RIB/FIB starts | |175ms175 ms | | RIB/FIB ends | | |178ms178 ms | | | RIB/FIB ends | | | | | | |200ms200 ms | Link DOWN | | | |212ms212 ms | | Schedule SPF (in | | | | |150ms)150 ms) | | |214ms214 ms | | | Schedule SPF (in | | | | |150ms)150 ms) | | | | | | | | | | | |370ms370 ms | | SPF starts | | |372ms372 ms | | SPF ends | | |373ms373 ms | | | SPF starts | |373ms373 ms | | RIB/FIB starts | | |375ms375 ms | | | SPF ends | |376ms376 ms | | | RIB/FIB starts | |383ms383 ms | | RIB/FIB ends | | |385ms385 ms | | | RIB/FIB ends | | | | | | |400ms400 ms | Link DOWN | | | |410ms410 ms | | Schedule SPF (in | Schedule SPF (in | | | |150ms)150 ms) |300ms)300 ms) | | | | | | | | | | | |560ms560 ms | | SPF starts | | |561ms561 ms | | SPF ends | | |562ms562 ms | Micro-loop may | RIB/FIB starts | | | | start from here | | | |568ms568 ms | | RIB/FIB ends | | | | | | | | | | | | |710ms710 ms | | | SPF starts | |713ms713 ms | | | SPF ends | |714ms714 ms | | | RIB/FIB starts | |716ms716 ms | Micro-loop ends | | RIB/FIB ends | | | | | | |1000ms1000 ms | Link DOWN | | | |1010ms1010 ms | | Schedule SPF (in | Schedule SPF (in | | | |1s)1 s) |600ms)600 ms) | | | | | | | | | | | | | | | | | | | | | |1612ms1612 ms | | | SPF starts | |1615ms1615 ms | | | SPF ends | |1616ms1616 ms | Micro-loop may | | RIB/FIB starts | | | start from here | | | |1626ms1626 ms | | | RIB/FIB ends | | | | | | | | | | | | | | | | | | | | | |2012ms2012 ms | | SPF starts | | |2014ms2014 ms | | SPF ends | | |2015ms2015 ms | | RIB/FIB starts | | |2025ms2025 ms | Micro-loop ends | RIB/FIB ends | | | | | | | | | | | |+--------+--------------------+------------------+------------------++---------+-------------------+------------------+------------------+ Table2 -2: RoutecomputationComputation uponmultiple link down events whenMultiple Link Down Events When S and Euse the different behaviorsUse Different Behaviors 6. Benefits ofstandardizedStandardized SPFdelay behavior UsingDelay Behavior Table 3 uses the same event sequence asinTable1, we may expect fewer and/ or1. Fewer and/or shorter micro-loops are expected using a standardized SPF delay.+--------+--------------------+------------------+------------------++---------+-------------------+------------------+------------------+ | Time | Network Event | Router SeventsEvents | Router EeventsEvents |+--------+--------------------+------------------+------------------++---------+-------------------+------------------+------------------+ | t0=0 | Prefix DOWN | | | |10ms10 ms | | Schedule PRC (in | Schedule PRC (in | | | |150ms)150 ms) |150ms)150 ms) | | | | | | | | | | | |160ms160 ms | | PRC starts | PRC starts | |161ms161 ms | | PRC ends | | |162ms162 ms | | RIB/FIB starts | PRC ends | |163ms163 ms | | | RIB/FIB starts | |175ms175 ms | | RIB/FIB ends | | |176ms176 ms | | | RIB/FIB ends | | | | | | |200ms200 ms | Prefix UP | | | |212ms212 ms | | Schedule PRC (in | | | | |150ms)150 ms) | | |213ms213 ms | | | Schedule PRC (in | | | | |150ms)150 ms) | | | | | | | | | | | |370ms370 ms | | PRC starts | PRC starts | |372ms372 ms | | PRC ends | | |373ms373 ms | | RIB/FIB starts | PRC ends | |374ms374 ms | | | RIB/FIB starts | |383ms383 ms | | RIB/FIB ends | | |384ms384 ms | | | RIB/FIB ends | | | | | | |400ms400 ms | Prefix DOWN | | | |410ms410 ms | | Schedule PRC (in | Schedule PRC (in | | | |300ms)300 ms) |300ms)300 ms) | | | | | | | | | | | | | | | | | | | | | |710ms710 ms | | PRC starts | PRC starts | |711ms711 ms | | PRC ends | PRC ends | |712ms712 ms | | RIB/FIB starts | | |713ms713 ms | | | RIB/FIB starts | |716ms716 ms | | RIB/FIB ends | RIB/FIB ends | | | | | | |1000ms1000 ms | S-D link DOWN | | | |1010ms1010 ms | | Schedule SPF (in | Schedule SPF (in | | | |150ms)150 ms) |150ms)150 ms) | | | | | | | | | | | |1160ms1160 ms | | SPF starts | | |1161ms1161 ms | | SPF ends | SPF starts | |1162ms1162 ms | Micro-loop may | RIB/FIB starts | SPF ends | | | start from here | | | |1163ms1163 ms | | | RIB/FIB starts | |1175ms1175 ms | | RIB/FIB ends | | |1177ms1177 ms | Micro-loop ends | | RIB/FIB ends |+--------+--------------------+------------------+------------------++---------+-------------------+------------------+------------------+ Table3 -3: Routecomputation whenComputation When S and EuseUse thesame standardized behaviorSame Standardized Behavior As displayed above, therecouldcan besomeotherparametersparameters, like router computationpower,power and floodingtimerstimers, that may also influence micro- loops. In all the examples in this document comparing the SPF timer behavior of router S and router E, we have made router E a bit slower than router S. This can lead to micro-loops even when both S and E use a common standardized SPF behavior. However,we expect thatby aligning implementations of the SPF delay, we expect that service providers may reduce the number andtheduration of micro-loops. 7. Security Considerations This document does not introduce any securityconsideration.considerations. 8.Acknowledgements Authors would like to thank Mike Shand and Chris Bowers for their useful comments. 9.IANA Considerations This document has noactionactions for IANA.10.9. References10.1.9.1. Normative References [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, DOI 10.17487/RFC1195, December 1990, <https://www.rfc-editor.org/info/rfc1195>.[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 10.17487/RFC2328, April 1998, <https://www.rfc-editor.org/info/rfc2328>.[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.[RFC8405] Decraene, B., Litkowski, S., Gredler, H., Lindem, A., Francois, P., and C. Bowers, "Shortest Path First (SPF) Back-Off Delay Algorithm for Link-State IGPs", RFC 8405, DOI 10.17487/RFC8405, June 2018, <https://www.rfc-editor.org/info/rfc8405>.10.2.9.2. Informative References[I-D.ietf-rtgwg-microloop-analysis][MICROLOOP-LSRP] Zinin, A., "Analysis and Minimization of Microloops in Link-state Routing Protocols",draft-ietf-rtgwg-microloop- analysis-01 (workWork inprogress),Progress, draft- ietf-rtgwg-microloop-analysis-01, October 2005. [RFC6976] Shand, M., Bryant, S., Previdi, S., Filsfils, C., Francois, P., and O. Bonaventure, "Framework for Loop-Free Convergence Using the Ordered Forwarding Information Base (oFIB) Approach", RFC 6976, DOI 10.17487/RFC6976, July 2013, <https://www.rfc-editor.org/info/rfc6976>. [RFC8333] Litkowski, S., Decraene, B., Filsfils, C., and P. Francois, "Micro-loop Prevention by Introducing a Local Convergence Delay", RFC 8333, DOI 10.17487/RFC8333, March 2018, <https://www.rfc-editor.org/info/rfc8333>. Acknowledgements The authors would like to thank Mike Shand and Chris Bowers for their useful comments. Authors' Addresses Stephane Litkowski Orange Business Service Email: stephane.litkowski@orange.com Bruno Decraene Orange Email: bruno.decraene@orange.com Martin Horneffer Deutsche Telekom Email: martin.horneffer@telekom.de