draft-ietf-grow-bgp-graceful-shutdown-requirements-05.txt		draft-ietf-grow-bgp-graceful-shutdown-requirements-06.txt
	skipping to change at page 1, line 15		skipping to change at page 1, line 15
	Intended status: Informational P. Francois		Intended status: Informational P. Francois
	UCL		UCL
	C. Pelsser		C. Pelsser
	IIJ		IIJ
	Z. Ahmad		Z. Ahmad
	Orange Business Services		Orange Business Services
	A. J. Elizondo Armengol		A. J. Elizondo Armengol
	Telefonica I+D		Telefonica I+D
	T. Takeda		T. Takeda
	NTT		NTT
	October 11, 2010		October 22, 2010
	Requirements for the graceful shutdown of BGP sessions		Requirements for the graceful shutdown of BGP sessions
	draft-ietf-grow-bgp-graceful-shutdown-requirements-05.txt		draft-ietf-grow-bgp-graceful-shutdown-requirements-06.txt
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF in full conformance with the
	provisions of BCP 78 and BCP 79. This document may contain material		provisions of BCP 78 and BCP 79. This document may contain material
	from IETF Documents or IETF Contributions published or made publicly		from IETF Documents or IETF Contributions published or made publicly
	available before November 10, 2008. The person(s) controlling the		available before November 10, 2008. The person(s) controlling the
	copyright in some of this material may not have granted the IETF		copyright in some of this material may not have granted the IETF
	Trust the right to allow modifications of such material outside the		Trust the right to allow modifications of such material outside the
	IETF Standards Process. Without obtaining an adequate license from		IETF Standards Process. Without obtaining an adequate license from
	skipping to change at page 1, line 51		skipping to change at page 1, line 51
	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."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on April 09, 2011.		This Internet-Draft will expire on April 20, 2011.
	Requirements for the graceful shutdown of BGP sessions		Internet-Draft Requirements for the graceful shutdown of BGP sessions
	Copyright Notice		Copyright Notice
	Copyright (c) 2010 IETF Trust and the persons identified as the		Copyright (c) 2010 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
	skipping to change at page 2, line 49		skipping to change at page 2, line 49
	1. Conventions used in this document...........................3		1. Conventions used in this document...........................3
	2. Introduction................................................3		2. Introduction................................................3
	3. Problem statement...........................................4		3. Problem statement...........................................4
	3.1. Example of undesirable BGP routing behavior.................4		3.1. Example of undesirable BGP routing behavior.................4
	3.2. Causes of packet loss.......................................5		3.2. Causes of packet loss.......................................5
	4. Terminology.................................................6		4. Terminology.................................................6
	5. Goals and requirements......................................7		5. Goals and requirements......................................7
	6. Reference Topologies........................................9		6. Reference Topologies........................................9
	6.1. E-BGP topologies............................................9		6.1. E-BGP topologies............................................9
	6.2. I-BGP topologies...........................................11		6.2. I-BGP topologies...........................................11
	7. Security Considerations....................................14		7. Security Considerations....................................15
	8. IANA Considerations........................................15		8. IANA Considerations........................................16
	9. References.................................................15		9. References.................................................16
	9.1. Normative References.......................................15		9.1. Normative References.......................................16
	9.2. Informative References.....................................15		9.2. Informative References.....................................16
	10. Acknowledgments............................................15		10. Acknowledgments............................................17
	11. Author's Addresses.........................................16		11. Author's Addresses.........................................17
	Requirements for the graceful shutdown of BGP sessions		Internet-Draft Requirements for the graceful shutdown of BGP sessions
	1. Conventions used in this document		1. Conventions used in this document
	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 RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	2. Introduction		2. Introduction
	The Border Gateway Protocol(BGP) [BGP-4] is heavily used in Service		The Border Gateway Protocol(BGP) [BGP-4] is heavily used in Service
	skipping to change at page 3, line 36		skipping to change at page 3, line 36
	is available in the Autonomous System (AS), it should be made		is available in the Autonomous System (AS), it should be made
	possible to reroute the customer or peer traffic on this backup path		possible to reroute the customer or peer traffic on this backup path
	before the BGP session(s) is/are torn down, the nominal path		before the BGP session(s) is/are torn down, the nominal path
	withdrawn and the forwarding is interrupted on the nominal path.		withdrawn and the forwarding is interrupted on the nominal path.
	The requirements also cover the subsequent re-establishment of the		The requirements also cover the subsequent re-establishment of the
	BGP session as even this "UP" case can currently trigger route loss		BGP session as even this "UP" case can currently trigger route loss
	and thus traffic loss at some routers.		and thus traffic loss at some routers.
	Currently, BGP [BGP-4] and MP-BGP [MP-BGP] do not include any		Currently, BGP [BGP-4] and MP-BGP [MP-BGP] do not include any
	operation to gracefully withdraw a prefix while traffic toward that		operation to gracefully advertise or withdraw a prefix while traffic
	prefix could still be correctly forwarded. When a BGP session is		toward that prefix could still be correctly forwarded using the old
	taken down, BGP behaves as if it was a sudden link or router failure		path. When a BGP session is taken down, BGP behaves as if it was a
	and withdraws the prefixes learnt over that session, which may		sudden link or router failure and withdraws the prefixes learnt over
	trigger traffic loss. There is no mechanism to advertise to its BGP		that session, which may trigger traffic loss. There is no mechanism
	peers that the prefix will soon be unreachable, while still being		to advertise to its BGP peers that the prefix will soon be
	reachable. When applicable, such mechanism would reduce or prevent		unreachable, while still being reachable. When applicable, such
	traffic loss. It would typically be applicable in case of a		mechanism would reduce or prevent traffic loss. It would typically be
	maintenance operation requiring the shutdown of a forwarding		applicable in case of a maintenance operation requiring the shutdown
	resource. Typical examples would be a link or line card maintenance,		of a forwarding resource. Typical examples would be a link or line
	replacement or upgrade. It may also be applicable for a software		card maintenance, replacement or upgrade. It may also be applicable
	upgrade as it may involve a firmware reset on the line cards and		for a software upgrade as it may involve a firmware reset on the line
	hence forwarding interruption.		cards and hence forwarding interruption.
	The introduction of Route Reflectors as per [RR] to solve scalability		The introduction of Route Reflectors as per [RR] to solve scalability
	issues bound to IBGP full-meshes has worsened the duration of routing		issues bound to IBGP full-meshes has worsened the duration of routing
	convergence as some route reflectors may hide the back up path. Thus		convergence as some route reflectors may hide the back up path. Thus
	depending on RR topology more IBGP hops may be involved in the IBGP		depending on RR topology more IBGP hops may be involved in the IBGP
	convergence.		convergence.
	Requirements for the graceful shutdown of BGP sessions		Internet-Draft Requirements for the graceful shutdown of BGP sessions
	Note that these planned maintenance operations cannot be addressed by		Note that these planned maintenance operations cannot be addressed by
	Graceful Restart extensions [GR] as GR only applies when the		Graceful Restart extensions [GR] as GR only applies when the
	forwarding is preserved during the control plane restart. On the		forwarding is preserved during the control plane restart. On the
	contrary, Graceful Shutdown applies when the forwarding is		contrary, Graceful Shutdown applies when the forwarding is
	interrupted.		interrupted.
	Note also that some protocols are already considering such graceful		Note also that some protocols are already considering such graceful
	shutdown procedure (e.g. GMPLS in [RFC5817]).		shutdown procedure (e.g. GMPLS in [RFC5817]).
	A successful approach of such mechanism should minimize the loss of		A successful approach of such mechanism should minimize the loss of
	skipping to change at page 4, line 39		skipping to change at page 4, line 39
	the traffic that was directed towards the removed next-hops may be		the traffic that was directed towards the removed next-hops may be
	lost until the end of the BGP convergence. As it is a planned		lost until the end of the BGP convergence. As it is a planned
	operation, a make before break solution should be made possible.		operation, a make before break solution should be made possible.
	As maintenance operations are frequent in large networks		As maintenance operations are frequent in large networks
	[Reliability], the global availability of the network is		[Reliability], the global availability of the network is
	significantly impaired by this BGP maintenance issue.		significantly impaired by this BGP maintenance issue.
	3.1. Example of undesirable BGP routing behavior		3.1. Example of undesirable BGP routing behavior
	To illustrate these problems, let us consider the following example		To illustrate these problems, let us consider the following simple
	where one customer router "CUST" is dual-attached to two SP routers		example where one customer router "CUST" is dual-attached to two SP
	"ASBR1" and "ASBR2".		routers "ASBR1" and "ASBR2".
	ASBR1 and ASBR2 are in the same AS and owned by the same service		ASBR1 and ASBR2 are in the same AS and owned by the same service
	provider. Both are IBGP client of the route reflector R1.		provider. Both are IBGP client of the route reflector R1.
	Requirements for the graceful shutdown of BGP sessions		Internet-Draft Requirements for the graceful shutdown of BGP sessions
	'		'
	AS1 ' AS2		AS1 ' AS2
	'		'
	/-----------ASBR1---		/-----------ASBR1---
	/ \		/ \
	/ \		/ \
	CUST R1		CUST R1
	\ /		\ /
	skipping to change at page 6, line 5		skipping to change at page 6, line 5
	When multiple BGP routers are involved and plenty of prefixes are		When multiple BGP routers are involved and plenty of prefixes are
	affected, the recovery process can take longer than applications		affected, the recovery process can take longer than applications
	requirements.		requirements.
	3.2. Causes of packet loss		3.2. Causes of packet loss
	The loss of packets during the maintenance has two main causes:		The loss of packets during the maintenance has two main causes:
	- lack of an alternate path on some routers,		- lack of an alternate path on some routers,
	- transient routing inconsistency.		- transient routing inconsistency.
	Requirements for the graceful shutdown of BGP sessions		Internet-Draft Requirements for the graceful shutdown of BGP sessions
	Some routers may lack an alternate path because another router is		Some routers may lack an alternate path because another router is
	hiding the backup path. This router can be:		hiding the backup path. This router can be:
	- a route reflector only propagating its best path;		- a route reflector only propagating its best path;
	- the backup ASBR not advertising the backup path because it prefers		- the backup ASBR not advertising the backup path because it prefers
	the nominal path.		the nominal path.
	This lack of knowledge of the alternate path is the first target of		This lack of knowledge of the alternate path is the first target of
	this requirement draft.		this requirement draft.
	Transient routing inconsistencies happen during IBGP convergence		Transient routing inconsistencies happen during IBGP convergence
	because all routers are not updating their RIB at the same time. This		because all routers are not updating their RIB and FIB at the same
	can lead to forwarding loops and then packet drops. The duration of		time. This can lead to forwarding loops and then packet drops. The
	these transient micro-loops may depend on the IBGP topology (e.g.		duration of these transient micro-loops may depend on the IBGP
	number of Route Reflectors between ingress and egress ASBR),		topology (e.g. number of Route Reflectors between ingress and egress
	implementation differences among router platforms (e.g. speed to		ASBR), implementation differences among router platforms (e.g. speed
	update the RIB and FIB, possibly the order in which prefixes are		to update the RIB and FIB, possibly the order in which prefixes are
	modified), forwarding mode (hop by hop IP forwarding versus		modified), forwarding mode (hop by hop IP forwarding versus
	tunneling).		tunneling).
	Transient forwarding loops can be avoided by performing only one IP		Transient forwarding loops can be avoided by performing only one IP
	lookup on BGP routes in each AS and by using tunnels (e.g. MPLS LSP)		lookup on BGP routes in each AS and by using tunnels (e.g. MPLS LSP)
	to send packets between ASBRs. As such, BGP/MPLS VPNs should be		to send packets between ASBRs. As such, BGP/MPLS VPNs should be
	immune to such micro forwarding loops.		immune to such micro forwarding loops.
	4. Terminology		4. Terminology
	g-shut: Graceful SHUTdown. A method for explicitly notifying the BGP		g-shut: Graceful SHUTdown. A method for explicitly notifying the BGP
	skipping to change at page 7, line 5		skipping to change at page 7, line 5
	Affected router: a router reaching an affected prefix via a		Affected router: a router reaching an affected prefix via a
	peering link undergoing maintenance.		peering link undergoing maintenance.
	Initiator AS: the autonomous system of the g-shut initiator		Initiator AS: the autonomous system of the g-shut initiator
	router.		router.
	Neighbor AS(es): the autonomous system(s) of the g-shut neighbor		Neighbor AS(es): the autonomous system(s) of the g-shut neighbor
	router(s).		router(s).
	Requirements for the graceful shutdown of BGP sessions		Internet-Draft Requirements for the graceful shutdown of BGP sessions
	5. Goals and requirements		5. Goals and requirements
	When a BGP session of the router under maintenance is shut down, the		When a BGP session of the router under maintenance is shut down, the
	router removes the routes and then triggers the BGP convergence on		router removes the routes and then triggers the BGP convergence on
	its BGP peers. The goal of BGP graceful shutdown is to initiate the		its BGP peers. The goal of BGP graceful shutdown is to initiate the
	BGP convergence to find the alternate paths before the nominal paths		BGP convergence to find the alternate paths before the nominal paths
	are removed. As a result, before the nominal BGP session is shut		are removed. As a result, before the nominal BGP session is shut
	down, all routers learn and use the alternate paths. Then the nominal		down, all routers learn and use the alternate paths. Then the nominal
	BGP session can be shut down.		BGP session can be shut down.
	skipping to change at page 7, line 50		skipping to change at page 7, line 50
	simplicity of implementation and operation as shown in some of the		simplicity of implementation and operation as shown in some of the
	following requirements.		following requirements.
	b) An Internet wide convergence is OPTIONAL. However if the		b) An Internet wide convergence is OPTIONAL. However if the
	initiator AS and the neighbor AS(es) have a backup path, they SHOULD		initiator AS and the neighbor AS(es) have a backup path, they SHOULD
	be able to gracefully converge before the nominal path is shut down.		be able to gracefully converge before the nominal path is shut down.
	c) The proposed solution SHOULD be applicable to any kind of BGP		c) The proposed solution SHOULD be applicable to any kind of BGP
	sessions (EBGP, IBGP, IBGP route reflector client, EBGP		sessions (EBGP, IBGP, IBGP route reflector client, EBGP
	confederations, EBGP multi hop, MultiProtocol BGP extension...) and		confederations, EBGP multi hop, MultiProtocol BGP extension...) and
	any address family. If a BGP implementation allows closing a sub-set		any address family. If a BGP implementation allows closing or
	of AFIs carried in a MP-BGP session, this mechanism MAY be applicable		enabling a sub-set of AFIs carried in a MP-BGP session, this
	to this sub-set of AFIs.		mechanism MAY be applicable to this sub-set of AFIs.
	Depending on the session type (EBGP, IBGP...), there may be some
	variations in the proposed solution in order to fulfill the
	requirements.
	Requirements for the graceful shutdown of BGP sessions		Depending on the kind of session, there may be some variations in the
			proposed solution in order to fulfill the requirements.
	The following cases should be handled in priority:		The following cases should be handled in priority:
			Internet-Draft Requirements for the graceful shutdown of BGP sessions
	- The shutdown of an inter-AS link and therefore the shutdown of an		- The shutdown of an inter-AS link and therefore the shutdown of an
	eBGP session;		eBGP session;
	- The shutdown of an AS Border Router and therefore the shutdown of		- The shutdown of an AS Border Router and therefore the shutdown of
	all its BGP sessions.		all its BGP sessions.
	Service Providers and platforms implementing a graceful shutdown		Service Providers and platforms implementing a graceful shutdown
	solution should note that in BGP/MPLS VPN as per [VPN], the PE-CE		solution should note that in BGP/MPLS VPN as per [VPN], the PE-CE
	routing can be performed by other protocols than BGP (e.g. static		routing can be performed by other protocols than BGP (e.g. static
	routes, RIPv2, OSPF, IS-IS...). This is out of scope of this		routes, RIPv2, OSPF, IS-IS). This is out of scope of this document.
	document.
	d) The proposed solution SHOULD NOT change the BGP convergence		d) The proposed solution SHOULD NOT change the BGP convergence
	behavior for the ASes exterior to the maintenance process, namely		behavior for the ASes exterior to the maintenance process, namely
	ASes other than the initiator AS and it(s) neighbor AS(es).		ASes other than the initiator AS and it(s) neighbor AS(es).
	e) An incremental deployment on a per AS or per BGP session basis		e) An incremental deployment on a per AS or per BGP session basis
	SHOULD be made possible. In case of partial deployment the proposed		MUST be made possible. In case of partial deployment the proposed
	solution SHOULD incrementally improve the maintenance process. The		solution SHOULD incrementally improve the maintenance process.
	solution SHOULD bring improvements even when one of the two ASes does		It should be noted that in an inter domain relation, one AS may have
	not support graceful shutdown. In particular, large Service Providers		more incentive to use graceful shutdown than the other. Similarly, in
	may not be able to upgrade all of the deployed customer premises		a BGP/MPLS VPN environment, it's much easier to upgrade the PE
	access routers (CPE).		routers than the CE mainly because there is at least an order of
			magnitude more CE and CE locations than PE and PE locations. As a
			consequence, when splitting the cost of the solution between the g-
			shut initiator and the g-shut neighbour the solution SHOULD favour a
			low cost solution on the neighbour AS side in order to reduce the
			impact on the g-shut neighbour. Impact should be understood as a
			generic term which includes first hardware, then software, then
			configuration upgrade..
	f) Redistribution or advertisement of (static) IP routes into BGP		f) Redistribution or advertisement of (static) IP routes into BGP
	SHOULD also be covered.		SHOULD also be covered.
	g) The proposed solution MAY be designed in order to avoid		g) The proposed solution MAY be designed in order to avoid
	transient forwarding loops. Indeed, forwarding loops increase packet		transient forwarding loops. Indeed, forwarding loops increase packet
	transit delay and may lead to link saturation.		transit delay and may lead to link saturation.
	h) The specific procedure SHOULD end when the BGP session is closed		h) The specific procedure SHOULD end when the BGP session is closed
	following the g-shut and once the BGP session is gracefully opened		following the g-shut and once the BGP session is gracefully opened
	skipping to change at page 8, line 52		skipping to change at page 9, line 5
	The duration of the g-shut procedure, and hence the time before the		The duration of the g-shut procedure, and hence the time before the
	BGP session is safely closed SHOULD be discussed by the solution		BGP session is safely closed SHOULD be discussed by the solution
	document. Examples of possible solutions are the use of a pre-		document. Examples of possible solutions are the use of a pre-
	configured timer, of a message to signal the end of the BGP		configured timer, of a message to signal the end of the BGP
	convergence or monitoring the traffic on the g-shut interface...		convergence or monitoring the traffic on the g-shut interface...
	i) The solution SHOULD be simple and simple to operate. Hence it		i) The solution SHOULD be simple and simple to operate. Hence it
	MAY only cover a subset of the cases. (As a consequence, most of the		MAY only cover a subset of the cases. (As a consequence, most of the
	above requirements are expressed as "SHOULD" rather than "MUST")		above requirements are expressed as "SHOULD" rather than "MUST")
			Internet-Draft Requirements for the graceful shutdown of BGP sessions
	The metrics to evaluate and compare the proposed solutions are, in		The metrics to evaluate and compare the proposed solutions are, in
	decreasing order of importance:		decreasing order of importance:
	- The duration of the remaining loss of connectivity when the BGP		- The duration of the remaining loss of connectivity when the BGP
	session is brought down or up		session is brought down or up
	Requirements for the graceful shutdown of BGP sessions
	- The applicability to a wide range of BGP and network topologies,		- The applicability to a wide range of BGP and network topologies,
	especially those described in section 6;		especially those described in section 6;
	- The simplicity;		- The simplicity;
	- The duration of transient forwarding loops;		- The duration of transient forwarding loops;
	- The additional load introduced in BGP (eg BGP messages sent to peer		- The additional load introduced in BGP (eg BGP messages sent to peer
	routers, peer ASes, the Internet).		routers, peer ASes, the Internet).
	6. Reference Topologies		6. Reference Topologies
	In order to benchmark the proposed solutions, some typical BGP		In order to benchmark the proposed solutions, some typical BGP
	skipping to change at page 9, line 40		skipping to change at page 10, line 5
	We describe here some frequent EBGP topologies that SHOULD be		We describe here some frequent EBGP topologies that SHOULD be
	supported by the solution.		supported by the solution.
	6.1.1. 1 ASBR in AS1 connected to two ASBRs in the neighboring AS2		6.1.1. 1 ASBR in AS1 connected to two ASBRs in the neighboring AS2
	In this topology we have an asymmetric protection scheme between		In this topology we have an asymmetric protection scheme between
	AS1 and AS2:		AS1 and AS2:
	- On AS2 side, two different routers are used to connect to AS1.		- On AS2 side, two different routers are used to connect to AS1.
	- On AS1 side, one single router with two BGP sessions is used.		- On AS1 side, one single router with two BGP sessions is used.
			Internet-Draft Requirements for the graceful shutdown of BGP sessions
	'		'
	AS1 ' AS2		AS1 ' AS2
	'		'
	/----------- ASBR2.1		/----------- ASBR2.1
	/ '		/ '
	/ '		/ '
	ASBR1.1 '		ASBR1.1 '
	\ '		\ '
	\ '		\ '
	\----------- ASBR2.2		\----------- ASBR2.2
	'		'
	'		'
	AS1 ' AS2		AS1 ' AS2
	'		'
	Figure 2. EBGP topology with redundant ASBR in one of the AS.		Figure 2. EBGP topology with redundant ASBR in one of the AS.
	The requirements of section 5 should be applicable to:		The requirements of section 5 should be applicable to:
	Requirements for the graceful shutdown of BGP sessions
	- Maintenance of one of the routers of AS2;		- Maintenance of one of the routers of AS2;
	- Maintenance of one link between AS1 and AS2, performed either		- Maintenance of one link between AS1 and AS2, performed either
	on an AS1 or AS2 router.		on an AS1 or AS2 router.
	Note that in case of maintenance of the whole router, all its BGP		Note that in case of maintenance of the whole router, all its BGP
	session needs to be shutdown.		sessions need to be gracefully shutdown at the beginning of the
			maintenance and gracefully brought up at the end of the
			maintenance.
	6.1.2. 2 ASBRs in AS1 connected to 2 ASBRs in AS2		6.1.2. 2 ASBRs in AS1 connected to 2 ASBRs in AS2
	In this topology we have a symmetric protection scheme between		In this topology we have a symmetric protection scheme between
	AS1 and AS2: on both sides, two different routers are used to		AS1 and AS2: on both sides, two different routers are used to
	connect AS1 to AS2.		connect AS1 to AS2.
	'		'
	AS1 ' AS2		AS1 ' AS2
	'		'
	skipping to change at page 10, line 38		skipping to change at page 11, line 4
	'		'
	ASBR1.2----------- ASBR2.2		ASBR1.2----------- ASBR2.2
	'		'
	AS1 ' AS2		AS1 ' AS2
	'		'
	Figure 3. EBGP topology with redundant ASBR in both ASes		Figure 3. EBGP topology with redundant ASBR in both ASes
	The requirements of section 5 should be applicable to:		The requirements of section 5 should be applicable to:
	- Maintenance of any of the ASBR routers (in AS1 or AS2);		- Maintenance of any of the ASBR routers (in AS1 or AS2);
			Internet-Draft Requirements for the graceful shutdown of BGP sessions
	- Maintenance of one link between AS1 and AS2 performed either on		- Maintenance of one link between AS1 and AS2 performed either on
	an AS1 or AS2 router.		an AS1 or AS2 router.
	6.1.3. 2 ASBRs in AS2 each connected to two different ASes		6.1.3. 2 ASBRs in AS2 each connected to two different ASes
	In this topology at least three ASes are involved. Depending on		In this topology at least three ASes are involved. Depending on
	which routes are exchanged between these ASes, some protection		which routes are exchanged between these ASes, some protection
	for some of the traffic may be possible.		for some of the traffic may be possible.
	Requirements for the graceful shutdown of BGP sessions
	'		'
	AS1 ' AS2		AS1 ' AS2
	'		'
	ASBR1.1----------- ASBR2.1		ASBR1.1----------- ASBR2.1
	| '		| '
	| '		| '
	'''''|''''''''''		'''''|''''''''''
	| '		| '
	| '		| '
	ASBR3.1----------- ASBR2.2		ASBR3.1----------- ASBR2.2
	skipping to change at page 11, line 36		skipping to change at page 12, line 5
	For instance if ASBR2.2 requires a maintenance affecting ASBR3.1,		For instance if ASBR2.2 requires a maintenance affecting ASBR3.1,
	then ASBR3.1 will be notified. However we do not require for ASBR1.1		then ASBR3.1 will be notified. However we do not require for ASBR1.1
	to be notified of the maintenance of the eBGP session between		to be notified of the maintenance of the eBGP session between
	ASBR3.1-ASBR2.2.		ASBR3.1-ASBR2.2.
	6.2. IBGP topologies		6.2. IBGP topologies
	We describe here some frequent IBGP topologies that SHOULD be		We describe here some frequent IBGP topologies that SHOULD be
	supported by the solution.		supported by the solution.
			Internet-Draft Requirements for the graceful shutdown of BGP sessions
	6.2.1. IBGP Full-Mesh		6.2.1. IBGP Full-Mesh
	In this topology we have a full mesh of iBGP sessions:		In this topology we have a full mesh of iBGP sessions:
	P1 ------ P2		P1 ------ P2
	| \ / |		| \ / |
	| \ / |		| \ / |
	| \ / | AS1		| \ / | AS1
	| / \ |		| / \ |
	| / \ |		| / \ |
	ASBR1.1---ASBR1.2		ASBR1.1---ASBR1.2
	\ /		\ /
	\ /		\ /
	''''''\''''/''''''''''''		''''''\''''/''''''''''''
	\ / AS2		\ / AS2
	ASBR2.1		ASBR2.1
	Figure 5. IBGP full mesh		Figure 5. IBGP full mesh
	When the session between ASBR1.1 and ASBR2.1 undergoes		When the session between ASBR1.1 and ASBR2.1 is gracefully
	maintenance, it is required that all IBGP peers of ASBR1.1 reroute		shutdown, it is required that all routers of AS1 reroute traffic
			to ASBR1.2 before the session between ASBR1.1 and ASBR2.1 is shut
	Requirements for the graceful shutdown of BGP sessions		down.
			Symmetrically, when the session between ASBR1.1 and ASBR2.1 is
	traffic to ASBR1.2 before the session between ASBR1.1 and ASBR2.1		gracefully brought up, it is required that all routers of AS1
	is shut down.		preferring ASBR1.1 over ASBR1.2 reroute traffic to ASBR1.1 before
			the less preferred path trough ASBR1.2 is possibly withdrawn.
	6.2.2. Route Reflector		6.2.2. Route Reflector
	In this topology, route reflectors are used to limit the number of		In this topology, route reflectors are used to limit the number of
	IBGP sessions.		IBGP sessions. There is a single level of route reflectors and the
			route reflectors are fully meshed.
			Internet-Draft Requirements for the graceful shutdown of BGP sessions
	P1 RR----- P2 RR		P1 RR----- P2 RR
	| \ / |		| \ / |
	| \ / |		| \ / |
	| \ / | AS1		| \ / | AS1
	| \ / |		| \ / |
	| / \ |		| / \ |
	| / \ |		| / \ |
	| / \ |		| / \ |
	ASBR1.1 ASBR1.2		ASBR1.1 ASBR1.2
	\ /		\ /
	\ /		\ /
	''''''\''''''/''''''''''''		''''''\''''''/''''''''''''
	\ /		\ /
	\ / AS2		\ / AS2
	ASBR2.1		ASBR2.1
	Figure 6. Route Reflector		Figure 6. Route Reflector
	When the session between ASBR1.1 and ASBR2.1 undergoes		When the session between ASBR1.1 and ASBR2.1 is gracefully
	maintenance, it is required that all BGP routers of AS1 reroute		shutdown, it is required that all BGP routers of AS1 reroute
	traffic to ASBR1.2 before the session between ASBR1.1 and ASBR2.1		traffic to ASBR1.2 before the session between ASBR1.1 and ASBR2.1
	is shut down.		is shut down.
			Symmetrically, when the session between ASBR1.1 and ASBR2.1 is
			gracefully brought up, it is required that all routers of AS1
			preferring ASBR1.1 over ASBR1.2 reroute traffic to ASBR1.1 before
			the less preferred path trough ASBR1.2 is possibly withdrawn.
	6.2.3. hierarchical Route Reflector		6.2.3. hierarchical Route Reflector
	In this topology, hierarchical route reflectors are used to limit		In this topology, hierarchical route reflectors are used to limit
	the number of IBGP sessions.		the number of IBGP sessions. There could me more than levels of
			route reflectors and the top level route reflectors are fully
			meshed.
	Requirements for the graceful shutdown of BGP sessions		Internet-Draft Requirements for the graceful shutdown of BGP sessions
	P1/hRR -------- P2/hRR		P1/hRR -------- P2/hRR
	| |		| |
	| |		| |
	| | AS1		| | AS1
	| |		| |
	| |		| |
	P3/RR P4/RR		P3/RR P4/RR
	| |		| |
	skipping to change at page 13, line 30		skipping to change at page 14, line 30
	ASBR1.1 ASBR1.2		ASBR1.1 ASBR1.2
	\ /		\ /
	\ /		\ /
	''''''\'''''''''/''''''''''''		''''''\'''''''''/''''''''''''
	\ /		\ /
	\ / AS2		\ / AS2
	ASBR2.1		ASBR2.1
	Figure 7. Hierarchical Route Reflector		Figure 7. Hierarchical Route Reflector
	When the session between ASBR1.1 and ASBR2.1 undergoes		When the session between ASBR1.1 and ASBR2.1 is gracefully
	maintenance, it is required that all BGP routers of AS1 reroute		shutdown, it is required that all BGP routers of AS1 reroute
	traffic to ASBR1.2 before the session between ASBR1.1 and ASBR2.1		traffic to ASBR1.2 before the session between ASBR1.1 and ASBR2.1
	is shut down.		is shut down.
			Symmetrically, when the session between ASBR1.1 and ASBR2.1 is
			gracefully brought up, it is required that all routers of AS1
			preferring ASBR1.1 over ASBR1.2 reroute traffic to ASBR1.1 before
			the less preferred path trough ASBR1.2 is possibly withdrawn.
	6.2.4. Confederations		6.2.4. Confederations
	In this topology, a confederation of ASs is used to limit the number		In this topology, a confederation of ASs is used to limit the number
	of IBGP sessions. Moreover, RRs may be present in the member ASs of		of IBGP sessions. Moreover, RRs may be present in the member ASs of
	the confederation.		the confederation.
	Confederations may be run with different sub-options. Regarding the		Confederations may be run with different sub-options. Regarding the
	IGP, each member AS can run its own IGP or they can all share the		IGP, each member AS can run its own IGP or they can all share the
	same IGP. Regarding BGP, local_pref may or may not cross the member		same IGP. Regarding BGP, local_pref may or may not cross the member
	AS boundaries.		AS boundaries.
	A solution should support the shutdown of EBGP sessions between		A solution should support the graceful shutdown and graceful bring up
	member-ASs in the confederation in addition to the shutdown of EBGP		of EBGP sessions between member-ASs in the confederation in addition
	sessions between a member-AS and an AS outside of the confederation.		to the graceful shutdown and graceful bring up of EBGP sessions
			between a member-AS and an AS outside of the confederation.
	Requirements for the graceful shutdown of BGP sessions		Internet-Draft Requirements for the graceful shutdown of BGP sessions
	ASBR1C.1 ---------- ASBR1C.2		ASBR1C.1 ---------- ASBR1C.2
	| |		| |
	| |		| |
	| AS1C |		| AS1C |
	| |		| |
	| |		| |
	"""|"""""""""""""""""""|"""		"""|"""""""""""""""""""|"""
	| " |		| " |
	ASBR1A.2 " ASBR1B.2		ASBR1A.2 " ASBR1B.2
	skipping to change at page 14, line 39		skipping to change at page 15, line 39
	Figure 8. Confederation		Figure 8. Confederation
	In the above figure, member-AS AS1A, AS1B, AS1C belong to a		In the above figure, member-AS AS1A, AS1B, AS1C belong to a
	confederation of ASs in AS1. AS1A and AS1B are connected to AS2.		confederation of ASs in AS1. AS1A and AS1B are connected to AS2.
	In normal operation, for the traffic toward AS2,		In normal operation, for the traffic toward AS2,
	. AS1A sends the traffic directly to AS2 through ASBR1A.1		. AS1A sends the traffic directly to AS2 through ASBR1A.1
	. AS1B sends the traffic directly to AS2 through ASBR1B.1		. AS1B sends the traffic directly to AS2 through ASBR1B.1
	. AS1C load balances the traffic between AS1A and AS1B		. AS1C load balances the traffic between AS1A and AS1B
	When the session between ASBR1A.1 and ASBR2.1 undergoes		When the session between ASBR1A.1 and ASBR2.1 is gracefully shutdown,
	maintenance, it is required that all BGP routers of AS1 reroute		it is required that all BGP routers of AS1 reroute traffic to
	traffic to ASBR1B.1 before the session between ASBR1A.1 and		ASBR1B.1 before the session between ASBR1A.1 and ASBR2.1 is shut
	ASBR2.1 is shut down.		down.
			Symmetrically, when the session between ASBR1A.1 and ASBR2.1 is
			gracefully brought up, it is required that all routers of AS1
			preferring ASBR1A.1 over ASBR1.2 reroute traffic to ASBR1A.1 before
			the less preferred path trough ASBR1.2 is possibly withdrawn.
	7. Security Considerations		7. Security Considerations
	At the requirements stage, this graceful shutdown mechanism is		At the requirements stage, this graceful shutdown mechanism is
	expected to not affect the security of the BGP protocol, especially		expected to not affect the security of the BGP protocol, especially
	if it can be kept simple. No new sessions are required and the		if it can be kept simple. No new sessions are required and the
	additional ability to signal the graceful shutdown is not expected to		additional ability to signal the graceful shutdown is not expected to
	bring additional attack vector as BGP neighbors already have the		bring additional attack vector as BGP neighbors already have the
	ability to send incorrect or misleading information or even shut down		ability to send incorrect or misleading information or even shut down
	the session.		the session.
			Internet-Draft Requirements for the graceful shutdown of BGP sessions
	Security considerations MUST be addressed by the proposed		Security considerations MUST be addressed by the proposed
	solutions. In particular they SHOULD address the issues of bogus		solutions. In particular they SHOULD address the issues of bogus
	g-shut messages and how they would affect the network(s), as well		g-shut messages and how they would affect the network(s), as well
	Requirements for the graceful shutdown of BGP sessions
	as the impact of hiding a g-shut message so that g-shut is not		as the impact of hiding a g-shut message so that g-shut is not
	performed.		performed.
	The solution SHOULD NOT increase the ability for one AS to		The solution SHOULD NOT increase the ability for one AS to
	selectively influence routing decision in the peer AS (inbound		selectively influence routing decision in the peer AS (inbound
	Traffic Engineering) outside the case of the BGP session		Traffic Engineering) outside the case of the BGP session
	shutdown. Otherwise, the peer AS SHOULD have means to detect such		shutdown. Otherwise, the peer AS SHOULD have means to detect such
	behavior.		behavior.
	8. IANA Considerations		8. IANA Considerations
	skipping to change at page 15, line 54		skipping to change at page 17, line 5
	"Graceful Shutdown in MPLS and Generalized MPLS Traffic		"Graceful Shutdown in MPLS and Generalized MPLS Traffic
	Engineering Networks", RFC 5817 April 2010.		Engineering Networks", RFC 5817 April 2010.
	[GR] S. Sangli, E. Chen, R. Fernando, J. Scudder, Y. Rekhter		[GR] S. Sangli, E. Chen, R. Fernando, J. Scudder, Y. Rekhter
	"Graceful Restart Mechanism for BGP", RFC 4724 January 2007.		"Graceful Restart Mechanism for BGP", RFC 4724 January 2007.
	[Reliability] Network Strategy Partners, LLC.		[Reliability] Network Strategy Partners, LLC.
	"Reliable IP Nodes: A prerequisite to profitable IP services",		"Reliable IP Nodes: A prerequisite to profitable IP services",
	November 2002. http://www.nspllc.com/NewPages/Reliable_IP_Nodes.pdf		November 2002. http://www.nspllc.com/NewPages/Reliable_IP_Nodes.pdf
			Internet-Draft Requirements for the graceful shutdown of BGP sessions
	10. Acknowledgments		10. Acknowledgments
	Authors would like to thank Nicolas Dubois, Benoit Fondeviole,		Authors would like to thank Nicolas Dubois, Benoit Fondeviole,
	Christian Jacquenet, Olivier Bonaventure, Steve Uhlig, Xavier		Christian Jacquenet, Olivier Bonaventure, Steve Uhlig, Xavier
	Requirements for the graceful shutdown of BGP sessions
	Vinet, Vincent Gillet, Jean-Louis le Roux, Pierre Alain Coste and		Vinet, Vincent Gillet, Jean-Louis le Roux, Pierre Alain Coste and
	Ronald Bonica for the useful discussions on this subject, their		Ronald Bonica for the useful discussions on this subject, their
	review and comments.		review and comments.
	This draft has been partly sponsored by the European project IST		This draft has been partly sponsored by the European project IST
	AGAVE.		AGAVE.
	Authors' Addresses		Authors' Addresses
	Bruno Decraene		Bruno Decraene
	skipping to change at page 16, line 50		skipping to change at page 18, line 4
	Zubair Ahmad		Zubair Ahmad
	Orange Business Services		Orange Business Services
	13775 McLearen Road, Oak Hill VA 20171		13775 McLearen Road, Oak Hill VA 20171
	USA		USA
	Email: zubair.ahmad@orange-ftgroup.com		Email: zubair.ahmad@orange-ftgroup.com
	Antonio Jose Elizondo Armengol		Antonio Jose Elizondo Armengol
	Division de Analisis Tecnologicos		Division de Analisis Tecnologicos
			Internet-Draft Requirements for the graceful shutdown of BGP sessions
	Technology Analysis Division		Technology Analysis Division
	Telefonica I+D		Telefonica I+D
	C/ Emilio Vargas 6		C/ Emilio Vargas 6
	28043, Madrid		28043, Madrid
	Requirements for the graceful shutdown of BGP sessions
	E-mail: ajea@tid.es		E-mail: ajea@tid.es
	Tomonori Takeda		Tomonori Takeda
	NTT Corporation		NTT Corporation
	9-11, Midori-Cho 3 Chrome		9-11, Midori-Cho 3 Chrome
	Musashino-Shi, Tokyo 180-8585		Musashino-Shi, Tokyo 180-8585
	Japan		Japan
	Email: takeda.tomonori@lab.ntt.co.jp		Email: takeda.tomonori@lab.ntt.co.jp
End of changes. 43 change blocks.
	93 lines changed or deleted		120 lines changed or added
This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/