< draft-ietf-rtgwg-backoff-algo-06.txt		draft-ietf-rtgwg-backoff-algo-07.txt >
	Network Working Group B. Decraene		Network Working Group B. Decraene
	Internet-Draft Orange		Internet-Draft Orange
	Intended status: Standards Track S. Litkowski		Intended status: Standards Track S. Litkowski
	Expires: April 25, 2018 Orange Business Service		Expires: June 13, 2018 Orange Business Service
	H. Gredler		H. Gredler
	RtBrick Inc		RtBrick Inc
	A. Lindem		A. Lindem
	Cisco Systems		Cisco Systems
	P. Francois		P. Francois
	C. Bowers		C. Bowers
	Juniper Networks, Inc.		Juniper Networks, Inc.
	October 22, 2017		December 10, 2017
	SPF Back-off algorithm for link state IGPs		SPF Back-off algorithm for link state IGPs
	draft-ietf-rtgwg-backoff-algo-06		draft-ietf-rtgwg-backoff-algo-07
	Abstract		Abstract
	This document defines a standard algorithm to back-off link-state IGP		This document defines a standard algorithm to back-off link-state IGP
	SPF computations.		Shortest Path First (SPF) computations.
	Having one standard algorithm improves interoperability by reducing		Having one standard algorithm improves interoperability by reducing
	the probability and/or duration of transient forwarding loops during		the probability and/or duration of transient forwarding loops during
	the IGP convergence when the IGP reacts to multiple temporally close		the IGP convergence when the IGP reacts to multiple temporally close
	IGP events.		IGP events.
	Requirements Language		Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	skipping to change at page 2, line 4 ¶		skipping to change at page 2, line 4 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on April 25, 2018.		This Internet-Draft will expire on June 13, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2017 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 28 ¶		skipping to change at page 2, line 28 ¶
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. High level goals . . . . . . . . . . . . . . . . . . . . . . 3		2. High level goals . . . . . . . . . . . . . . . . . . . . . . 3
	3. Definitions and parameters . . . . . . . . . . . . . . . . . 4		3. Definitions and parameters . . . . . . . . . . . . . . . . . 4
	4. Principles of SPF delay algorithm . . . . . . . . . . . . . . 5		4. Principles of SPF delay algorithm . . . . . . . . . . . . . . 5
	5. Specification of the SPF delay state machine . . . . . . . . 5		5. Specification of the SPF delay state machine . . . . . . . . 5
	5.1. States . . . . . . . . . . . . . . . . . . . . . . . . . 5		5.1. States . . . . . . . . . . . . . . . . . . . . . . . . . 6
	5.2. States Transitions . . . . . . . . . . . . . . . . . . . 6		5.2. Timers . . . . . . . . . . . . . . . . . . . . . . . . . 6
	5.3. FSM Events . . . . . . . . . . . . . . . . . . . . . . . 7		5.3. States Transitions . . . . . . . . . . . . . . . . . . . 6
			5.4. FSM Events . . . . . . . . . . . . . . . . . . . . . . . 7
	6. Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 9		6. Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 9
	7. Partial Deployment . . . . . . . . . . . . . . . . . . . . . 9		7. Partial Deployment . . . . . . . . . . . . . . . . . . . . . 10
	8. Impact on micro-loops . . . . . . . . . . . . . . . . . . . . 10		8. Impact on micro-loops . . . . . . . . . . . . . . . . . . . . 10
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
	10. Security considerations . . . . . . . . . . . . . . . . . . . 10		10. Security considerations . . . . . . . . . . . . . . . . . . . 11
	11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10		11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . 10		12. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
	12.1. Normative References . . . . . . . . . . . . . . . . . . 10		12.1. Normative References . . . . . . . . . . . . . . . . . . 11
	12.2. Informative References . . . . . . . . . . . . . . . . . 11		12.2. Informative References . . . . . . . . . . . . . . . . . 11
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
	1. Introduction		1. Introduction
	Link state IGPs, such as IS-IS [ISO10589-Second-Edition] and OSPF		Link state IGPs, such as IS-IS [ISO10589-Second-Edition] and OSPF
	[RFC2328], perform distributed route computation on all routers in		[RFC2328], perform distributed route computation on all routers in
	the area/level. In order to have consistent routing tables across		the area/level. In order to have consistent routing tables across
	the network, such distributed computation requires that all routers		the network, such distributed computation requires that all routers
	have the same version of the network topology (Link State DataBase		have the same version of the network topology (Link State DataBase
	(LSDB)) and perform their computation at the same time.		(LSDB)) and perform their computation at the same time.
	In general, when the network is stable, there is a desire to compute		In general, when the network is stable, there is a desire to compute
	a new SPF as soon as a failure is detected in order to quickly route		a new Shortest Path First (SPF) as soon as a failure is detected in
	around the failure. However, when the network is experiencing		order to quickly route around the failure. However, when the network
	multiple temporally close failures over a short period of time, there		is experiencing multiple temporally close failures over a short
	is a conflicting desire to limit the frequency of SPF computations.		period of time, there is a conflicting desire to limit the frequency
	Indeed, this allows a reduction in control plane resources used by		of SPF computations. Indeed, this allows a reduction in control
	IGPs and all protocols/subsystems reacting on the attendant route		plane resources used by IGPs and all protocols/subsystems reacting on
	change, such as LDP, RSVP-TE, BGP, Fast ReRoute computations, FIB		the attendant route change, such as LDP [RFC5036], RSVP-TE [RFC3209],
	updates... This also reduces the churn on routers and in the network		BGP [RFC4271], Fast ReRoute computations (e.g. Loop Free Alternates
	and, in particular, reduces the side effects such as micro-loops that		(LFA) [RFC5286], FIB updates... This also reduces the churn on
	ensue during IGP convergence.		routers and in the network and, in particular, reduces the side
			effects such as micro-loops [RFC5715] that ensue during IGP
			convergence.
	To allow for this, IGPs implement an SPF back-off algorithm.		To allow for this, IGPs implement an SPF back-off algorithm.
	However, different implementations have choosen different algorithms.		However, different implementations have choosen different algorithms.
	Hence, in a multi-vendor network, it's not possible to ensure that		Hence, in a multi-vendor network, it's not possible to ensure that
	all routers trigger their SPF computation after the same delay. This		all routers trigger their SPF computation after the same delay. This
	situation increases the average differential delay between routers		situation increases the average and maximum differential delay
	completing their SPF computation. It also increases the probability		between routers completing their SPF computation. It also increases
	that different routers compute their FIBs based on different LSDB		the probability that different routers compute their FIBs based on
	versions. Both factors increase the probability and/or duration of		different LSDB versions. Both factors increase the probability and/
	micro-loops.		or duration of micro-loops as discussed in Section 8.
	To allow multi-vendor networks to have all routers delay their SPF		To allow multi-vendor networks to have all routers delay their SPF
	computations for the same duration, this document specifies a		computations for the same duration, this document specifies a
	standard algorithm. Optionally, implementations may offer		standard algorithm. Optionally, implementations may also offer
	alternative algorithms.		alternative algorithms.
	2. High level goals		2. High level goals
	The high level goals of this algorithm are the following:		The high level goals of this algorithm are the following:
	o Very fast convergence for a single event (e.g., link failure).		o Very fast convergence for a single event (e.g., link failure).
	o Paced fast convergence for multiple temporally close IGP events		o Paced fast convergence for multiple temporally close IGP events
	while IGP stability is considered acceptable.		while IGP stability is considered acceptable.
	skipping to change at page 4, line 29 ¶		skipping to change at page 4, line 29 ¶
	computation and SPF computation.		computation and SPF computation.
	SPF_DELAY: The delay between the first IGP event triggering a new		SPF_DELAY: The delay between the first IGP event triggering a new
	routing table computation and the start of that routing table		routing table computation and the start of that routing table
	computation. It can take the following values:		computation. It can take the following values:
	INITIAL_SPF_DELAY: A very small delay to quickly handle link		INITIAL_SPF_DELAY: A very small delay to quickly handle link
	failure, e.g., 0 milliseconds.		failure, e.g., 0 milliseconds.
	SHORT_SPF_DELAY: A small delay to have a fast convergence in case of		SHORT_SPF_DELAY: A small delay to have a fast convergence in case of
	a single component failure (node, SRLG..), e.g., 50-100		a single failure (node, SRLG..), e.g., 50-100 milliseconds.
	milliseconds.
	LONG_SPF_DELAY: A long delay when the IGP is unstable, e.g., 2		LONG_SPF_DELAY: A long delay when the IGP is unstable, e.g., 2
	seconds. Note that this allows the IGP network to stabilize.		seconds. Note that this allows the IGP network to stabilize.
	TIME_TO_LEARN_INTERVAL: This is the maximum duration typically needed		TIME_TO_LEARN_INTERVAL: This is the maximum duration typically needed
	to learn all the IGP events related to a single component failure		to learn all the IGP events related to a single component failure
	(e.g., router failure, SRLG failure), e.g., 1 second. It's mostly		(e.g., router failure, SRLG failure), e.g., 1 second. It's mostly
	dependent on failure detection time variation between all routers		dependent on failure detection time variation between all routers
	that are adjacent to the failure. Additionally, it may depend on the		that are adjacent to the failure. Additionally, it may depend on the
	different IGP implementations across the network, related to		different IGP implementations/parameters across the network, related
	origination and flooding of their link state advertisements.		to origination and flooding of their link state advertisements.
	HOLDDOWN_INTERVAL: The time required with no received IGP events		HOLDDOWN_INTERVAL: The time required with no received IGP events
	before considering the IGP to be stable again and allowing the		before considering the IGP to be stable again and allowing the
	SPF_DELAY to be restored to INITIAL_SPF_DELAY. e.g., 3 seconds.		SPF_DELAY to be restored to INITIAL_SPF_DELAY. e.g., 3 seconds. The
			HOLDDOWN_INTERVAL MUST be defaulted or configured to be longer than
	SPF_TIMER: The Finite State Machine (FSM) abstract timer that uses		the TIME_TO_LEARN_INTERVAL.
	the computed SPF delay. Upon expiration, the Route Table Computation
	(as defined above) is performed.
	4. Principles of SPF delay algorithm		4. Principles of SPF delay algorithm
	For this first IGP event, we assume that there has been a single		For this first IGP event, we assume that there has been a single
	simple change in the network which can be taken into account using a		simple change in the network which can be taken into account using a
	single routing computation (e.g., link failure, prefix (metric)		single routing computation (e.g., link failure, prefix (metric)
	change) and we optimize for very fast convergence, delaying the		change) and we optimize for very fast convergence, delaying the
	routing computation by INITIAL_SPF_DELAY. Under this assumption,		routing computation by INITIAL_SPF_DELAY. Under this assumption,
	there is no benefit in delaying the routing computation. In a		there is no benefit in delaying the routing computation. In a
	typical network, this is the most common type of IGP event. Hence,		typical network, this is the most common type of IGP event. Hence,
	skipping to change at page 5, line 33 ¶		skipping to change at page 5, line 33 ¶
	failure routing table in a single route computation. In this		failure routing table in a single route computation. In this
	situation, we delay the routing computation by SHORT_SPF_DELAY.		situation, we delay the routing computation by SHORT_SPF_DELAY.
	If IGP events are still received after TIME_TO_LEARN_INTERVAL from		If IGP events are still received after TIME_TO_LEARN_INTERVAL from
	the initial IGP event received in QUIET state, then the network is		the initial IGP event received in QUIET state, then the network is
	presumably experiencing multiple independent failures. In this case,		presumably experiencing multiple independent failures. In this case,
	while waiting for network stability, the computations are delayed for		while waiting for network stability, the computations are delayed for
	a longer time represented by LONG_SPF_DELAY. This SPF delay is kept		a longer time represented by LONG_SPF_DELAY. This SPF delay is kept
	until no IGP events are received for HOLDDOWN_INTERVAL.		until no IGP events are received for HOLDDOWN_INTERVAL.
	Note that previous SPF delay algorithms used to count the number of		Note that previously implemented SPF delay algorithms counted the
	SPF computations. However, as all routers may receive the IGP events		number of SPF computations. However, as all routers may receive the
	at different times, we cannot assume that all routers will perform		IGP events at different times, we cannot assume that all routers will
	the same number of SPF computations or that they will schedule them		perform the same number of SPF computations or that they will
	at the same time. For example, assuming that the SPF delay is 50 ms,		schedule them at the same time. For example, assuming that the SPF
	router R1 may receive 3 IGP events (E1, E2, E3) in those 50 ms and		delay is 50 ms, router R1 may receive 3 IGP events (E1, E2, E3) in
	hence will perform a single routing computation. While another		those 50 ms and hence will perform a single routing computation.
	router R2 may only receive 2 events (E1, E2) in those 50 ms and hence		While another router R2 may only receive 2 events (E1, E2) in those
	will schedule another routing computation when receiving E3. That's		50 ms and hence will schedule another routing computation when
	why this document uses a time (TIME_TO_LEARN) from the initial event		receiving E3. That's why this document uses a time
	detection/reception as opposed to counting the number of SPF		(TIME_TO_LEARN_INTERVAL) from the initial event detection/reception
	computations to determine when the IGP is unstable.		as opposed to counting the number of SPF computations to determine
			when the IGP is unstable.
	5. Specification of the SPF delay state machine		5. Specification of the SPF delay state machine
	5.1. States		5.1. States
	This section describes the state machine. The naming and semantics		This section describes the state machine. The naming and semantics
	of each state corresponds directly to the SPF delay used for IGP		of each state corresponds directly to the SPF delay used for IGP
	events received in that state. Three states are defined:		events received in that state. Three states are defined:
	QUIET: This is the initial state, when no IGP events have occured for		QUIET: This is the initial state, when no IGP events have occured for
	at least HOLDDOWN_INTERVAL since the previous routing table		at least HOLDDOWN_INTERVAL since the previous routing table
	computation. The state is meant to handle link failures very		computation. The state is meant to handle link failures very
	quickly.		quickly.
	SHORT_WAIT: State entered when an IGP event has been received in		SHORT_WAIT: State entered when an IGP event has been received in
	QUIET state. This state is meant to handle single component failure		QUIET state. This state is meant to handle single component failure
	requiring multiple IGP events (e.g., node, SRLG).		requiring multiple IGP events (e.g., node, SRLG).
	LONG_WAIT: State reached after TIME_TO_LEARN_INTERVAL. In other		LONG_WAIT: State reached after TIME_TO_LEARN_INTERVAL. In other
	words, state reached after TIME_TO_LEARN_INTERVAL in state		words, state reached after TIME_TO_LEARN_INTERVAL in state
	SHORT_WAIT. This state is meant to handle multiple independent		SHORT_WAIT. This state is meant to handle multiple independent
	component failures during periods of IGP instability.		component failures during periods of IGP instability.
	5.2. States Transitions		5.2. Timers
	The FSM is initialized to the QUIET_STATE with all three timers		SPF_TIMER: The Finite State Machine (FSM) abstract timer that uses
	deactivated. The following diagram describes briefly the state		the computed SPF delay. Upon expiration, the Route Table Computation
	transitions.		(as defined in Section 3) is performed.
			HOLDDOWN_TIMER: The Finite State Machine (FSM) abstract timer that is
			(re)started whan an IGP event is received and set to
			HOLDDOWN_INTERVAL. Upon expiration, the FSM is moved to the QUIET
			state.
			LEARN_TIMER: The Finite State Machine (FSM) abstract timer that is
			started when an IGP event is recevied while the FSM is in the QUIET
			state. Upon expiration, the FSM is moved to the LONG_WAIT state.
			5.3. States Transitions
			The FSM is initialized to the QUIET state with all three timers
			timers (SPF_TIMER, HOLDDOWN_TIMER, LEARN_TIMER) deactivated.
			The events which may change the FSM states are an IGP event or the
			expiration of one timer (SPF_TIMER, HOLDDOWN_TIMER, LEARN_TIMER).
			The following diagram briefly describes the state transitions.
	+-------------------+		+-------------------+
	| |<-------------------+		+---->| |<-------------------+
	| QUIET | |		| | QUIET | |
	| |<---------+ |		+-----| |<---------+ |
	+-------------------+ | |		7: +-------------------+ | |
	| | |		SPF_TIMER | | |
	| | |		expiration | | |
	| 1: IGP event | |		| 1: IGP event | |
	| | |		| | |
	v | |		v | |
	+-------------------+ | |		+-------------------+ | |
	+---->| | | |		+---->| | | |
	| | SHORT_WAIT |----->----+ |		| | SHORT_WAIT |----->----+ |
	+-----| | |		+-----| | |
	2: +-------------------+ 6: HOLDDOWN_TIMER |		2: +-------------------+ 6: HOLDDOWN_TIMER |
	IGP event | expiration |		IGP event | expiration |
	| |		8: SPF_TIMER | |
	| |		expiration | |
	| 3: LEARN_TIMER |		| 3: LEARN_TIMER |
	| expiration |		| expiration |
	| |		| |
	v |		v |
	+-------------------+ |		+-------------------+ |
	+---->| | |		+---->| | |
	| | LONG_WAIT |------------>-------+		| | LONG_WAIT |------------>-------+
	+-----| |		+-----| |
	4: +-------------------+ 5: HOLDDOWN_TIMER		4: +-------------------+ 5: HOLDDOWN_TIMER
	IGP event expiration		IGP event expiration
			9: SPF_TIMER expiration
	Figure 1: State Machine		Figure 1: State Machine
	5.3. FSM Events		5.4. FSM Events
	This section describes the events and the actions performed in		This section describes the events and the actions performed in
	response.		response.
	Event 1: IGP event, while in QUIET_STATE.		Transition 1: IGP event, while in QUIET_STATE.
	Actions on event 1:		Actions on event 1:
	o If SPF_TIMER is not already running, start it with value		o If SPF_TIMER is not already running, start it with value
	INITIAL_SPF_DELAY.		INITIAL_SPF_DELAY.
	o Start LEARN_TIMER with TIME_TO_LEARN_INTERVAL.		o Start LEARN_TIMER with TIME_TO_LEARN_INTERVAL.
	o Start HOLDDOWN_TIMER with HOLDDOWN_INTERVAL.		o Start HOLDDOWN_TIMER with HOLDDOWN_INTERVAL.
	o Transition to SHORT_WAIT state.		o Transition to SHORT_WAIT state.
	Event 2: IGP event, while in SHORT_WAIT.		Transition 2: IGP event, while in SHORT_WAIT.
	Actions on event 2:		Actions on event 2:
	o Reset HOLDDOWN_TIMER to HOLDDOWN_INTERVAL.		o Reset HOLDDOWN_TIMER to HOLDDOWN_INTERVAL.
	o If SPF_TIMER is not already running, start it with value		o If SPF_TIMER is not already running, start it with value
	SHORT_SPF_DELAY.		SHORT_SPF_DELAY.
	o Remain in current state.		o Remain in current state.
	Event 3: LEARN_TIMER expiration.		Transition 3: LEARN_TIMER expiration.
	Actions on event 3:		Actions on event 3:
	o Transition to LONG_WAIT state.		o Transition to LONG_WAIT state.
	Event 4: IGP event, while in LONG_WAIT.		Transition 4: IGP event, while in LONG_WAIT.
	Actions on event 4:		Actions on event 4:
	o Reset HOLDDOWN_TIMER to HOLDDOWN_INTERVAL.		o Reset HOLDDOWN_TIMER to HOLDDOWN_INTERVAL.
	o If SPF_TIMER is not already running, start it with value		o If SPF_TIMER is not already running, start it with value
	LONG_SPF_DELAY.		LONG_SPF_DELAY.
	o Remain in current state.		o Remain in current state.
	Event 5: HOLDDOWN_TIMER expiration, while in LONG_WAIT.		Transition 5: HOLDDOWN_TIMER expiration, while in LONG_WAIT.
	Actions on event 5:		Actions on event 5:
	o Transition to QUIET state.		o Transition to QUIET state.
	Event 6: HOLDDOWN_TIMER expiration, while in SHORT_WAIT.		Transition 6: HOLDDOWN_TIMER expiration, while in SHORT_WAIT.
	Actions on event 6:		Actions on event 6:
	o Deactivate LEARN_TIMER.		o Deactivate LEARN_TIMER.
	o Transition to QUIET state.		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.
			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		6. Parameters
	All the parameters MUST be configurable [I-D.ietf-isis-yang-isis-cfg]		All the parameters MUST be configurable [I-D.ietf-isis-yang-isis-cfg]
	[I-D.ietf-ospf-yang] at the protocol instance granularity. They MAY		[I-D.ietf-ospf-yang] at the protocol instance granularity. They MAY
	be configurable at the area/level granularity. All the delays		be configurable at the area/level granularity. All the delays
	(INITIAL_SPF_DELAY, SHORT_SPF_DELAY, LONG_SPF_DELAY,		(INITIAL_SPF_DELAY, SHORT_SPF_DELAY, LONG_SPF_DELAY,
	TIME_TO_LEARN_INTERVAL, HOLDDOWN_INTERVAL) SHOULD be configurable at		TIME_TO_LEARN_INTERVAL, HOLDDOWN_INTERVAL) SHOULD be configurable at
	the millisecond granularity. They MUST be configurable at least at		the millisecond granularity. They MUST be configurable at least at
	the tenth of second granularity. The configurable range for all the		the tenth of second granularity. The configurable range for all the
	parameters SHOULD at least be from 0 milliseconds to 60 seconds.		parameters SHOULD at least be from 0 milliseconds to 60 seconds.
	skipping to change at page 9, line 44 ¶		skipping to change at page 10, line 22 ¶
	start with safe, i.e., longer timers.		start with safe, i.e., longer timers.
	For the standard algorithm to be effective in mitigating micro-loops,		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		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		the routers in the same area/level, have exactly the same configured
	values.		values.
	7. Partial Deployment		7. Partial Deployment
	In general, the SPF delay algorithm is only effective in mitigating		In general, the SPF delay algorithm is only effective in mitigating
	micro-loops if it is deployed on all routers in the IGP domain or, at		micro-loops if it is deployed, with the same parameters, on all
	least, all routers in an IGP area/level. The impact of partial		routers, in the IGP domain or, at least, all routers in an IGP area/
	deployment is based on the particular event, topology, and the SPF		level. The impact of partial deployment is based on the particular
	algorithm(s) used on other routers in the IGP area/level. In cases		event, topology, and the SPF algorithm(s) used on other routers in
	where the previous SPF algorithm was implemented uniformly, partial		the IGP area/level. In cases where the previous SPF algorithm was
	deployment will increase the frequency and duration of micro-loops.		implemented uniformly, partial deployment will increase the frequency
	Hence, it is RECOMMENDED that all routers in the IGP domain or at		and duration of micro-loops. Hence, it is RECOMMENDED that all
	least within the same area/level be migrated to the SPF algorithm		routers in the IGP domain or at least within the same area/level be
	described herein at roughly the same time.		migrated to the SPF algorithm described herein at roughly the same
			time.
	Note that this is not a new consideration as over times, network		Note that this is not a new consideration as over times, network
	operators have changed SPF delay parameters in order to accommodate		operators have changed SPF delay parameters in order to accommodate
	new customer requirements for fast convergence, as permitted by new		new customer requirements for fast convergence, as permitted by new
	software and hardware. They may also have progressively replaced an		software and hardware. They may also have progressively replaced an
	implementation with a given SPF delay algorithm by another		implementation with a given SPF delay algorithm by another
	implementation with a different one.		implementation with a different one.
	8. Impact on micro-loops		8. Impact on micro-loops
	Micro-loops during IGP convergence are due to a non-synchronized or		Micro-loops during IGP convergence are due to a non-synchronized or
	non-ordered update of the forwarding information tables (FIB)		non-ordered update of the forwarding information tables (FIB)
	[RFC5715] [RFC6976] [I-D.ietf-rtgwg-spf-uloop-pb-statement]. FIBs		[RFC5715] [RFC6976] [I-D.ietf-rtgwg-spf-uloop-pb-statement]. FIBs
	are installed after multiple steps such as SPF wait time, SPF		are installed after multiple steps such as flooding of the IGP event
	computation, FIB distribution, and FIB update. This document only		across the network, SPF wait time, SPF computation, FIB distribution
	addresses the first contribution. This standardized procedure		across line cards, and FIB update. This document only addresses the
	reduces the probability and/or duration of micro-loops when IGPs		first contribution. This standardized procedure reduces the
	experience multiple temporally close events. It does not prevent all		probability and/or duration of micro-loops when IGPs experience
	micro-loops. However, it is beneficial and is less complex and		multiple temporally close events. It does not prevent all micro-
	costly to implement when compared to full solutions such as [RFC5715]		loops. However, it is beneficial and is less complex and costly to
	or [RFC6976].		implement when compared to full solutions such as [RFC5715] or
			[RFC6976].
	9. IANA Considerations		9. IANA Considerations
	No IANA actions required.		No IANA actions required.
	10. Security considerations		10. Security considerations
	The algorithm presented in this document does not compromise IGP		The algorithm presented in this document does not compromise IGP
	security. An attacker having the ability to generate IGP events		security. An attacker having the ability to generate IGP events
	would be able to delay the IGP convergence time. The LONG_SPF_DELAY		would be able to delay the IGP convergence time. The LONG_SPF_DELAY
	skipping to change at page 11, line 10 ¶		skipping to change at page 11, line 39 ¶
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	12.2. Informative References		12.2. Informative References
	[I-D.ietf-isis-yang-isis-cfg]		[I-D.ietf-isis-yang-isis-cfg]
	Litkowski, S., Yeung, D., Lindem, A., Zhang, Z., and L.		Litkowski, S., Yeung, D., Lindem, A., Zhang, Z., and L.
	Lhotka, "YANG Data Model for IS-IS protocol", draft-ietf-		Lhotka, "YANG Data Model for IS-IS protocol", draft-ietf-
	isis-yang-isis-cfg-18 (work in progress), July 2017.		isis-yang-isis-cfg-19 (work in progress), November 2017.
	[I-D.ietf-ospf-yang]		[I-D.ietf-ospf-yang]
	Yeung, D., Qu, Y., Zhang, Z., Chen, I., and A. Lindem,		Yeung, D., Qu, Y., Zhang, Z., Chen, I., and A. Lindem,
	"Yang Data Model for OSPF Protocol", draft-ietf-ospf-		"Yang Data Model for OSPF Protocol", draft-ietf-ospf-
	yang-08 (work in progress), July 2017.		yang-09 (work in progress), October 2017.
	[I-D.ietf-rtgwg-spf-uloop-pb-statement]		[I-D.ietf-rtgwg-spf-uloop-pb-statement]
	Litkowski, S., Decraene, B., and M. Horneffer, "Link State		Litkowski, S., Decraene, B., and M. Horneffer, "Link State
	protocols SPF trigger and delay algorithm impact on IGP		protocols SPF trigger and delay algorithm impact on IGP
	micro-loops", draft-ietf-rtgwg-spf-uloop-pb-statement-04		micro-loops", draft-ietf-rtgwg-spf-uloop-pb-statement-05
	(work in progress), May 2017.		(work in progress), December 2017.
	[ISO10589-Second-Edition]		[ISO10589-Second-Edition]
	International Organization for Standardization,		International Organization for Standardization,
	"Intermediate system to Intermediate system intra-domain		"Intermediate system to Intermediate system intra-domain
	routeing information exchange protocol for use in		routeing information exchange protocol for use in
	conjunction with the protocol for providing the		conjunction with the protocol for providing the
	connectionless-mode Network Service (ISO 8473)", ISO/		connectionless-mode Network Service (ISO 8473)", ISO/
	IEC 10589:2002, Second Edition, Nov 2002.		IEC 10589:2002, Second Edition, Nov 2002.
	[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328,		[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328,
	DOI 10.17487/RFC2328, April 1998,		DOI 10.17487/RFC2328, April 1998,
	<https://www.rfc-editor.org/info/rfc2328>.		<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>.
			[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>.
	[RFC5715] Shand, M. and S. Bryant, "A Framework for Loop-Free		[RFC5715] Shand, M. and S. Bryant, "A Framework for Loop-Free
	Convergence", RFC 5715, DOI 10.17487/RFC5715, January		Convergence", RFC 5715, DOI 10.17487/RFC5715, January
	2010, <https://www.rfc-editor.org/info/rfc5715>.		2010, <https://www.rfc-editor.org/info/rfc5715>.
	[RFC6976] Shand, M., Bryant, S., Previdi, S., Filsfils, C.,		[RFC6976] Shand, M., Bryant, S., Previdi, S., Filsfils, C.,
	Francois, P., and O. Bonaventure, "Framework for Loop-Free		Francois, P., and O. Bonaventure, "Framework for Loop-Free
	Convergence Using the Ordered Forwarding Information Base		Convergence Using the Ordered Forwarding Information Base
	(oFIB) Approach", RFC 6976, DOI 10.17487/RFC6976, July		(oFIB) Approach", RFC 6976, DOI 10.17487/RFC6976, July
	2013, <https://www.rfc-editor.org/info/rfc6976>.		2013, <https://www.rfc-editor.org/info/rfc6976>.
End of changes. 36 change blocks.
	93 lines changed or deleted		158 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/