< draft-litkowski-rtgwg-uloop-delay-00.txt		draft-litkowski-rtgwg-uloop-delay-01.txt >
	Routing Area Working Group S. Litkowski		Routing Area Working Group S. Litkowski
	Internet-Draft B. Decraene		Internet-Draft B. Decraene
	Intended status: Standards Track Orange		Intended status: Standards Track Orange
	Expires: August 19, 2013 P. Francois		Expires: February 20, 2014 P. Francois
	IMDEA Networks/Cisco Systems		IMDEA Networks/Cisco Systems
	February 15, 2013		August 19, 2013
	Microloop prevention by introducting a local convergence delay		Microloop prevention by introducting a local convergence delay
	draft-litkowski-rtgwg-uloop-delay-00		draft-litkowski-rtgwg-uloop-delay-01
	Abstract		Abstract
	This document describes a mechanism for link-state routing protocols		This document describes a mechanism for link-state routing protocols
	to prevent a subset of transient loops during topology changes. It		to prevent a subset of transient loops during topology changes. It
	introduces a two-step convergence by introducing a delay between the		introduces a two-step convergence by introducing a delay between the
	network wide convergence and the node advertising the failure. As		network wide convergence and the node advertising the failure. As
	the network wide convergence is delayed in case of down events, this		the network wide convergence is delayed in case of down events, this
	mechanism can be used for planned maintenance or for unplanned outage		mechanism can be used for planned maintenance or for unplanned outage
	provided a fast reroute mechanism is used in conjunction to convert a		provided a fast reroute mechanism is used in conjunction to convert a
	skipping to change at page 1, line 36 ¶		skipping to change at page 1, line 36 ¶
	mechanism does not provide a complete solution, it is simple and it		mechanism does not provide a complete solution, it is simple and it
	solves an interesting fraction of the transient loops in the analyzed		solves an interesting fraction of the transient loops in the analyzed
	SP topologies.		SP topologies.
	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
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 http://datatracker.ietf.org/drafts/current/.		Drafts is at http://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 August 19, 2013.		This Internet-Draft will expire on February 20, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2013 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
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://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 . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Overview of the solution . . . . . . . . . . . . . . . . . . . 4		2. Overview of the solution . . . . . . . . . . . . . . . . . . 3
	3. Specification . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Specification . . . . . . . . . . . . . . . . . . . . . . . . 3
	3.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4		3.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3
	3.2. Current IGP reactions . . . . . . . . . . . . . . . . . . 5		3.2. Current IGP reactions . . . . . . . . . . . . . . . . . . 4
	3.3. Local delay . . . . . . . . . . . . . . . . . . . . . . . 5		3.3. Local delay . . . . . . . . . . . . . . . . . . . . . . . 4
	3.3.1. Link down event . . . . . . . . . . . . . . . . . . . 5		3.3.1. Link down event . . . . . . . . . . . . . . . . . . . 4
	3.3.2. Link up event . . . . . . . . . . . . . . . . . . . . 6		3.3.2. Link up event . . . . . . . . . . . . . . . . . . . . 5
	4. Use case . . . . . . . . . . . . . . . . . . . . . . . . . . . 6		4. Use case . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	4.1. Applicable case . . . . . . . . . . . . . . . . . . . . . 6		4.1. Applicable case . . . . . . . . . . . . . . . . . . . . . 5
	4.2. Non applicable case . . . . . . . . . . . . . . . . . . . 7		4.2. Non applicable case . . . . . . . . . . . . . . . . . . . 6
	5. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 7		5. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 6
	5.1. Topological applicability . . . . . . . . . . . . . . . . 8		5.1. Topological applicability . . . . . . . . . . . . . . . . 6
	6. Deployment considerations . . . . . . . . . . . . . . . . . . 8		6. Deployment considerations . . . . . . . . . . . . . . . . . . 7
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 9		7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
	10.1. Normative References . . . . . . . . . . . . . . . . . . . 10		10.1. Normative References . . . . . . . . . . . . . . . . . . 8
	10.2. Informative References . . . . . . . . . . . . . . . . . . 10		10.2. Informative References . . . . . . . . . . . . . . . . . 8
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
	1. Introduction		1. Introduction
	In figure 1, upon link AD down event, for the destination A, if D		In figure 1, upon link AD down event, for the destination A, if D
	updates its forwarding entry before C, a transient forwarding loop		updates its forwarding entry before C, a transient forwarding loop
	occurs between C and D. We have a similar loop for link up event, if		occurs between C and D. We have a similar loop for link up event, if
	C updates its forwarding entry A before D.		C updates its forwarding entry A before D.
	A ------ B		A ------ B
	| |		| |
	skipping to change at page 6, line 20 ¶		skipping to change at page 5, line 16 ¶
	Upon an adjacency/link up event, this document introduces the		Upon an adjacency/link up event, this document introduces the
	following change in step 3 where the node SHOULD:		following change in step 3 where the node SHOULD:
	o Firstly build a LSP/LSA with the new adjacency but setting the		o Firstly build a LSP/LSA with the new adjacency but setting the
	metric to MAX_METRIC. It SHOULD flood it but not compute the SPF		metric to MAX_METRIC. It SHOULD flood it but not compute the SPF
	at this time.		at this time.
	o Then build the LSP/LSA with the target metric but SHOULD delay the		o Then build the LSP/LSA with the target metric but SHOULD delay the
	flooding of this LSP/LSA by SPF_TIMER + ULOOP_DELAY_UP_TIMER.		flooding of this LSP/LSA by SPF_TIMER + ULOOP_DELAY_UP_TIMER.
	MAX_METRIC is equal to LSInfinity (0xFFFF) for OSPF and 2^24-2		MAX_METRIC is equal to MaxLinkMetric (0xFFFF) for OSPF and 2^24-2
	(0xFFFFFE) for IS-IS.		(0xFFFFFE) for IS-IS.
	o Then continue with next steps (SPF computation) without waiting		o Then continue with next steps (SPF computation) without waiting
	for the expiration of the above timer. In other word, only the		for the expiration of the above timer. In other word, only the
	flooding of the LSA/LSP is delayed, not the local SPF computation.		flooding of the LSA/LSP is delayed, not the local SPF computation.
	As as result of this addition, routers local to the failure will		As as result of this addition, routers local to the failure will
	converge faster than remote routers.		converge faster than remote routers.
	If this mechanism is used in cooperation with "LDP IGP		If this mechanism is used in cooperation with "LDP IGP
	skipping to change at page 8, line 10 ¶		skipping to change at page 6, line 51 ¶
	5. Applicability		5. Applicability
	Simulations have been run on multiple service provider topologies.		Simulations have been run on multiple service provider topologies.
	So far, only link down event have been tested.		So far, only link down event have been tested.
	5.1. Topological applicability		5.1. Topological applicability
	+----------+------+		+----------+------+
	| Topology | Gain |		| Topology | Gain |
	+----------+------+		+----------+------+
	| T1 | 71% |		| T1 | 71% |
	| T2 | 81% |		| T2 | 81% |
	| T3 | 62% |		| T3 | 62% |
	| T4 | 50% |		| T4 | 50% |
	| T5 | 70% |		| T5 | 70% |
	| T6 | 70% |		| T6 | 70% |
	| T7 | 59% |		| T7 | 59% |
	| T8 | 77% |		| T8 | 77% |
	+----------+------+		+----------+------+
	Table 1: Number of Repair/Dst that may loop		Table 1: Number of Repair/Dst that may loop
	We evaluated the efficiency of the mechanism on eight different		We evaluated the efficiency of the mechanism on eight different
	service provider topologies (different network size, design). The		service provider topologies (different network size, design). The
	benefit is displayed in the table above. The benefit is evaluated as		benefit is displayed in the table above. The benefit is evaluated as
	follows:		follows:
	o We consider a tuple (link A-B, destination D, PLR S, backup		o We consider a tuple (link A-B, destination D, PLR S, backup
	skipping to change at page 9, line 37 ¶		skipping to change at page 8, line 29 ¶
	link. The local delay does not increase the negative consequences as		link. The local delay does not increase the negative consequences as
	if an attacker has the ability to disable or enable an IGP link, it		if an attacker has the ability to disable or enable an IGP link, it
	can already harm the network by creating instability and harm the		can already harm the network by creating instability and harm the
	traffic by creating forwarding packet loss and forwarding loss for		traffic by creating forwarding packet loss and forwarding loss for
	the traffic crossing that link.		the traffic crossing that link.
	8. Acknowledgements		8. Acknowledgements
	We wish to thanks the authors of [I-D.ietf-rtgwg-ordered-fib] for		We wish to thanks the authors of [I-D.ietf-rtgwg-ordered-fib] for
	introducing the concept of ordered convergence: Mike Shand, Stewart		introducing the concept of ordered convergence: Mike Shand, Stewart
	Bryant, Stefano Previdi, Clarence Filsfils, Pierre Francois,and		Bryant, Stefano Previdi, Clarence Filsfils, and Olivier Bonaventure.
	Olivier Bonaventure.
	9. IANA Considerations		9. IANA Considerations
	This document has no actions for IANA.		This document has no actions for IANA.
	10. References		10. References
	10.1. Normative References		10.1. Normative References
	[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, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC5443] Jork, M., Atlas, A., and L. Fang, "LDP IGP		[RFC5443] Jork, M., Atlas, A., and L. Fang, "LDP IGP
	Synchronization", RFC 5443, March 2009.		Synchronization", RFC 5443, March 2009.
	[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, January 2010.		Convergence", RFC 5715, January 2010.
	10.2. Informative References		10.2. Informative References
	[I-D.ietf-rtgwg-microloop-analysis]		[I-D.ietf-rtgwg-microloop-analysis]
	Zinin, A., "Analysis and Minimization of Microloops in		Zinin, A., "Analysis and Minimization of Microloops in
	Link-state Routing Protocols",		Link-state Routing Protocols", draft-ietf-rtgwg-microloop-
	draft-ietf-rtgwg-microloop-analysis-01 (work in progress),		analysis-01 (work in progress), October 2005.
	October 2005.
	[I-D.ietf-rtgwg-ordered-fib]		[I-D.ietf-rtgwg-ordered-fib]
	Shand, M., Bryant, S., Previdi, S., Filsfils, C.,		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 oFIB", draft-ietf-rtgwg-ordered-fib-09		convergence using oFIB", draft-ietf-rtgwg-ordered-fib-12
	(work in progress), January 2013.		(work in progress), May 2013.
	[I-D.ietf-rtgwg-remote-lfa]		[I-D.ietf-rtgwg-remote-lfa]
	Bryant, S., Filsfils, C., Previdi, S., Shand, M., and S.		Bryant, S., Filsfils, C., Previdi, S., Shand, M., and S.
	Ning, "Remote LFA FRR", draft-ietf-rtgwg-remote-lfa-01		Ning, "Remote LFA FRR", draft-ietf-rtgwg-remote-lfa-02
	(work in progress), December 2012.		(work in progress), May 2013.
	[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering		[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
	(TE) Extensions to OSPF Version 2", RFC 3630,		(TE) Extensions to OSPF Version 2", RFC 3630, September
	September 2003.		2003.
	[RFC6571] Filsfils, C., Francois, P., Shand, M., Decraene, B.,		[RFC6571] Filsfils, C., Francois, P., Shand, M., Decraene, B.,
	Uttaro, J., Leymann, N., and M. Horneffer, "Loop-Free		Uttaro, J., Leymann, N., and M. Horneffer, "Loop-Free
	Alternate (LFA) Applicability in Service Provider (SP)		Alternate (LFA) Applicability in Service Provider (SP)
	Networks", RFC 6571, June 2012.		Networks", RFC 6571, June 2012.
	Authors' Addresses		Authors' Addresses
	Stephane Litkowski		Stephane Litkowski
	Orange		Orange
End of changes. 14 change blocks.
	46 lines changed or deleted		45 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/