draft-ietf-grow-bgp-graceful-shutdown-requirements-03.txt		draft-ietf-grow-bgp-graceful-shutdown-requirements-04.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
	June 11, 2010		September 06, 2010
	Requirements for the graceful shutdown of BGP sessions		Requirements for the graceful shutdown of BGP sessions
	draft-ietf-grow-bgp-graceful-shutdown-requirements-03.txt		draft-ietf-grow-bgp-graceful-shutdown-requirements-04.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 December 08, 2010.		This Internet-Draft will expire on March 05, 2011.
	Requirements for the graceful shutdown of BGP sessions		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
	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.
	Abstract		Abstract
	The BGP protocol is heavily used in Service Provider networks both		The Border Gateway Protocol(BGP) is heavily used in Service Provider
	for Internet and BGP/MPLS VPN services. For resiliency purposes,		networks both for Internet and BGP/MPLS VPN services. For resiliency
	redundant routers and BGP sessions can be deployed to reduce the		purposes, redundant routers and BGP sessions can be deployed to
	consequences of an AS Border Router or BGP session breakdown on		reduce the consequences of an AS Border Router or BGP session
	customers' or peers' traffic. However simply taking down or even		breakdown on customers' or peers' traffic. However simply taking down
	bringing up a BGP session for maintenance purposes may still induce		or even bringing up a BGP session for maintenance purposes may still
	connectivity losses during the BGP convergence. This is no more		induce connectivity losses during the BGP convergence. This is not
	satisfactory for new applications (e.g. voice over IP, on line		satisfactory any more for new applications (e.g. voice over IP, on
	gaming, VPN). Therefore, a solution is required for the graceful		line gaming, VPN). Therefore, a solution is required for the graceful
	shutdown of a (set of) BGP session(s) in order to limit the amount of		shutdown of a (set of) BGP session(s) in order to limit the amount of
	traffic loss during a planned shutdown. This document expresses		traffic loss during a planned shutdown. This document expresses
	requirements for such a solution.		requirements for such a solution.
	Table of Contents		Table of Contents
	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......................................6		5. Goals and requirements......................................6
	6. Reference Topologies........................................8		6. Reference Topologies........................................8
	6.1. E-BGP topologies............................................8		6.1. E-BGP topologies............................................9
	6.2. I-BGP topologies...........................................10		6.2. I-BGP topologies...........................................11
	7. Security Considerations....................................13		7. Security Considerations....................................14
	8. IANA Considerations........................................13		8. IANA Considerations........................................14
	9. References.................................................14		9. References.................................................14
	9.1. Normative References.......................................14		9.1. Normative References.......................................14
	9.2. Informative References.....................................14		9.2. Informative References.....................................14
	10. Acknowledgments............................................14		10. Acknowledgments............................................15
	11. Author's Addresses.........................................15		11. Author's Addresses.........................................15
	Requirements for the graceful shutdown of BGP sessions		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 BGP protocol is heavily used in Service Provider networks both		The Border Gateway Protocol(BGP) is heavily used in Service Provider
	for Internet and BGP/MPLS VPN services. For resiliency purposes,		networks both for Internet and BGP/MPLS VPN services. For resiliency
	redundant routers and BGP sessions can be deployed to reduce the		purposes, redundant routers and BGP sessions can be deployed to
	consequences of an AS Border Router or BGP session breakdown on		reduce the consequences of an AS Border Router or BGP session
	customers' or peers' traffic.		breakdown on customers' or peers' traffic.
	We place ourselves in the context where a Service Provider performs a		We place ourselves in the context where a Service Provider performs a
	maintenance operation and needs to shut down one or multiple BGP		maintenance operation and needs to shut down one or multiple BGP
	peering link(s) or a whole ASBR. If an alternate path is available		peering link(s) or a whole ASBR. If an alternate path is available
	within the AS, the requirement is to avoid or reduce customer or peer		within the AS, the requirement is to avoid or reduce customer or peer
	traffic loss during the BGP convergence. Indeed, as an alternate path		traffic loss during the BGP convergence. Indeed, as an alternate path
	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.
	skipping to change at page 3, line 50		skipping to change at page 3, line 50
	trigger traffic loss. There is no mechanism to advertise to its BGP		trigger traffic loss. There is no mechanism to advertise to its BGP
	peers that the prefix will soon be unreachable, while still being		peers that the prefix will soon be unreachable, while still being
	reachable. When applicable, such mechanism would reduce or prevent		reachable. When applicable, such mechanism would reduce or prevent
	traffic loss. It would typically be applicable in case of a		traffic loss. It would typically be applicable in case of a
	maintenance operation requiring the shutdown of a forwarding		maintenance operation requiring the shutdown of a forwarding
	resource. Typical examples would be a link or line card maintenance,		resource. Typical examples would be a link or line card maintenance,
	replacement or upgrade. It may also be applicable for a software		replacement or upgrade. It may also be applicable for a software
	upgrade as it may involve a firmware reset on the line cards and		upgrade as it may involve a firmware reset on the line cards and
	hence forwarding interruption.		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		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
	skipping to change at page 4, line 43		skipping to change at page 4, line 43
	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 example
	where one customer router "CUST" is dual-attached to two SP routers		where one customer router "CUST" is dual-attached to two SP routers
	"ASBR1" and "ASBR2".		"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		Requirements for the graceful shutdown of BGP sessions
	'		'
	AS1 ' AS2		AS1 ' AS2
	'		'
	/-----------ASBR1---		/-----------ASBR1---
	/ \		/ \
	/ \		/ \
	CUST R1		CUST R1
	\ /		\ /
	Z/z \ /		Z/z \ /
	\-----------ASBR2---		\-----------ASBR2---
	'		'
	AS1 ' AS2		AS1 ' AS2
	'		'
	Before the maintenance, packets for destination Z/z use the CUST-		Figure 1. Dual attached customer
	ASBR1 link because R1 selects ASBR1's route based on the IGP cost.
			Before the maintenance, packets for destination Z/z use the ASBR1-
			CUST link because R1 selects ASBR1's route based on the IGP cost.
	Let's assume the service provider wants to shutdown the ASBR1-CUST		Let's assume the service provider wants to shutdown the ASBR1-CUST
	link for maintenance purposes. Currently, when the shutdown is		link for maintenance purposes. Currently, when the shutdown is
	performed on ASBR1, the following steps are performed:		performed on ASBR1, the following steps are performed:
	1. ASBR1 sends a withdraw to its route reflector R1 for the prefix		1. ASBR1 sends a withdraw to its route reflector R1 for the prefix
	Z/z.		Z/z.
	2. R1 runs its decision process, selects the route from ASBR2 and		2. R1 runs its decision process, selects the route from ASBR2 and
	advertises the new path to ASBR1.		advertises the new path to ASBR1.
	3. ASBR1 runs its decision process and recovers the reachability of		3. ASBR1 runs its decision process and recovers the reachability of
	Z/z.		Z/z.
	skipping to change at page 5, line 50		skipping to change at page 5, line 52
	In a bigger AS, multiple steps of BGP convergence may be required to		In a bigger AS, multiple steps of BGP convergence may be required to
	find and select the best alternate path (e.g. ASBR1 is chosen based		find and select the best alternate path (e.g. ASBR1 is chosen based
	on a higher local pref, hierarchical route reflectors are used...).		on a higher local pref, hierarchical route reflectors are used...).
	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.
	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 a route reflector only		hiding the backup path. This router can be:
	propagating the best path. Or the backup ASBR does not advertise the		- a route reflector only propagating its best path;
	backup path because it prefers the nominal path. This lack of
	Requirements for the graceful shutdown of BGP sessions		Requirements for the graceful shutdown of BGP sessions
	knowledge of the alternate path is the first target of this		- the backup ASBR not advertising the backup path because it prefers
	requirement draft.		the nominal path.
			This lack of knowledge of the alternate path is the first target of
			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 at the same time. This
	can lead to forwarding loops and then packet drops. This can be		can lead to forwarding loops and then packet drops. The duration of
	avoided by performing only one IP lookup on BGP routes in each AS and		these transient micro-loops may depend on the IBGP topology (e.g.
	by using tunnels (e.g. MPLS LSP) to send packets between ASBRs.		number of Route Reflectors between ingress and egress ASBR),
			implementation differences among router platforms (e.g. speed to
			update the RIB and FIB, possibly the order in which prefixes are
			modified), forwarding mode (hop by hop IP forwarding versus
			tunneling).
			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)
			to send packets between ASBRs. As such, BGP/MPLS VPNs should be
			immune to such micro forwarding loops.
	4. Terminology		4. Terminology
	g-shut initiator: the router on which the session(s) shutdown is		g-shut initiator: the router on which the session(s) shutdown is
	(are) performed for the maintenance.		(are) performed for the maintenance.
	g-shut neighbor: a router that peers with the g-shut initiator		g-shut neighbor: a router that peers with the g-shut initiator
	via (one of) the session(s) undergoing maintenance.		via (one of) the session(s) undergoing maintenance.
	Affected prefixes: a prefix initially reached via the peering		Affected prefixes: a prefix initially reached via the peering
	skipping to change at page 6, line 48		skipping to change at page 7, line 4
	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.
	As a result, provided an alternate path is available in the AS, the		As a result, provided an alternate path is available in the AS, the
	packets are rerouted before the BGP session termination and fewer		packets are rerouted before the BGP session termination and fewer
			Requirements for the graceful shutdown of BGP sessions
	packets (possibly none) are lost during the BGP convergence process		packets (possibly none) are lost during the BGP convergence process
	since at any time, all routers have a valid path.		since at any time, all routers have a valid path.
	Another goal is to minimize packet loss when the BGP session is re-		Another goal is to minimize packet loss when the BGP session is re-
	established following the maintenance.		established following the maintenance.
	From the above goals we can derive the following requirements:		From the above goals we can derive the following requirements:
	a) A mechanism to advertise the maintenance action to all affected		a) A mechanism to advertise the maintenance action to all affected
	routers is REQUIRED. Such mechanism may be either implicit or		routers is REQUIRED. Such mechanism may be either implicit or
	Requirements for the graceful shutdown of BGP sessions
	explicit. Note that affected routers can be located both in the local		explicit. Note that affected routers can be located both in the local
	AS and in neighboring ASes.		AS and in neighboring ASes. Note also that the maintenance action can
			either be the shutdown of a BGP session or the establishment of a BGP
			session.
			The mechanism SHOULD minimize packet loss when a path is removed or
			advertised. In particular, it SHOULD be ensured that the old path is
			not removed from the routing tables of the affected routers before
			the new path is known.
	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 MUST be		initiator AS and the neighbor AS(es) have a backup path, they SHOULD
	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 (e-BGP, i-BGP, i-BGP route reflector client, e-BGP		sessions (EBGP, IBGP, IBGP route reflector client, EBGP
	confederations, e-BGP 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 a sub-set
	of AFIs carried in a MP-BGP session, this mechanism MAY be applicable		of AFIs carried in a MP-BGP session, this mechanism MAY be applicable
	to this sub-set of AFIs.		to this sub-set of AFIs.
	Depending on the session type (eBGP, iBGP...), there may be some		Depending on the session type (EBGP, IBGP...), there may be some
	variations in the proposed solution in order to fit the requirements.		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:
	- 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.
	- The shutdown of a customer access router and all of its BGP
	sessions. In BGP/MPLS VPN as per [VPN], this router is called a CE		Service Providers and platforms implementing a graceful shutdown
	and the use of others protocols than BGP on the PE-CE access link		solution should note that in BGP/MPLS VPN as per [VPN], the PE-CE
	should also be considered (static routes, RIPv2, OSPF, IS-IS...).		routing can be performed by other protocols than BGP (e.g. static
			routes, RIPv2, OSPF, IS-IS...). This is out of scope of this
			document, but comprehensive graceful shutdown procedures should take
			this into account.
	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).
			Requirements for the graceful shutdown of BGP sessions
	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		SHOULD 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. The
	solution SHOULD bring improvements even when one of the two ASes does		solution SHOULD bring improvements even when one of the two ASes does
	not support graceful shutdown. In particular, large Service Providers		not support graceful shutdown. In particular, large Service Providers
	may not be able to upgrade all of the deployed customer premises		may not be able to upgrade all of the deployed customer premises
	access routers (CPE).		access routers (CPE).
	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		h) The specific procedure SHOULD end when the BGP session is closed
	closed. The procedure SHOULD be reverted, either automatically or		following the g-shut and once the BGP session is gracefully opened
	manually, when the session is re-established. During this reversion		following the g-noshut. In the end, once the planned maintenance is
	procedure -when the session is brought up- the procedure SHOULD also		finished the nominal BGP routing MUST be reestablished.
	minimize packet loss when the nominal path is installed and used		The duration of the g-shut procedure, and hence the time before the
			BGP session is safely closed SHOULD be discussed by the solution
	Requirements for the graceful shutdown of BGP sessions		document. Examples of possible solutions are the use of a pre-
			configured timer, of a message to signal the end of the BGP
	again. In particular, it SHOULD be ensured that the backup path is		convergence or monitoring the traffic on the g-shut interface...
	not removed from the routing tables of the effected nodes before it
	learns the nominal path. In the end, once the planned maintenance is
	finished and the shutdown resource becomes available again, the
	nominal BGP routing MUST be reestablished.
	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.		MAY only cover a subset of the cases.
	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
	- 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;
	skipping to change at page 8, line 38		skipping to change at page 9, line 4
	In order to benchmark the proposed solutions, some typical BGP		In order to benchmark the proposed solutions, some typical BGP
	topologies are detailed in this section. The solution drafts		topologies are detailed in this section. The solution drafts
	should state its applicability for each of these possible		should state its applicability for each of these possible
	topologies.		topologies.
	However, solutions SHOULD be applicable to all possible BGP		However, solutions SHOULD be applicable to all possible BGP
	topologies and not only to these below examples. Note that this		topologies and not only to these below examples. Note that this
	is a "SHOULD" rather than a "MUST" as a partial lightweight		is a "SHOULD" rather than a "MUST" as a partial lightweight
	solution may be preferred to a full but more complex solution.		solution may be preferred to a full but more complex solution.
			Requirements for the graceful shutdown of BGP sessions
	Especially since some ISP may not be concerned by some topologies		Especially since some ISP may not be concerned by some topologies
	(e.g. confederations).		(e.g. confederations).
	6.1. E-BGP topologies		6.1. EBGP topologies
	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.
	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.
	The requirements of section 5 should be applicable to:		The requirements of section 5 should be applicable to:
	- 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.		session needs to be shutdown.
	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.
			Requirements for the graceful shutdown of BGP sessions
	'		'
	AS1 ' AS2		AS1 ' AS2
	'		'
	ASBR1.1----------- ASBR2.1		ASBR1.1----------- ASBR2.1
	'		'
	'		'
	'		'
	'		'
	'		'
	ASBR1.2----------- ASBR2.2		ASBR1.2----------- ASBR2.2
	'		'
	AS1 ' AS2		AS1 ' AS2
	'		'
			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);
	- 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.
	Requirements for the graceful shutdown of BGP sessions
	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.
	'		'
	AS1 ' AS2		AS1 ' AS2
	'		'
	ASBR1.1----------- ASBR2.1		ASBR1.1----------- ASBR2.1
	| '		| '
	| '		| '
	'''''|''''''''''		'''''|''''''''''
	| '		| '
	| '		| '
	ASBR3.1----------- ASBR2.2		ASBR3.1----------- ASBR2.2
	'		'
	AS3 ' AS2		AS3 ' AS2
			Figure 4. EBGP topology of a dual homed customer
	The requirements of section 5 do not translate as easily as in		The requirements of section 5 do not translate as easily as in
	the two previous topologies because we do not require propagating		the two previous topologies because we do not require propagating
	the maintenance advertisement outside of the two ASes involved in		the maintenance advertisement outside of the two ASes involved in
	an eBGP session.		an eBGP session.
	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. I-BGP topologies		Requirements for the graceful shutdown of BGP sessions
	We describe here some frequent iBGP topologies that SHOULD be		6.2. IBGP topologies
			We describe here some frequent IBGP topologies that SHOULD be
	supported by the solution.		supported by the solution.
	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
	Requirements for the graceful shutdown of BGP sessions		Figure 5. IBGP full mesh
	When the session between ASBR1.1 and ASBR2.1 undergoes		When the session between ASBR1.1 and ASBR2.1 undergoes
	maintenance, it is required that all i-BGP peers of ASBR1.1		maintenance, it is required that all IBGP peers of ASBR1.1 reroute
	reroute traffic to ASBR1.2 before the session between ASBR1.1 and		traffic to ASBR1.2 before the session between ASBR1.1 and ASBR2.1
	ASBR2.1 is shut down.		is shut down.
	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
	i-BGP sessions.		IBGP sessions.
			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
	When the session between ASBR1.1 and ASBR2.1 undergoes		When the session between ASBR1.1 and ASBR2.1 undergoes
	maintenance, it is required that all BGP routers of AS1 reroute		maintenance, 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.
	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 i-BGP sessions.		the number of IBGP sessions.
	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 12, line 28		skipping to change at page 12, line 56
	| |		| |
	| |		| |
	ASBR1.1 ASBR1.2		ASBR1.1 ASBR1.2
	\ /		\ /
	\ /		\ /
	''''''\'''''''''/''''''''''''		''''''\'''''''''/''''''''''''
	\ /		\ /
	\ / AS2		\ / AS2
	ASBR2.1		ASBR2.1
			Figure 7. Hierarchical Route Reflector
			Requirements for the graceful shutdown of BGP sessions
	When the session between ASBR1.1 and ASBR2.1 undergoes		When the session between ASBR1.1 and ASBR2.1 undergoes
	maintenance, it is required that all BGP routers of AS1 reroute		maintenance, 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.
	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 i-BGP 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 shutdown of EBGP sessions between
	member-ASs in the confederation in addition to the shutdown of eBGP		member-ASs in the confederation in addition to the shutdown of EBGP
	sessions between a member-AS and an AS outside of the confederation.		sessions between a member-AS and an AS outside of the confederation.
	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 13, line 29		skipping to change at page 13, line 47
	| " |		| " |
	| " |		| " |
	ASBR1A.1 " ASBR1B.1		ASBR1A.1 " ASBR1B.1
	\ " /		\ " /
	\ " /		\ " /
	''''''\'''''''''''''/''''''''''''		''''''\'''''''''''''/''''''''''''
	\ /		\ /
	\ / AS2		\ / AS2
	ASBR2.1		ASBR2.1
			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
			Requirements for the graceful shutdown of BGP sessions
	When the session between ASBR1A.1 and ASBR2.1 undergoes		When the session between ASBR1A.1 and ASBR2.1 undergoes
	maintenance, it is required that all BGP routers of AS1 reroute		maintenance, it is required that all BGP routers of AS1 reroute
	traffic to ASBR1B.1 before the session between ASBR1A.1 and		traffic to ASBR1B.1 before the session between ASBR1A.1 and
	ASBR2.1 is shut down.		ASBR2.1 is shut down.
	7. Security Considerations		7. Security Considerations
	Security considerations MUST be addressed by the proposed		Security considerations MUST be addressed by the proposed
	solutions.		solutions.
	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
	TE) outside the case of the BGP session shutdown. Otherwise, the		Traffic Engineering) outside the case of the BGP session
	peer AS SHOULD have means to detect such behavior.		shutdown. Otherwise, the peer AS SHOULD have means to detect such
			behavior.
	8. IANA Considerations		8. IANA Considerations
	This document has no actions for IANA.		This document has no actions for IANA.
	Requirements for the graceful shutdown of BGP sessions
	9. References		9. References
	9.1. Normative References		9.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.
	[BGP-4] Y. Rekhter, T. Li, "A Border Gateway protocol 4 (BGP)", RFC		[BGP-4] Y. Rekhter, T. Li, "A Border Gateway protocol 4 (BGP)", RFC
	4271, January 2006.		4271, January 2006.
	skipping to change at page 14, line 38		skipping to change at page 15, line 4
	9.2. Informative References		9.2. Informative References
	[RFC5817] Z. Ali, J.P. Vasseur, A. Zamfir and J. Newton		[RFC5817] Z. Ali, J.P. Vasseur, A. Zamfir and J. Newton
	"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.
			Requirements for the graceful shutdown of BGP sessions
	"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
	10. Acknowledgments		10. Acknowledgments
	This draft is mostly an updated version of draft-dubois-bgp-pm-
	reqs-02.txt.
	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
	Vinet, Vincent Gillet, Jean-Louis le Roux and Pierre Alain Coste		Vinet, Vincent Gillet, Jean-Louis le Roux, Pierre Alain Coste and
	for the useful discussions on this subject, their review and		Ronald Bonica for the useful discussions on this subject, their
	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.
	Requirements for the graceful shutdown of BGP sessions
	Authors' Addresses		Authors' Addresses
	Bruno Decraene		Bruno Decraene
	France Telecom		France Telecom
	38-40 rue du General Leclerc		38-40 rue du General Leclerc
	92794 Issy Moulineaux cedex 9		92794 Issy Moulineaux cedex 9
	France		France
	Email: bruno.decraene@orange-ftgroup.com		Email: bruno.decraene@orange-ftgroup.com
	skipping to change at page 15, line 39		skipping to change at page 15, line 53
	Chiyoda-ku, Tokyo 101-0051		Chiyoda-ku, Tokyo 101-0051
	Japan		Japan
	Email: cristel@iij.ad.jp		Email: cristel@iij.ad.jp
	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
			Requirements for the graceful shutdown of BGP sessions
	Antonio Jose Elizondo Armengol		Antonio Jose Elizondo Armengol
	Division de Analisis Tecnologicos		Division de Analisis Tecnologicos
	Technology Analysis Division		Technology Analysis Division
	Telefonica I+D		Telefonica I+D
	C/ Emilio Vargas 6		C/ Emilio Vargas 6
	28043, Madrid		28043, Madrid
	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
	Requirements for the graceful shutdown of BGP sessions
	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. 57 change blocks.
	104 lines changed or deleted		136 lines changed or added
This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/