summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc8405.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc8405.txt')
-rw-r--r--doc/rfc/rfc8405.txt787
1 files changed, 787 insertions, 0 deletions
diff --git a/doc/rfc/rfc8405.txt b/doc/rfc/rfc8405.txt
new file mode 100644
index 0000000..10de155
--- /dev/null
+++ b/doc/rfc/rfc8405.txt
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) B. Decraene
+Request for Comments: 8405 Orange
+Category: Standards Track S. Litkowski
+ISSN: 2070-1721 Orange Business Service
+ H. Gredler
+ RtBrick Inc.
+ A. Lindem
+ Cisco Systems
+ P. Francois
+
+ C. Bowers
+ Juniper Networks, Inc.
+ June 2018
+
+
+ Shortest Path First (SPF) Back-Off Delay Algorithm for Link-State IGPs
+
+Abstract
+
+ This document defines a standard algorithm to temporarily postpone or
+ "back off" link-state IGP Shortest Path First (SPF) computations.
+ This reduces the computational load and churn on IGP nodes when
+ multiple temporally close network events trigger multiple SPF
+ computations.
+
+ Having one standard algorithm improves interoperability by reducing
+ the probability and/or duration of transient forwarding loops during
+ the IGP convergence when the IGP reacts to multiple temporally close
+ IGP events.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 7841.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ https://www.rfc-editor.org/info/rfc8405.
+
+
+
+
+
+
+
+
+Decraene, et al. Standards Track [Page 1]
+
+RFC 8405 SPF Back-Off Delay Algorithm June 2018
+
+
+Copyright Notice
+
+ Copyright (c) 2018 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
+ 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
+ 2. High-Level Goals . . . . . . . . . . . . . . . . . . . . . . 3
+ 3. Definitions and Parameters . . . . . . . . . . . . . . . . . 4
+ 4. Principles of the SPF Delay Algorithm . . . . . . . . . . . . 5
+ 5. Specification of the SPF Delay State Machine . . . . . . . . 6
+ 5.1. State Machine . . . . . . . . . . . . . . . . . . . . . . 6
+ 5.2. States . . . . . . . . . . . . . . . . . . . . . . . . . 7
+ 5.3. Timers . . . . . . . . . . . . . . . . . . . . . . . . . 7
+ 5.4. FSM Events . . . . . . . . . . . . . . . . . . . . . . . 7
+ 6. Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 9
+ 7. Partial Deployment . . . . . . . . . . . . . . . . . . . . . 10
+ 8. Impact on Micro-loops . . . . . . . . . . . . . . . . . . . . 11
+ 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
+ 10. Security Considerations . . . . . . . . . . . . . . . . . . . 11
+ 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
+ 11.1. Normative References . . . . . . . . . . . . . . . . . . 11
+ 11.2. Informative References . . . . . . . . . . . . . . . . . 11
+ Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Decraene, et al. Standards Track [Page 2]
+
+RFC 8405 SPF Back-Off Delay Algorithm June 2018
+
+
+1. Introduction
+
+ Link-state IGPs, such as IS-IS [ISO10589], OSPF [RFC2328], and OSPFv3
+ [RFC5340], perform distributed route computation on all routers in
+ the area/level. In order to have consistent routing tables across
+ the network, such distributed computation requires that all routers
+ have the same version of the network topology (Link-State Database
+ (LSDB)) and perform their computation essentially at the same time.
+
+ In general, when the network is stable, there is a desire to trigger
+ a new Shortest Path First (SPF) computation as soon as a failure is
+ detected in order to quickly route around the failure. However, when
+ the network is experiencing multiple failures over a short period of
+ time, there is a conflicting desire to limit the frequency of SPF
+ computations, which would allow a reduction in control plane
+ resources used by IGPs and all protocols/subsystems reacting to the
+ attendant route change, such as LDP [RFC5036], RSVP-TE [RFC3209], BGP
+ [RFC4271], Fast Reroute computations (e.g., Loop-Free Alternates
+ (LFAs) [RFC5286]), FIB updates, etc. This also reduces network churn
+ and, in particular, reduces side effects (such as micro-loops
+ [RFC5715]) that ensue during IGP convergence.
+
+ To allow for this, IGPs usually implement an SPF Back-Off Delay
+ algorithm that postpones or backs off the SPF computation. However,
+ different implementations chose different algorithms. Hence, in a
+ multi-vendor network, it's not possible to ensure that all routers
+ trigger their SPF computation after the same delay. This situation
+ increases the average and maximum differential delay between routers
+ completing their SPF computation. It also increases the probability
+ that different routers compute their FIBs based on different LSDB
+ versions. Both factors increase the probability and/or duration of
+ micro-loops as discussed in Section 8.
+
+ This document specifies a standard algorithm to allow multi-vendor
+ networks to have all routers delay their SPF computations for the
+ same duration.
+
+1.1. 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.
+
+
+
+
+
+
+
+Decraene, et al. Standards Track [Page 3]
+
+RFC 8405 SPF Back-Off Delay Algorithm June 2018
+
+
+2. High-Level Goals
+
+ The high-level goals of this algorithm are the following:
+
+ o very fast convergence for a single event (e.g., link failure),
+
+ o paced fast convergence for multiple temporally close IGP events
+ while IGP stability is considered acceptable,
+
+ o delayed convergence when IGP stability is problematic (this will
+ allow the IGP and related processes to conserve resources during
+ the period of instability), and
+
+ o avoidance of having different SPF_DELAY timer values (Section 3)
+ across different routers in the area/level. This requires
+ specific consideration as different routers may receive IGP
+ messages at different intervals, or even in different orders, due
+ to differences both in the distance from the originator of the IGP
+ event and in flooding implementations.
+
+3. Definitions and Parameters
+
+ IGP event: The reception or origination of an IGP LSDB change
+ requiring a new routing table computation. Some examples are a
+ topology change, a prefix change, and a metric change on a link or
+ prefix. Note that locally triggering a routing table computation is
+ not considered an IGP event since other IGP routers are unaware of
+ this occurrence.
+
+ Routing table computation, in this document, is scoped to the IGP;
+ so, this is the computation of the IGP RIB, performed by the IGP,
+ using the IGP LSDB. No distinction is made between the type of
+ computation performed, e.g., full SPF, incremental SPF, or Partial
+ Route Computation (PRC); the type of computation is a local
+ consideration. This document may interchangeably use the terms
+ "routing table computation" and "SPF computation".
+
+ SPF_DELAY: The delay between the first IGP event triggering a new
+ routing table computation and the start of that routing table
+ computation. It can take the following values:
+
+ INITIAL_SPF_DELAY: A very small delay to quickly handle a single
+ isolated link failure, e.g., 0 milliseconds.
+
+ SHORT_SPF_DELAY: A small delay to provide fast convergence in the
+ case of a single component failure (such as a node failure or Shared
+ Risk Link Group (SRLG) failure) that leads to multiple IGP events,
+ e.g., 50-100 milliseconds.
+
+
+
+Decraene, et al. Standards Track [Page 4]
+
+RFC 8405 SPF Back-Off Delay Algorithm June 2018
+
+
+ LONG_SPF_DELAY: A long delay when the IGP is unstable, e.g., 2
+ seconds. Note that this allows the IGP network to stabilize.
+
+
+ TIME_TO_LEARN_INTERVAL: This is the maximum duration typically needed
+ to learn all the IGP events related to a single component failure
+ (such as router failure or SRLG failure), e.g., 1 second. It's
+ mostly dependent on failure detection time variation between all
+ routers that are adjacent to the failure. Additionally, it may
+ depend on the different IGP implementations/parameters across the
+ network and their relation to the origination and flooding of link
+ state advertisements.
+
+ HOLDDOWN_INTERVAL: The time required with no received IGP event
+ before considering the IGP to be stable again and allowing the
+ SPF_DELAY to be restored to INITIAL_SPF_DELAY, e.g., a
+ HOLDDOWN_INTERVAL of 3 seconds. The HOLDDOWN_INTERVAL MUST be
+ defaulted or configured to be longer than the TIME_TO_LEARN_INTERVAL.
+
+4. Principles of the SPF Delay Algorithm
+
+ For the first IGP event, we assume that there has been a single
+ simple change in the network, which can be taken into account using a
+ single routing computation (e.g., link failure, prefix (metric)
+ change), and we optimize for very fast convergence by delaying the
+ initial routing computation for a small interval, INITIAL_SPF_DELAY.
+ Under this assumption, there is no benefit in delaying the routing
+ computation. In a typical network, this is the most common type of
+ IGP event. Hence, it makes sense to optimize this case.
+
+ If subsequent IGP events are received in a short period of time
+ (TIME_TO_LEARN_INTERVAL), we then assume that a single component
+ failed, but that this failure requires the knowledge of multiple IGP
+ events in order for IGP routing to converge. Under this assumption,
+ we want fast convergence since this is a normal network situation.
+ However, there is a benefit in waiting for all IGP events related to
+ this single component failure: the IGP can then compute the post-
+ failure routing table in a single additional route computation. In
+ this situation, we delay the routing computation by SHORT_SPF_DELAY.
+
+ If IGP events are still received after TIME_TO_LEARN_INTERVAL from
+ the initial IGP event received in QUIET state (see Section 5.1), then
+ the network is presumably experiencing multiple independent failures.
+ In this case, while waiting for network stability, the computations
+ are delayed for a longer time, which is represented by
+ LONG_SPF_DELAY. This SPF delay is used until no IGP events are
+ received for HOLDDOWN_INTERVAL.
+
+
+
+
+Decraene, et al. Standards Track [Page 5]
+
+RFC 8405 SPF Back-Off Delay Algorithm June 2018
+
+
+ Note that in order to increase the consistency network wide, the
+ algorithm uses a delay (TIME_TO_LEARN_INTERVAL) from the initial IGP
+ event rather than the number of SPF computations performed. Indeed,
+ as all routers may receive the IGP events at different times, we
+ cannot assume that all routers will perform the same number of SPF
+ computations. For example, assuming that the SPF delay is 50
+ milliseconds, router R1 may receive three IGP events (E1, E2, E3) in
+ those 50 milliseconds and hence will perform a single routing
+ computation, while another router R2 may only receive two events (E1,
+ E2) in those 50 milliseconds and hence will schedule another routing
+ computation when receiving E3.
+
+5. Specification of the SPF Delay State Machine
+
+ This section specifies the Finite State Machine (FSM) intended to
+ control the timing of the execution of SPF calculations in response
+ to IGP events.
+
+5.1. State Machine
+
+ The FSM is initialized to the QUIET state with all three timers
+ (SPF_TIMER, HOLDDOWN_TIMER, and LEARN_TIMER) deactivated.
+
+ The events that may change the FSM states are an IGP event or the
+ expiration of one timer (SPF_TIMER, HOLDDOWN_TIMER, or LEARN_TIMER).
+
+ The following diagram briefly describes the state transitions.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Decraene, et al. Standards Track [Page 6]
+
+RFC 8405 SPF Back-Off Delay Algorithm June 2018
+
+
+ +-------------------+
+ +---->| |<-------------------+
+ | | QUIET | |
+ +-----| |<---------+ |
+ 7: +-------------------+ | |
+ SPF_TIMER | | |
+ expiration | | |
+ | 1: IGP event | |
+ | | |
+ v | |
+ +-------------------+ | |
+ +---->| | | |
+ | | SHORT_WAIT |----->----+ |
+ +-----| | |
+ 2: +-------------------+ 6: HOLDDOWN_TIMER |
+ IGP event | expiration |
+ 8: SPF_TIMER | |
+ expiration | |
+ | 3: LEARN_TIMER |
+ | expiration |
+ | |
+ v |
+ +-------------------+ |
+ +---->| | |
+ | | LONG_WAIT |------------>-------+
+ +-----| |
+ 4: +-------------------+ 5: HOLDDOWN_TIMER
+ IGP event expiration
+ 9: SPF_TIMER expiration
+
+ Figure 1: State Machine
+
+5.2. States
+
+ The naming and semantics of each state corresponds directly to the
+ SPF delay used for IGP events received in that state. Three states
+ are defined:
+
+ QUIET: This is the initial state, when no IGP events have occurred
+ for at least HOLDDOWN_INTERVAL since the last routing table
+ computation. The state is meant to handle link failures very
+ quickly.
+
+ SHORT_WAIT: This is the state entered when an IGP event has been
+ received in QUIET state. This state is meant to handle a single
+ component failure requiring multiple IGP events (e.g., node, SRLG).
+
+
+
+
+
+Decraene, et al. Standards Track [Page 7]
+
+RFC 8405 SPF Back-Off Delay Algorithm June 2018
+
+
+ LONG_WAIT: This is the state reached after TIME_TO_LEARN_INTERVAL in
+ state SHORT_WAIT. This state is meant to handle multiple independent
+ component failures during periods of IGP instability.
+
+5.3. Timers
+
+ SPF_TIMER: This is the FSM timer that uses the computed SPF delay.
+ Upon expiration, the routing table computation (as defined in
+ Section 3) is performed.
+
+ HOLDDOWN_TIMER: This is the FSM timer that is (re)started when an IGP
+ event is received and set to HOLDDOWN_INTERVAL. Upon expiration, the
+ FSM is moved to the QUIET state.
+
+ LEARN_TIMER: This is the FSM timer that is started when an IGP event
+ is received while the FSM is in the QUIET state. Upon expiration,
+ the FSM is moved to the LONG_WAIT state.
+
+5.4. FSM Events
+
+ This section describes the events and the actions performed in
+ response.
+
+ Transition 1: IGP event while in QUIET state
+
+ Actions on event 1:
+
+ o If SPF_TIMER is not already running, start it with value
+ INITIAL_SPF_DELAY.
+
+ o Start LEARN_TIMER with TIME_TO_LEARN_INTERVAL.
+
+ o Start HOLDDOWN_TIMER with HOLDDOWN_INTERVAL.
+
+ o Transition to SHORT_WAIT state.
+
+
+ Transition 2: IGP event while in SHORT_WAIT
+
+ Actions on event 2:
+
+ o Reset HOLDDOWN_TIMER to HOLDDOWN_INTERVAL.
+
+ o If SPF_TIMER is not already running, start it with value
+ SHORT_SPF_DELAY.
+
+ o Remain in current state.
+
+
+
+
+Decraene, et al. Standards Track [Page 8]
+
+RFC 8405 SPF Back-Off Delay Algorithm June 2018
+
+
+ Transition 3: LEARN_TIMER expiration
+
+ Actions on event 3:
+
+ o Transition to LONG_WAIT state.
+
+
+ Transition 4: IGP event while in LONG_WAIT
+
+ Actions on event 4:
+
+ o Reset HOLDDOWN_TIMER to HOLDDOWN_INTERVAL.
+
+ o If SPF_TIMER is not already running, start it with value
+ LONG_SPF_DELAY.
+
+ o Remain in current state.
+
+
+ Transition 5: HOLDDOWN_TIMER expiration while in LONG_WAIT
+
+ Actions on event 5:
+
+ o Transition to QUIET state.
+
+
+ Transition 6: HOLDDOWN_TIMER expiration while in SHORT_WAIT
+
+ Actions on event 6:
+
+ o Deactivate LEARN_TIMER.
+
+ o Transition to QUIET state.
+
+
+ Transition 7: SPF_TIMER expiration while in QUIET
+
+ Actions on event 7:
+
+ o Compute SPF.
+
+ o Remain in current state.
+
+
+
+
+
+
+
+
+
+Decraene, et al. Standards Track [Page 9]
+
+RFC 8405 SPF Back-Off Delay Algorithm June 2018
+
+
+ Transition 8: SPF_TIMER expiration while in SHORT_WAIT
+
+ Actions on event 8:
+
+ o Compute SPF.
+
+ o Remain in current state.
+
+
+ Transition 9: SPF_TIMER expiration while in LONG_WAIT
+
+ Actions on event 9:
+
+ o Compute SPF.
+
+ o Remain in current state.
+
+6. Parameters
+
+ All the parameters MUST be configurable at the protocol instance
+ level. They MAY be configurable on a per IGP LSDB basis (e.g., IS-IS
+ level, OSPF area, or IS-IS Level 1 area). All the delays
+ (INITIAL_SPF_DELAY, SHORT_SPF_DELAY, LONG_SPF_DELAY,
+ TIME_TO_LEARN_INTERVAL, and HOLDDOWN_INTERVAL) SHOULD be configurable
+ with a granularity of a millisecond. They MUST be configurable with
+ a granularity of at least a tenth of a second. The configurable
+ range for all the parameters SHOULD be from 0 milliseconds to at
+ least 6000 milliseconds. The HOLDDOWN_INTERVAL MUST be defaulted or
+ configured to be longer than the TIME_TO_LEARN_INTERVAL.
+
+ If this SPF Back-Off algorithm is enabled by default, then in order
+ to have consistent SPF delays between implementations with default
+ configuration, the following default values SHOULD be implemented:
+
+ INITIAL_SPF_DELAY 50 ms
+ SHORT_SPF_DELAY 200 ms
+ LONG_SPF_DELAY 5000 ms
+ TIME_TO_LEARN_INTERVAL 500 ms
+ HOLDDOWN_INTERVAL 10000 ms
+
+ In order to satisfy the goals stated in Section 2, operators are
+ RECOMMENDED to configure delay intervals such that INITIAL_SPF_DELAY
+ <= SHORT_SPF_DELAY and SHORT_SPF_DELAY <= LONG_SPF_DELAY.
+
+ When setting (default) values, one should consider the customers and
+ their application requirements, the computational power of the
+ routers, the size of the network as determined primarily by the
+ number of IP prefixes advertised in the IGP, the frequency and number
+
+
+
+Decraene, et al. Standards Track [Page 10]
+
+RFC 8405 SPF Back-Off Delay Algorithm June 2018
+
+
+ of IGP events, and the number of protocol reactions/computations
+ triggered by IGP SPF computation (e.g., BGP, Path Computation Element
+ Communication Protocol (PCEP), Traffic Engineering Constrained SPF
+ (CSPF), and Fast Reroute computations). Note that some or all of
+ these factors may change over the life of the network. In case of
+ doubt, it's RECOMMENDED that timer intervals should be chosen
+ conservatively (i.e., longer timer values).
+
+ For the standard algorithm to be effective in mitigating micro-loops,
+ it is RECOMMENDED that all routers in the IGP domain, or at least all
+ the routers in the same area/level, have exactly the same configured
+ values.
+
+7. Partial Deployment
+
+ In general, the SPF Back-Off Delay algorithm is only effective in
+ mitigating micro-loops if it is deployed with the same parameters on
+ all routers in the IGP domain or, at least, all routers in an IGP
+ area/level. The impact of partial deployment is dependent on the
+ particular event, the topology, and the algorithm(s) used on other
+ routers in the IGP area/level. In cases where the previous SPF Back-
+ Off Delay algorithm was implemented uniformly, partial deployment
+ will increase the frequency and duration of micro-loops. Hence, it
+ is RECOMMENDED that all routers in the IGP domain, or at least within
+ the same area/level, be migrated to the SPF algorithm described
+ herein at roughly the same time.
+
+ Note that this is not a new consideration; over time, network
+ operators have changed SPF delay parameters in order to accommodate
+ new customer requirements for fast convergence, as permitted by new
+ software and hardware. They may also have progressively replaced an
+ implementation using a given SPF Back-Off Delay algorithm with
+ another implementation using a different one.
+
+8. Impact on Micro-loops
+
+ Micro-loops during IGP convergence are due to a non-synchronized or
+ non-ordered update of FIBs [RFC5715] [RFC6976] [SPF-MICRO]. FIBs are
+ installed after multiple steps, such as flooding of the IGP event
+ across the network, SPF wait time, SPF computation, FIB distribution
+ across line cards, and FIB update. This document only addresses the
+ contribution from the SPF wait time. This standardized procedure
+ reduces the probability and/or duration of micro-loops when IGPs
+ experience multiple temporally close events. It does not prevent all
+ micro-loops; however, it is beneficial and is less complex and costly
+ to implement when compared to full solutions such as Distributed
+ Tunnels [RFC5715], Synchronized FIB Update [RFC5715], or the ordered
+ FIB approach [RFC6976].
+
+
+
+Decraene, et al. Standards Track [Page 11]
+
+RFC 8405 SPF Back-Off Delay Algorithm June 2018
+
+
+9. IANA Considerations
+
+ This document has no IANA actions.
+
+10. Security Considerations
+
+ The algorithm presented in this document does not compromise IGP
+ security. An attacker having the ability to generate IGP events
+ would be able to delay the IGP convergence time. The LONG_SPF_DELAY
+ state may help mitigate the effects of Denial-of-Service (DoS)
+ attacks generating many IGP events.
+
+11. References
+
+11.1. Normative References
+
+ [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>.
+
+ [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>.
+
+11.2. Informative References
+
+ [ISO10589]
+ International Organization for Standardization,
+ "Information technology -- Telecommunications and
+ information exchange between systems -- Intermediate
+ System to Intermediate System intra-domain routeing
+ information exchange protocol for use in conjunction with
+ the protocol for providing the connectionless-mode network
+ service (ISO 8473)", ISO/IEC 10589:2002, Second Edition,
+ November 2002.
+
+ [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328,
+ DOI 10.17487/RFC2328, April 1998,
+ <https://www.rfc-editor.org/info/rfc2328>.
+
+ [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
+ and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
+ Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
+ <https://www.rfc-editor.org/info/rfc3209>.
+
+
+
+
+
+
+Decraene, et al. Standards Track [Page 12]
+
+RFC 8405 SPF Back-Off Delay Algorithm June 2018
+
+
+ [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
+ Border Gateway Protocol 4 (BGP-4)", RFC 4271,
+ DOI 10.17487/RFC4271, January 2006,
+ <https://www.rfc-editor.org/info/rfc4271>.
+
+ [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
+ "LDP Specification", RFC 5036, DOI 10.17487/RFC5036,
+ October 2007, <https://www.rfc-editor.org/info/rfc5036>.
+
+ [RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for
+ IP Fast Reroute: Loop-Free Alternates", RFC 5286,
+ DOI 10.17487/RFC5286, September 2008,
+ <https://www.rfc-editor.org/info/rfc5286>.
+
+ [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
+ for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
+ <https://www.rfc-editor.org/info/rfc5340>.
+
+ [RFC5715] Shand, M. and S. Bryant, "A Framework for Loop-Free
+ Convergence", RFC 5715, DOI 10.17487/RFC5715, January
+ 2010, <https://www.rfc-editor.org/info/rfc5715>.
+
+ [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>.
+
+ [SPF-MICRO]
+ Litkowski, S., Decraene, B., and M. Horneffer, "Link State
+ protocols SPF trigger and delay algorithm impact on IGP
+ micro-loops", Work in Progress, draft-ietf-rtgwg-spf-
+ uloop-pb-statement-07, May 2018.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Decraene, et al. Standards Track [Page 13]
+
+RFC 8405 SPF Back-Off Delay Algorithm June 2018
+
+
+Acknowledgements
+
+ We would like to acknowledge Les Ginsberg, Uma Chunduri, Mike Shand,
+ and Alexander Vainshtein for the discussions and comments related to
+ this document.
+
+Authors' Addresses
+
+ Bruno Decraene
+ Orange
+
+ Email: bruno.decraene@orange.com
+
+
+ Stephane Litkowski
+ Orange Business Service
+
+ Email: stephane.litkowski@orange.com
+
+
+ Hannes Gredler
+ RtBrick Inc.
+
+ Email: hannes@rtbrick.com
+
+
+ Acee Lindem
+ Cisco Systems
+ 301 Midenhall Way
+ Cary, NC 27513
+ United States of America
+
+ Email: acee@cisco.com
+
+
+ Pierre Francois
+
+ Email: pfrpfr@gmail.com
+
+
+ Chris Bowers
+ Juniper Networks, Inc.
+ 1194 N. Mathilda Ave.
+ Sunnyvale, CA 94089
+ United States of America
+
+ Email: cbowers@juniper.net
+
+
+
+
+Decraene, et al. Standards Track [Page 14]
+