draft-ietf-grow-bgp-gshut-04.txt		draft-ietf-grow-bgp-gshut-05.txt
	Network Working Group Pierre Francois		Network Working Group Pierre Francois
	Internet-Draft Institute IMDEA Networks		Internet-Draft Institute IMDEA Networks
	Intended status: Informational Bruno Decraene		Intended status: Informational Bruno Decraene
	Expires: April 25, 2013 France Telecom		Expires: August 1, 2014 Orange
	Cristel Pelsser		Cristel Pelsser
	Internet Initiative Japan		Internet Initiative Japan
	Keyur Patel		Keyur Patel
	Clarence Filsfils		Clarence Filsfils
	Cisco Systems		Cisco Systems
	October 22, 2012		January 28, 2014
	Graceful BGP session shutdown		Graceful BGP session shutdown
	draft-ietf-grow-bgp-gshut-04		draft-ietf-grow-bgp-gshut-05
	Abstract		Abstract
	This draft describes operational procedures aimed at reducing the		This draft describes operational procedures aimed at reducing the
	amount of traffic lost during planned maintenances of routers or		amount of traffic lost during planned maintenances of routers or
	links, involving the shutdown of BGP peering sessions.		links, involving the shutdown of BGP peering sessions.
	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 38		skipping to change at page 1, line 38
	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 April 25, 2013.		This Internet-Draft will expire on August 1, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 IETF Trust and the persons identified as the		Copyright (c) 2014 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
	skipping to change at page 6, line 8		skipping to change at page 6, line 8
	Note that the LoC for the inbound traffic of the maintained router,		Note that the LoC for the inbound traffic of the maintained router,
	induced by a lack of alternate path propagation within the iBGP		induced by a lack of alternate path propagation within the iBGP
	topology of a neighboring AS is not under the control of the operator		topology of a neighboring AS is not under the control of the operator
	performing the maintenance. The part of the procedure aimed at		performing the maintenance. The part of the procedure aimed at
	avoiding LoC for incoming paths can thus be applied even if no LoC		avoiding LoC for incoming paths can thus be applied even if no LoC
	are expected for the outgoing paths.		are expected for the outgoing paths.
	4.2. Make before break convergence: g-shut		4.2. Make before break convergence: g-shut
	This section describes configurations and actions to be performed to		This section describes configurations and actions to be performed for
	perform a graceful shutdown procedure for eBGP peering links.		the graceful shutdown of eBGP peering links.
	The goal of this procedure is to let the paths being shutdown		The goal of this procedure is to let the paths being shutdown
	visible, but with a lower LOCAL_PREF value, while alternate paths		visible, but with a lower LOCAL_PREF value, while alternate paths
	spread through the iBGP topology. Instead of withdrawing the path,		spread through the iBGP topology. Instead of withdrawing the path,
	routers of an AS will keep on using it until they become aware of		routers of an AS will keep on using it until they become aware of
	alternate paths.		alternate paths.
	4.2.1. eBGP g-shut		4.2.1. eBGP g-shut
	4.2.1.1. Pre-configuration		4.2.1.1. Pre-configuration
	skipping to change at page 8, line 14		skipping to change at page 8, line 14
	protocols, including static routes).		protocols, including static routes).
	This behavior is equivalent to the recommended behavior for paths		This behavior is equivalent to the recommended behavior for paths
	"redistributed" from eBGP sessions to iBGP sessions in the case of		"redistributed" from eBGP sessions to iBGP sessions in the case of
	the shutdown of an ASBR.		the shutdown of an ASBR.
	5. Forwarding modes and transient forwarding loops during convergence		5. Forwarding modes and transient forwarding loops during convergence
	The g-shut procedure or the solutions improving the availability of		The g-shut procedure or the solutions improving the availability of
	alternate paths, do not change the fact that BGP convergence and the		alternate paths, do not change the fact that BGP convergence and the
	subsequent FIB updates are runned independently on each router of the		subsequent FIB updates are run independently on each router of the
	ASes. If the AS applying the solution does not rely on encapsulation		ASes. If the AS applying the solution does not rely on encapsulation
	to forward packets from the Ingress Border Router to the Egress		to forward packets from the Ingress Border Router to the Egress
	Border Router, then transient forwarding loops and consequent packet		Border Router, then transient forwarding loops and consequent packet
	losses can occur during the convergence process. If zero LoC is		losses can occur during the convergence process. If zero LoC is
	required, encapsulation is required between ASBRs of the AS.		required, encapsulation is required between ASBRs of the AS.
	6. Link Up cases		6. Link Up cases
	We identify two potential causes for transient packet losses upon an		We identify two potential causes for transient packet losses upon an
	eBGP link up event. The first one is local to the g-no-shut		eBGP link up event. The first one is local to the g-no-shut
	skipping to change at page 9, line 19		skipping to change at page 9, line 19
	A typical example for such transient unreachability for a given		A typical example for such transient unreachability for a given
	prefix is the following:		prefix is the following:
	Let's consider 3 route reflectors RR1, RR2, RR3. There is a full		Let's consider 3 route reflectors RR1, RR2, RR3. There is a full
	mesh of iBGP session between them.		mesh of iBGP session between them.
	1. RR1 is initially advertising the current best path to the		1. RR1 is initially advertising the current best path to the
	members of its iBGP RR full-mesh. It propagated that path		members of its iBGP RR full-mesh. It propagated that path
	within its RR full-mesh. RR2 knows only that path towards the		within its RR full-mesh. RR2 knows only that path towards the
	prefix.		prefix.
	2. RR3 receives a new best path orginated by the "g-no-shut"		2. RR3 receives a new best path originated by the "g-no-shut"
	initiator, being one of its RR clients. RR3 selects it as best,		initiator, being one of its RR clients. RR3 selects it as best,
	and propagates an UPDATE within its RR full-mesh, i.e., to RR1		and propagates an UPDATE within its RR full-mesh, i.e., to RR1
	and RR2.		and RR2.
	3. RR1 receives that path, reruns its decision process, and		3. RR1 receives that path, reruns its decision process, and
	picks this new path as best. As a result, RR1 withdraws its		picks this new path as best. As a result, RR1 withdraws its
	previously announced best-path on the iBGP sessions of its RR		previously announced best-path on the iBGP sessions of its RR
	full-mesh.		full-mesh.
	4. If, for any reason, RR3 processes the withdraw generated in		4. If, for any reason, RR3 processes the withdraw generated in
	step 3, before processing the update generated in step 2, RR3		step 3, before processing the update generated in step 2, RR3
	transiently suffers from unreachability for the affected prefix.		transiently suffers from unreachability for the affected prefix.
	skipping to change at page 10, line 38		skipping to change at page 10, line 38
	9. Acknowledgments		9. Acknowledgments
	The authors wish to thank Olivier Bonaventure and Pradosh Mohapatra		The authors wish to thank Olivier Bonaventure and Pradosh Mohapatra
	for their useful comments on this work.		for their useful comments on this work.
	10. References		10. References
	[AddPath] D. Walton, E. Chen, A. Retana, and J. Scudder,		[AddPath] D. Walton, E. Chen, A. Retana, and J. Scudder,
	"Advertisement of Multiple Paths in BGP",		"Advertisement of Multiple Paths in BGP",
	draft-ietf-idr-add-paths-07.txt (work in progress).		draft-ietf-idr-add-paths-09.txt (work in progress).
	[BestExternal]		[BestExternal]
	Marques, P., Fernando, R., Chen, E., Mohapatra, P., and H.		Marques, P., Fernando, R., Chen, E., Mohapatra, P., and H.
	Gredler, "Advertisement of the best-external route to		Gredler, "Advertisement of the best-external route to
	IBGP", draft-ietf-idr-best-external-05.txt.		IBGP", draft-ietf-idr-best-external-05.txt.
	[REQS] Decraene, B., Francois, P., Pelsser, C., Ahmad, Z.,		[REQS] Decraene, B., Francois, P., Pelsser, C., Ahmad, Z.,
	Armengol, A., and T. Takeda, "Requirements for the		Armengol, A., and T. Takeda, "Requirements for the
	graceful shutdown of BGP sessions", RFC 6198.		graceful shutdown of BGP sessions", RFC 6198.
	[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended		[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
	Communities Attribute", RFC 4360, February 2006.		Communities Attribute", RFC 4360, February 2006.
	[EXT_POOL]		[EXT_POOL]
	Decraene, B. and P. Francois, "Assigned BGP extended		Decraene, B. and P. Francois, "Assigned BGP extended
	communities",		communities",
	draft-ietf-idr-reserved-extended-communities-03.		draft-ietf-idr-reserved-extended-communities-06.
	[BGPWKC] "http://www.iana.org/assignments/		[BGPWKC] "http://www.iana.org/assignments/
	bgp-well-known-communities".		bgp-well-known-communities".
	[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.
	Appendix A. Alternative techniques with limited applicability		Appendix A. Alternative techniques with limited applicability
	A few alternative techniques have been considered to provide g-shut		A few alternative techniques have been considered to provide g-shut
	skipping to change at page 12, line 16		skipping to change at page 12, line 16
	Pierre Francois		Pierre Francois
	Institute IMDEA Networks		Institute IMDEA Networks
	Avda. del Mar Mediterraneo, 22		Avda. del Mar Mediterraneo, 22
	Leganese 28918		Leganese 28918
	ES		ES
	Email: pierre.francois@imdea.org		Email: pierre.francois@imdea.org
	Bruno Decraene		Bruno Decraene
	France Telecom		Orange
	38-40 rue du General Leclerc		38-40 rue du General Leclerc
	92794 Issy Moulineaux cedex 9		92794 Issy Moulineaux cedex 9
	FR		FR
	Email: bruno.decraene@orange.com		Email: bruno.decraene@orange.com
	Cristel Pelsser		Cristel Pelsser
	Internet Initiative Japan		Internet Initiative Japan
	Jinbocho Mitsui Bldg.		Jinbocho Mitsui Bldg.
	1-105 Kanda Jinbo-cho		1-105 Kanda Jinbo-cho
End of changes. 11 change blocks.
	12 lines changed or deleted		12 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/