< draft-ietf-rtgwg-spf-uloop-pb-statement-06.txt		draft-ietf-rtgwg-spf-uloop-pb-statement-07.txt >
	Routing Area Working Group S. Litkowski		Routing Area Working Group S. Litkowski
	Internet-Draft Orange Business Service		Internet-Draft Orange Business Service
	Intended status: Informational B. Decraene		Intended status: Informational B. Decraene
	Expires: July 28, 2018 Orange		Expires: November 24, 2018 Orange
	M. Horneffer		M. Horneffer
	Deutsche Telekom		Deutsche Telekom
	January 24, 2018		May 23, 2018
	Link State protocols SPF trigger and delay algorithm impact on IGP		Link State protocols SPF trigger and delay algorithm impact on IGP
	micro-loops		micro-loops
	draft-ietf-rtgwg-spf-uloop-pb-statement-06		draft-ietf-rtgwg-spf-uloop-pb-statement-07
	Abstract		Abstract
	A micro-loop is a packet forwarding loop that may occur transiently		A micro-loop is a packet forwarding loop that may occur transiently
	among two or more routers in a hop-by-hop packet forwarding paradigm.		among two or more routers in a hop-by-hop packet forwarding paradigm.
	In this document, we are trying to analyze the impact of using		In this document, we are trying to analyze the impact of using
	different Link State IGP implementations in a single network in		different Link State IGP implementations in a single network, with
	regards of micro-loops. The analysis is focused on the SPF triggers		respect to micro-loops. The analysis is focused on the SPF delay
	and SPF delay algorithm.		algorithm.
	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
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	skipping to change at page 1, line 46 ¶		skipping to change at page 1, line 46 ¶
	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 July 28, 2018.		This Internet-Draft will expire on November 24, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2018 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	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. Problem statement . . . . . . . . . . . . . . . . . . . . . . 3		2. Problem statement . . . . . . . . . . . . . . . . . . . . . . 4
	3. SPF trigger strategies . . . . . . . . . . . . . . . . . . . 5		3. SPF trigger strategies . . . . . . . . . . . . . . . . . . . 5
	4. SPF delay strategies . . . . . . . . . . . . . . . . . . . . 5		4. SPF delay strategies . . . . . . . . . . . . . . . . . . . . 5
	4.1. Two steps SPF delay . . . . . . . . . . . . . . . . . . . 5		4.1. Two steps SPF delay . . . . . . . . . . . . . . . . . . . 6
	4.2. Exponential backoff . . . . . . . . . . . . . . . . . . . 6		4.2. Exponential backoff . . . . . . . . . . . . . . . . . . . 6
	5. Mixing strategies . . . . . . . . . . . . . . . . . . . . . . 7		5. Mixing strategies . . . . . . . . . . . . . . . . . . . . . . 7
	6. Proposed work items . . . . . . . . . . . . . . . . . . . . . 11		6. Benefits of standardized SPF delay behavior . . . . . . . . . 11
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 13		7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
	10.1. Normative References . . . . . . . . . . . . . . . . . . 13		10.1. Normative References . . . . . . . . . . . . . . . . . . 13
	10.2. Informative References . . . . . . . . . . . . . . . . . 13		10.2. Informative References . . . . . . . . . . . . . . . . . 13
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
	1. Introduction		1. Introduction
	Link State IGP protocols are based on a topology database on which an		Link State IGP protocols are based on a topology database on which
	SPF (Shortest Path First) algorithm like Dijkstra is implemented to		the SPF (Shortest Path First) algorithm is run to find a consistent
	find the optimal routing paths.		set of non-looping routing paths.
	Specifications like IS-IS ([RFC1195]) propose some optimizations of		Specifications like IS-IS ([RFC1195]) propose some optimizations of
	the route computation (See Appendix C.1) but not all the		the route computation (See Appendix C.1) but not all the
	implementations are following those not mandatory optimizations.		implementations follow those non-mandatory optimizations.
	We will call "SPF trigger", the events that would lead to a new SPF		We will call "SPF triggers", the events that would lead to a new SPF
	computation based on the topology.		computation based on the topology.
	Link State IGP protocols, like OSPF ([RFC2328]) and IS-IS		Link State IGP protocols, like OSPF ([RFC2328]) and IS-IS
	([RFC1195]), are using multiple timers to control the router behavior		([RFC1195]), are using multiple timers to control the router behavior
	in case of churn: SPF delay, PRC delay, LSP generation delay, LSP		in case of churn: SPF delay, PRC delay, LSP generation delay, LSP
	flooding delay, LSP retransmission interval...		flooding delay, LSP retransmission interval...
	Some of those timers are standardized in protocol specification, some		Some of those timers (values and behavior) are standardized in
	are not especially the SPF computation related timers.		protocol specifications, while some are not. The SPF computation
			related timers have generally remained unspecified.
	For non standardized timers, implementations are free to implement it		For non standardized timers, implementations are free to implement it
	in any way. For some standardized timer, we can also see that rather		in any way. For some standardized timer, we can also see that rather
	than using static configurable values for such timer, implementations		than using static configurable values for such timer, implementations
	may offer dynamically adjusted timers to help controlling the churn.		may offer dynamically adjusted timers to help controlling the churn.
	We will call "SPF delay", the timer that exists in most		We will call "SPF delay", the timer that exists in most
	implementations that specifies the required delay before running SPF		implementations that specifies the required delay before running SPF
	computation after a SPF trigger is received.		computation after a SPF trigger is received.
	A micro-loop is a packet forwarding loop that may occur transiently		A micro-loop is a packet forwarding loop that may occur transiently
	among two or more routers in a hop-by-hop packet forwarding paradigm.		among two or more routers in a hop-by-hop packet forwarding paradigm.
	We can observe that these micro-loops are formed when two routers do		We can observe that these micro-loops are formed when two routers do
	not update their Forwarding Information Base (FIB) for a certain		not update their Forwarding Information Base (FIB) for a certain
	prefix at the same time. The micro-loop phenomenon is described in		prefix at the same time. The micro-loop phenomenon is described in
	[I-D.ietf-rtgwg-microloop-analysis].		[I-D.ietf-rtgwg-microloop-analysis].
	Some micro-loop mitigation techniques have been defined by IETF (e.g.		Two micro-loop mitigation techniques have been defined by IETF.
	[RFC6976], [I-D.ietf-rtgwg-uloop-delay]) but are not implemented due		[RFC6976] has not been widely implemented, presumably due to the
	to complexity or are not providing a complete mitigation.		complexity of the technique. [I-D.ietf-rtgwg-uloop-delay]) 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		In multi-vendor networks, using different implementations of a link
	state protocol may favor micro-loops creation during the convergence		state protocol may favor micro-loops creation during the convergence
	process due to discrepancies of timers. Service Providers are		process due to discrepancies of timers. Service Providers are
	already aware to use similar timers for all the network as a best		already aware to use similar timers (values and behavior) for all the
	practice, but sometimes it is not possible due to limitations of		network as a best practice, but sometimes it is not possible due to
	implementations.		limitations of implementations.
	This document will present why it sounds important for service		This document will present why it sounds important for service
	providers to have consistent implementations of Link State protocols		providers to have consistent implementations of Link State protocols
	across vendors. We are particularly analyzing the impact of using		across vendors. We are particularly analyzing the impact of using
	different Link State IGP implementations in a single network in		different Link State IGP implementations in a single network in
	regards of micro-loops. The analysis is focused on the SPF triggers		regards of micro-loops. The analysis is focused on the SPF delay
	and the SPF delay algorithm.		algorithm.
	This document is only stating the problem, and defining some work		[I-D.ietf-rtgwg-backoff-algo] defines a solution that satisfies this
	items but its not intended to provide a solution.		problem statement and this document captures the reasoning of the
			provided solution.
	2. Problem statement		2. Problem statement
	A ---- B
	| |		S ---- E
	10 | | 10		| |
	| |		10 | | 10
	C ---- D		| |
	| 2 |		D ---- A
	Px Px		| 2
			Px
	Figure 1 - Network topology suffering from micro-loops		Figure 1 - Network topology suffering from micro-loops
	In Figure 1, A uses primarily the AC link to reach C. When the AC		In Figure 1, S uses primarily the SD link to reach the prefixes
	link fails, the IGP convergence occurs. If A converges before B, A		behind D (Px). When the SD link fails, the IGP convergence occurs.
	will forward the traffic to C through B, but as B as not converged		If S converges before E, S will forward the traffic to Px through E,
	yet, B will loop back traffic to A, leading to a micro-loop.		but as E has not converged yet, E will loop back traffic to S,
			leading to a micro-loop.
	The micro-loop appears due to the asynchronous convergence of nodes		The micro-loop appears due to the asynchronous convergence of nodes
	in a network when an event occurs.		in a network when an event occurs.
	Multiple factors (and combination of these factors) may increase the		Multiple factors (or a combination of these factors) may increase the
	probability for a micro-loop to appear:		probability for a micro-loop to appear:
	o the delay of failure notification: the more B is advised of the		o the delay of failure notification: the more E is advised of the
	failure later than A, the more a micro-loop may have a chance to		failure later than S, the more a micro-loop may have a chance to
	appear.		appear.
	o the SPF delay: most of the implementations supports a delay for		o the SPF delay: most implementations support a delay for the SPF
	the SPF computation to try to catch as many events as possible.		computation to try to catch as many events as possible. If S uses
	If A uses an SPF delay timer of x msec and B uses an SPF delay		an SPF delay timer of x msec and E uses an SPF delay timer of y
	timer of y msec and x < y, B would start converging after A		msec and x < y, E would start converging after S leading to a
	leading to a potential micro-loop.		potential micro-loop.
	o the SPF computation time: mostly a matter of CPU power and		o the SPF computation time: mostly a matter of CPU power and
	optimizations like incremental SPF. If A computes its SPF faster		optimizations like incremental SPF. If S computes its SPF faster
	than B, there is a chance for a micro-loop to appear. CPUs are		than E, there is a chance for a micro-loop to appear. CPUs are
	today faster enough to consider SPF computation time as		today fast enough to consider SPF computation time as negligible
	negligeable (order of msec in a large network).		(on the order of milliseconds in a large network).
	o the SPF computation order: an SPF trigger can be common to		o the SPF computation order: an SPF trigger can be common to
	multiple IGP areas or levels (e.g., IS-IS Level1/Level2) or for		multiple IGP areas or levels (e.g., IS-IS Level1/Level2) or for
	multiple address families with multi-topologies. There is no		multiple address families with multi-topologies. There is no
	specified order for SPF computation today and it is implementation		specified order for SPF computation today and it is implementation
	dependent. In such scenarios, if the order of SPF computation		dependent. In such scenarios, if the order of SPF computation
	done in A and B for each area/level/topology/SPF-algorithm is		done in S and E for each area/level/topology/SPF-algorithm is
	different, there is a possibility for a micro-loop to appear.		different, there is a possibility for a micro-loop to appear.
	o the RIB and FIB prefix insertion speed or ordering: highly		o the RIB and FIB prefix insertion speed or ordering. This is
	implementation dependant.		highly dependent on the implementation.
	This document will focus on analysis SPF delay (and associated		This document will focus on analysis of the SPF delay behavior and
	triggers).		associated triggers.
	3. SPF trigger strategies		3. SPF trigger strategies
	Depending of the change advertised in LSP/LSA, the topology may be		Depending on the change advertised in LSPDU or LSA, the topology may
	affected or not. An implementation may avoid running the SPF		be affected or not. An implementation may avoid running the SPF
	computation (and may only run IP reachability computation instead) if		computation (and may only run IP reachability computation instead) if
	the advertised change is not affecting topology.		the advertised change does not affect the topology.
	Different strategies exists to trigger the SPF computation:		Different strategies exists to trigger the SPF computation:
	1. An implementation may always run a full SPF whatever the change		1. An implementation may always run a full SPF for any type of
	to process.		change.
	2. An implementation may run a full SPF only when required: e.g. if		2. An implementation may run a full SPF only when required. For
	a link fails, a local node will run an SPF for its local LSP		example, if a link fails, a local node will run an SPF for its
	update. If the LSP from the neighbor (describing the same		local LSP update. If the LSP from the neighbor (describing the
	failure) is received after SPF has started, the local node can		same failure) is received after SPF has started, the local node
	decide that a new full SPF is not required as the topology has		can decide that a new full SPF is not required as the topology
	not change.		has not change.
	3. If the topology does not change, an implementation may only		3. If the topology does not change, an implementation may only
	recompute the IP reachability.		recompute the IP reachability.
	As pointed in Section 1, SPF optimizations are not mandatory in		As noted in Section 1, SPF optimizations are not mandatory in
	specifications, leading to multiple strategies to be implemented.		specifications. This has led to the implementation of different
			strategies.
	4. SPF delay strategies		4. SPF delay strategies
	Implementations of link state routing protocols use different		Implementations of link state routing protocols use different
	strategies to delay the SPF computation. We usually see the		strategies to delay the SPF computation. The two most common SPF
	following:		delay behaviors are the following:
	1. Two steps delay.		1. Two phase SPF delay.
	2. Exponential backoff delay.		2. Exponential backoff delay.
	Those behavior will be explained in the next sections.		Those behavior will be explained in the next sections.
	4.1. Two steps SPF delay		4.1. Two steps SPF delay
	The SPF delay is managed by four parameters:		The SPF delay is managed by four parameters:
	o Rapid delay: amount of time to wait before running SPF.		o Rapid delay: amount of time to wait before running SPF, after the
			initial SPF trigger event.
	o Rapid runs: amount of consecutive SPF runs that can use the rapid		o Rapid runs: the number of consecutive SPF runs that can use the
	delay. When the amount is exceeded the delay moves to the slow		rapid delay. When the number is exceeded, the delay moves to the
	delay value .		slow delay value.
	o Slow delay: amount of time to wait before running SPF.		o Slow delay: amount of time to wait before running SPF.
	o Wait time: amount of time to wait without events before going back		o Wait time: amount of time to wait without receiving SPF trigger
	to the rapid delay.		events before going back to the rapid delay.
	Example: Rapid delay = 50msec, Rapid runs = 3, Slow delay = 1sec,		Example: Rapid delay = 50msec, Rapid runs = 3, Slow delay = 1sec,
	Wait time = 2sec		Wait time = 2sec
	SPF delay time		SPF delay time
	^		^
	|		|
	|		|
	SD- | x xx x		SD- | x xx x
	|		|
	|		|
	|		|
	RD- | x x x x		RD- | x x x x
	|		|
	+---------------------------------> Events		+---------------------------------> Events
	| | | | || | |		| | | | || | |
	< wait time >		< wait time >
	Figure 2 - Two steps delay algorithm		Figure 2 - Two phase delay algorithm
	4.2. Exponential backoff		4.2. Exponential backoff
	The algorithm has two modes: the fast mode and the backoff mode. In		The algorithm has two modes: the fast mode and the backoff mode. In
	the fast mode, the SPF delay is usually delayed by a very small		the fast mode, the SPF delay is usually delayed by a very small
	amount of time (fast reaction). When an SPF computation has run in		amount of time (fast reaction). When an SPF computation has run in
	the fast mode, the algorithm automatically moves to the backoff mode		the fast mode, the algorithm automatically moves to the backoff mode
	(a single SPF run is authorized in the fast mode). In the backoff		(a single SPF run is authorized in the fast mode). In the backoff
	mode, the SPF delay is increasing exponentially at each run. When		mode, the SPF delay is increasing exponentially at each run. When
	the network becomes stable, the algorithm moves back to the fast		the network becomes stable, the algorithm moves back to the fast
	skipping to change at page 7, line 36 ¶		skipping to change at page 7, line 45 ¶
	ID |		ID |
	+---------------------------------> Events		+---------------------------------> Events
	| | | | || | |		| | | | || | |
	< wait time >		< wait time >
	FM->BM -------------------->FM		FM->BM -------------------->FM
	Figure 3 - Exponential delay algorithm		Figure 3 - Exponential delay algorithm
	5. Mixing strategies		5. Mixing strategies
	S ---- E		In Figure 1, we consider a flow of packet from S to D. We consider
	| |
	10 | | 10
	| |
	D ---- A
	| 2
	Px
	Figure 4
	In Figure 4, we consider a flow of packet from S to D. We consider
	that S is using optimized SPF triggering (Full SPF is triggered only		that S is using optimized SPF triggering (Full SPF is triggered only
	when necessary), and two steps SPF delay (rapid=150ms,rapid-runs=3,		when necessary), and two steps SPF delay (rapid=150ms,rapid-runs=3,
	slow=1s). As implementation of S is optimized, Partial Reachability		slow=1s). As implementation of S is optimized, Partial Reachability
	Computation (PRC) is available. We consider the same timers as SPF		Computation (PRC) is available. We consider the same timers as SPF
	for delaying PRC. We consider that E is using a SPF trigger strategy		for delaying PRC. We consider that E is using a SPF trigger strategy
	that always compute Full SPF and exponential backoff strategy for SPF		that always compute a Full SPF for any change, and uses the
	delay (start=150ms, inc=150ms, max=1s)		exponential backoff strategy for SPF delay (start=150ms, inc=150ms,
			max=1s)
	We also consider the following sequence of events (note : the time		We also consider the following sequence of events:
	scale does not intend to represent a real router time scale where
	jitters are introduced to all timers) :
	o t0=0 ms: a prefix is declared down in the network. We consider		o t0=0 ms: a prefix is declared down in the network. We consider
	this event to happen at time=0.		this event to happen at time=0.
	o 200ms: the prefix is declared as up.		o 200ms: the prefix is declared as up.
	o 400ms: a prefix is declared down in the network.		o 400ms: a prefix is declared down in the network.
	o 1000ms: S-D link fails.		o 1000ms: S-D link fails.
	skipping to change at page 9, line 39 ¶		skipping to change at page 9, line 36 ¶
	| | | | |		| | | | |
	| | | | |		| | | | |
	| | | | |		| | | | |
	| | | | |		| | | | |
	| 1612ms | | | SPF starts |		| 1612ms | | | SPF starts |
	| 1615ms | | | SPF ends |		| 1615ms | | | SPF ends |
	| 1616ms | | | RIB/FIB starts |		| 1616ms | | | RIB/FIB starts |
	| 1626ms | Micro-loop ends | | RIB/FIB ends |		| 1626ms | Micro-loop ends | | RIB/FIB ends |
	+--------+--------------------+------------------+------------------+		+--------+--------------------+------------------+------------------+
	Route computation event time scale		Table 1 - Route computation when S and E use the different behaviors
			and multiple events appear
	In the table above, we can see that due to discrepancies in the SPF		In the Table 1, we can see that due to discrepancies in the SPF
	management, after multiple events (of a different type), the values		management, after multiple events of a different type, the values of
	of the SPF delay are completely misaligned between nodes leading to		the SPF delay are completely misaligned between node S and node E,
	long micro-loops creation.		leading to the creation of micro-loops.
	The same issue can also appear with only single type of events as		The same issue can also appear with only a single type of event as
	displayed below:		shown below:
	+--------+--------------------+------------------+------------------+		+--------+--------------------+------------------+------------------+
	| Time | Network Event | Router S events | Router E events |		| Time | Network Event | Router S events | Router E events |
	+--------+--------------------+------------------+------------------+		+--------+--------------------+------------------+------------------+
	| t0=0 | Link DOWN | | |		| t0=0 | Link DOWN | | |
	| 10ms | | Schedule SPF (in | Schedule SPF (in |		| 10ms | | Schedule SPF (in | Schedule SPF (in |
	| | | 150ms) | 150ms) |		| | | 150ms) | 150ms) |
	| | | | |		| | | | |
	| | | | |		| | | | |
	| 160ms | | SPF starts | SPF starts |		| 160ms | | SPF starts | SPF starts |
	skipping to change at page 11, line 26 ¶		skipping to change at page 11, line 24 ¶
	| | | | |		| | | | |
	| | | | |		| | | | |
	| 2012ms | | SPF starts | |		| 2012ms | | SPF starts | |
	| 2014ms | | SPF ends | |		| 2014ms | | SPF ends | |
	| 2015ms | | RIB/FIB starts | |		| 2015ms | | RIB/FIB starts | |
	| 2025ms | Micro-loop ends | RIB/FIB ends | |		| 2025ms | Micro-loop ends | RIB/FIB ends | |
	| | | | |		| | | | |
	| | | | |		| | | | |
	+--------+--------------------+------------------+------------------+		+--------+--------------------+------------------+------------------+
	Route computation event time scale		Table 2 - Route computation upon multiple link down events when S and
			E use the different behaviors
	6. Proposed work items
	In order to enhance the current Link State IGP behavior, authors
	would encourage working on standardization of some behaviours.
	Authors are proposing the following work items :
	o Standardize SPF trigger strategy.
	o Standardize computation timer scope: single timer for all
	computation operations, separated timers ...
	o Standardize "slowdown" timer algorithm including its association		6. Benefits of standardized SPF delay behavior
	to a particular timer: authors of this document does not presume
	that the same algorithm must be used for all timers.
	Using the same event sequence as in figure 2, we may expect fewer		Using the same event sequence as in Table 1, we may expect fewer and/
	and/or shorter micro-loops using standardized implementations.		or shorter micro-loops using a standardized SPF delay.
	+--------+--------------------+------------------+------------------+		+--------+--------------------+------------------+------------------+
	| Time | Network Event | Router S events | Router E events |		| Time | Network Event | Router S events | Router E events |
	+--------+--------------------+------------------+------------------+		+--------+--------------------+------------------+------------------+
	| t0=0 | Prefix DOWN | | |		| t0=0 | Prefix DOWN | | |
	| 10ms | | Schedule PRC (in | Schedule SPF (in |		| 10ms | | Schedule PRC (in | Schedule PRC (in |
	| | | 150ms) | 150ms) |		| | | 150ms) | 150ms) |
	| | | | |		| | | | |
	| | | | |		| | | | |
	| 160ms | | PRC starts | PRC starts |		| 160ms | | PRC starts | PRC starts |
	| 161ms | | PRC ends | |		| 161ms | | PRC ends | |
	| 162ms | | RIB/FIB starts | PRC ends |		| 162ms | | RIB/FIB starts | PRC ends |
	| 163ms | | | RIB/FIB starts |		| 163ms | | | RIB/FIB starts |
	| 175ms | | RIB/FIB ends | |		| 175ms | | RIB/FIB ends | |
	| 176ms | | | RIB/FIB ends |		| 176ms | | | RIB/FIB ends |
	| | | | |		| | | | |
	skipping to change at page 13, line 7 ¶		skipping to change at page 12, line 40 ¶
	| | | | |		| | | | |
	| 1160ms | | SPF starts | |		| 1160ms | | SPF starts | |
	| 1161ms | | SPF ends | SPF starts |		| 1161ms | | SPF ends | SPF starts |
	| 1162ms | Micro-loop may | RIB/FIB starts | SPF ends |		| 1162ms | Micro-loop may | RIB/FIB starts | SPF ends |
	| | start from here | | |		| | start from here | | |
	| 1163ms | | | RIB/FIB starts |		| 1163ms | | | RIB/FIB starts |
	| 1175ms | | RIB/FIB ends | |		| 1175ms | | RIB/FIB ends | |
	| 1177ms | Micro-loop ends | | RIB/FIB ends |		| 1177ms | Micro-loop ends | | RIB/FIB ends |
	+--------+--------------------+------------------+------------------+		+--------+--------------------+------------------+------------------+
	Route computation event time scale		Table 3 - Route computation when S and E use the same standardized
			behavior
	As displayed above, there could be some other parameters like router		As displayed above, there could be some other parameters like router
	computation power, flooding timers that may also influence micro-		computation power, flooding timers that may also influence micro-
	loops. In Figure 4, we consider E to be a bit slower than S, leading		loops. In all the examples in this document comparing the SPF timer
	to micro-loop creation. Despite of this, we expect that by aligning		behavior of router S and router E, we have made router E a bit slower
	implementations at least on SPF trigger and SPF delay, service		than router S. This can lead to micro-loops even when both S and E
	provider may reduce the number and the duration of micro-loops.		use a common standardized SPF behavior. However, we expect that by
			aligning implementations of the SPF delay, service providers may
			reduce the number and the duration of micro-loops.
	7. Security Considerations		7. Security Considerations
	This document does not introduce any security consideration.		This document does not introduce any security consideration.
	8. Acknowledgements		8. Acknowledgements
	Authors would like to thank Mike Shand for his useful comments.		Authors would like to thank Mike Shand and Chris Bowers for their
			useful comments.
	9. IANA Considerations		9. IANA Considerations
	This document has no action for IANA.		This document has no action for IANA.
	10. References		10. References
	10.1. Normative References		10.1. Normative References
			[I-D.ietf-rtgwg-backoff-algo]
			Decraene, B., Litkowski, S., Gredler, H., Lindem, A.,
			Francois, P., and C. Bowers, "SPF Back-off Delay algorithm
			for link state IGPs", draft-ietf-rtgwg-backoff-algo-10
			(work in progress), March 2018.
	[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and		[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
	dual environments", RFC 1195, DOI 10.17487/RFC1195,		dual environments", RFC 1195, DOI 10.17487/RFC1195,
	December 1990, <https://www.rfc-editor.org/info/rfc1195>.		December 1990, <https://www.rfc-editor.org/info/rfc1195>.
	[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>.
	[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328,		[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328,
End of changes. 50 change blocks.
	126 lines changed or deleted		121 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/