draft-ietf-grow-bgp-med-considerations-00.txt		draft-ietf-grow-bgp-med-considerations-01.txt
	INTERNET-DRAFT Danny McPherson		INTERNET-DRAFT Danny McPherson
	Arbor Networks, Inc.		Arbor Networks, Inc.
	Vijay Gill		Vijay Gill
	AOL		AOL
	Category Informational		Category Informational
	Expires: June 2004 December 2003		Expires: November 2004 May 2004
	BGP MED Considerations		BGP MED Considerations
	<draft-ietf-grow-bgp-med-considerations-00.txt>		<draft-ietf-grow-bgp-med-considerations-01.txt>
	Status of this Document		Status of this Document
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC2026.		all provisions of Section 10 of RFC2026.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	skipping to change at page 1, line 43		skipping to change at page 1, line 43
	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 [RFC 2119].		document are to be interpreted as described in RFC 2119 [RFC 2119].
	This document is a product of an individual. Comments are solicited		This document is a product of an individual. Comments are solicited
	and should be addressed to the author(s).		and should be addressed to the author(s).
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2003). All Rights Reserved.		Copyright (C) The Internet Society (2004). All Rights Reserved.
			=0C
	Abstract		Abstract
	The BGP MED attribute provides a mechanism for BGP speakers to convey		The BGP MED attribute provides a mechanism for BGP speakers to convey
	to an adjacent AS the optimal entry point into the local AS. While		to an adjacent AS the optimal entry point into the local AS. While
	BGP MEDs function correctly in many scenarios, there are a number of		BGP MEDs function correctly in many scenarios, there are a number of
	issues which may arise when utilizing MEDs in dynamic or complex		issues which may arise when utilizing MEDs in dynamic or complex
	topologies.		topologies.
	This document discusses implementation and deployment considerations		This document discusses implementation and deployment considerations
	regarding BGP MEDs and provides information which implementors and		regarding BGP MEDs and provides information which implementors and
	network operators should be familiar with.		network operators should be familiar with.
			=0C
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.1. About the MULTI_EXIT_DISC (MED) Attribute . . . . . . . . . 4		1.1. About the MULTI_EXIT_DISC (MED) Attribute . . . . . . . . . 4
	1.2. MEDs and Potatoes . . . . . . . . . . . . . . . . . . . . . 5		1.2. MEDs and Potatoes . . . . . . . . . . . . . . . . . . . . . 5
	2. Implementation and Protocol Considerations . . . . . . . . . . 7		2. Implementation and Protocol Considerations . . . . . . . . . . 7
	2.1. MULTI_EXIT_DISC is a Optional Non-Transitive		2.1. MULTI_EXIT_DISC is a Optional Non-Transitive
	Attribute. . . . . . . . . . . . . . . . . . . . . . . . . . . . 7		Attribute. . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	2.2. MED Values and Preferences. . . . . . . . . . . . . . . . . 7		2.2. MED Values and Preferences. . . . . . . . . . . . . . . . . 7
	2.3. Comparing MEDs Between Different Autonomous		2.3. Comparing MEDs Between Different Autonomous
	skipping to change at page 4, line 5		skipping to change at page 4, line 5
	3. Deployment Considerations. . . . . . . . . . . . . . . . . . . 11		3. Deployment Considerations. . . . . . . . . . . . . . . . . . . 11
	3.1. Comparing MEDs Between Different Autonomous		3.1. Comparing MEDs Between Different Autonomous
	Systems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11		Systems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	3.2. Effects of Aggregation on MEDs` . . . . . . . . . . . . . . 12		3.2. Effects of Aggregation on MEDs` . . . . . . . . . . . . . . 12
	4. Security Considerations. . . . . . . . . . . . . . . . . . . . 12		4. Security Considerations. . . . . . . . . . . . . . . . . . . . 12
	4.1. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 12		4.1. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 12
	5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13		5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
	6. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13		6. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13
	7. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 13		7. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 13
			=0C
	1. Introduction		1. Introduction
	The BGP MED attribute provides a mechanism for BGP speakers to convey		The BGP MED attribute provides a mechanism for BGP speakers to convey
	to an adjacent AS the optimal entry point into the local AS. While		to an adjacent AS the optimal entry point into the local AS. While
	BGP MEDs function correctly in many scenarios, there are a number of		BGP MEDs function correctly in many scenarios, there are a number of
	issues which may arise when utilizing MEDs in dynamic or complex		issues which may arise when utilizing MEDs in dynamic or complex
	topologies.		topologies.
	This document discusses implementation and deployment considerations		This document discusses implementation and deployment considerations
	regarding BGP MEDs and provides information which implementors and		regarding BGP MEDs and provides information which implementors and
	skipping to change at page 5, line 5		skipping to change at page 5, line 5
	An implementation MAY also (based on local configuration) alter the		An implementation MAY also (based on local configuration) alter the
	value of the MULTI_EXIT_DISC attribute received over EBGP. This		value of the MULTI_EXIT_DISC attribute received over EBGP. This
	MAY be done prior to determining the degree of preference of the		MAY be done prior to determining the degree of preference of the
	route and performing route selection (decision process phases 1 and		route and performing route selection (decision process phases 1 and
	2).		2).
	Section 9.1.2.2 (c) of [BGP4] defines the following route selection		Section 9.1.2.2 (c) of [BGP4] defines the following route selection
	criteria regarding MEDs:		criteria regarding MEDs:
			=0C
	Remove from consideration routes with less-preferred		Remove from consideration routes with less-preferred
	MULTI_EXIT_DISC attributes. MULTI_EXIT_DISC is only comparable		MULTI_EXIT_DISC attributes. MULTI_EXIT_DISC is only comparable
	between routes learned from the same neighboring AS (the		between routes learned from the same neighboring AS (the
	neighboring AS is determined from the AS_PATH attribute). Routes		neighboring AS is determined from the AS_PATH attribute). Routes
	which do not have the MULTI_EXIT_DISC attribute are considered to		which do not have the MULTI_EXIT_DISC attribute are considered to
	have the lowest possible MULTI_EXIT_DISC value.		have the lowest possible MULTI_EXIT_DISC value.
	This is also described in the following procedure:		This is also described in the following procedure:
	for m = all routes still under consideration		for m =3D all routes still under consideration
	for n = all routes still under consideration		for n =3D all routes still under consideration
	if (neighborAS(m) == neighborAS(n)) and (MED(n) < MED(m))		if (neighborAS(m) =3D=3D neighborAS(n)) and (MED(n) < MED(m))
	remove route m from consideration		remove route m from consideration
	In the pseudo-code above, MED(n) is a function which returns the		In the pseudo-code above, MED(n) is a function which returns the
	value of route n's MULTI_EXIT_DISC attribute. If route n has no		value of route n's MULTI_EXIT_DISC attribute. If route n has no
	MULTI_EXIT_DISC attribute, the function returns the lowest possible		MULTI_EXIT_DISC attribute, the function returns the lowest possible
	MULTI_EXIT_DISC value, i.e. 0.		MULTI_EXIT_DISC value, i.e. 0.
	If a MULTI_EXIT_DISC attribute is removed before re- advertising a		If a MULTI_EXIT_DISC attribute is removed before re- advertising a
	route into IBGP, then comparison based on the received EBGP		route into IBGP, then comparison based on the received EBGP
	MULTI_EXIT_DISC attribute MAY still be performed. If an		MULTI_EXIT_DISC attribute MAY still be performed. If an
	skipping to change at page 6, line 4		skipping to change at page 6, line 4
	to cause route loops.		to cause route loops.
	Routes that have different MULTI_EXIT_DISC attribute SHALL NOT be		Routes that have different MULTI_EXIT_DISC attribute SHALL NOT be
	aggregated.		aggregated.
	1.2. MEDs and Potatoes		1.2. MEDs and Potatoes
	In a situation where traffic flows between a pair of hosts, each		In a situation where traffic flows between a pair of hosts, each
	connected to different transit networks, which are themselves		connected to different transit networks, which are themselves
	interconnected at two or more locations, each transit network has the		interconnected at two or more locations, each transit network has the
			=0C
	choice of either sending traffic to the closest peering to the		choice of either sending traffic to the closest peering to the
	adjacent transit network or passing traffic to the interconnection		adjacent transit network or passing traffic to the interconnection
	location which advertises the least cost path to the destination		location which advertises the least cost path to the destination
	host.		host.
	DIAGRAM***		DIAGRAM***
	The former method is called "hot potato routing" (or closest-exit)		The former method is called "hot potato routing" (or closest-exit)
	because like a hot potato held in bare hands, whoever has it tries to		because like a hot potato held in bare hands, whoever has it tries to
	get rid of it quickly. Hot potato routing is accomplished by not		get rid of it quickly. Hot potato routing is accomplished by not
	skipping to change at page 7, line 5		skipping to change at page 7, line 5
	commercial networks exchange MEDs with customers but not bilateral		commercial networks exchange MEDs with customers but not bilateral
	peers. However, commercial use of MEDs varies widely, from		peers. However, commercial use of MEDs varies widely, from
	ubiquitous use of MEDs to no use of MEDs at all.		ubiquitous use of MEDs to no use of MEDs at all.
	In addition, many deployments of MEDs today are likely behaving		In addition, many deployments of MEDs today are likely behaving
	differently (e.g., resulting is sub-optimal routing) than the network		differently (e.g., resulting is sub-optimal routing) than the network
	operator intended, thereby resulting not in hot or cold potatoes, but		operator intended, thereby resulting not in hot or cold potatoes, but
	mashed potatoes! More information on unintended behavior resulting		mashed potatoes! More information on unintended behavior resulting
	from MEDs is provided throughout this document.		from MEDs is provided throughout this document.
			=0C
	2. Implementation and Protocol Considerations		2. Implementation and Protocol Considerations
	There are a number of implementation and protocol peculiarities		There are a number of implementation and protocol peculiarities
	relating to MEDs that have been discovered that may affect network		relating to MEDs that have been discovered that may affect network
	behavior. The following sections provide information on these		behavior. The following sections provide information on these
	issues.		issues.
	2.1. MULTI_EXIT_DISC is a Optional Non-Transitive Attribute		2.1. MULTI_EXIT_DISC is a Optional Non-Transitive Attribute
	MULTI_EXIT_DISC is a non-transitive optional attribute whose		MULTI_EXIT_DISC is a non-transitive optional attribute whose
	skipping to change at page 8, line 4		skipping to change at page 8, line 4
	of the BGP draft specification have been all over the map with		of the BGP draft specification have been all over the map with
	interpretation of missing-MED. For example, earlier versions of the		interpretation of missing-MED. For example, earlier versions of the
	specification called for a missing MED to be assigned the highest		specification called for a missing MED to be assigned the highest
	possible MED value (i.e., 2^32-1).		possible MED value (i.e., 2^32-1).
	In addition, some implementations have been shown to internally		In addition, some implementations have been shown to internally
	employ a maximum possible MED value (2^32-1) as an "infinity" metric		employ a maximum possible MED value (2^32-1) as an "infinity" metric
	(i.e., the MED value is used to tag routes as unfeasible), and would		(i.e., the MED value is used to tag routes as unfeasible), and would
	upon on receiving an update with an MED value of 2^32-1 rewrite the		upon on receiving an update with an MED value of 2^32-1 rewrite the
	value to 2^32-2. Subsequently, the new MED value would be propagated		value to 2^32-2. Subsequently, the new MED value would be propagated
			=0C
	and could result in routing inconsistencies or unintended path		and could result in routing inconsistencies or unintended path
	selections.		selections.
	As a result of implementation inconsistencies and protocol revision		As a result of implementation inconsistencies and protocol revision
	variances, many network operators today explicitly reset all MED		variances, many network operators today explicitly reset all MED
	values on ingress to conform to their internal routing policies		values on ingress to conform to their internal routing policies
	(i.e., to include policy that requires that MED values of 0 and		(i.e., to include policy that requires that MED values of 0 and
	2^32-1 NOT be used in configurations, whether the MEDs are directly		2^32-1 NOT be used in configurations, whether the MEDs are directly
	computed or configured), so as to not have to rely on all their		computed or configured), so as to not have to rely on all their
	routers having the same missing-MED behavior.		routers having the same missing-MED behavior.
	skipping to change at page 9, line 4		skipping to change at page 9, line 4
	introduce persistent BGP route oscillation [RFC 3345]. The problem		introduce persistent BGP route oscillation [RFC 3345]. The problem
	is inherent in the way BGP works: a conflict exists between		is inherent in the way BGP works: a conflict exists between
	information hiding/hierarchy and the non-hierarchical selection		information hiding/hierarchy and the non-hierarchical selection
	process imposed by lack of total ordering caused by the MED rules.		process imposed by lack of total ordering caused by the MED rules.
	Given current practices, we see the problem most frequently manifest		Given current practices, we see the problem most frequently manifest
	itself in the context of MED + route reflectors or confederations.		itself in the context of MED + route reflectors or confederations.
	One potential way to avoid this is by configuring inter-Member-AS or		One potential way to avoid this is by configuring inter-Member-AS or
	inter-cluster IGP metrics higher than intra-Member-AS IGP metrics		inter-cluster IGP metrics higher than intra-Member-AS IGP metrics
	and/or using other tie breaking policies to avoid BGP route selection		and/or using other tie breaking policies to avoid BGP route selection
			=0C
	based on incomparable MEDs. Of course, IGP metric constraints may be		based on incomparable MEDs. Of course, IGP metric constraints may be
	unreasonably onerous for some applications.		unreasonably onerous for some applications.
	Comparing MEDs between differing adjacent autonomous systems (which		Comparing MEDs between differing adjacent autonomous systems (which
	will be discussed in later sections), or not utilizing MEDs at all,		will be discussed in later sections), or not utilizing MEDs at all,
	significantly decreases the probability of introducing potential		significantly decreases the probability of introducing potential
	route oscillation conditions into the network.		route oscillation conditions into the network.
	Although perhaps "legal" as far as current specifications are		Although perhaps "legal" as far as current specifications are
	concerned, modifying MED attributes received on any type of IBGP		concerned, modifying MED attributes received on any type of IBGP
	skipping to change at page 10, line 5		skipping to change at page 10, line 5
	dampening behavior because it many cause routes to be re- advertised		dampening behavior because it many cause routes to be re- advertised
	solely to reflect an internal topology change.		solely to reflect an internal topology change.
	Many implementations don't have a practical problem with IGP		Many implementations don't have a practical problem with IGP
	flapping, they either latch their IGP metric upon first advertisement		flapping, they either latch their IGP metric upon first advertisement
	or they employ some internal suppression mechanism. Some		or they employ some internal suppression mechanism. Some
	implementations regard BGP attribute changes as less significant than		implementations regard BGP attribute changes as less significant than
	route withdrawals and announcements to attempt to mitigate the impact		route withdrawals and announcements to attempt to mitigate the impact
	of this type of event.		of this type of event.
			=0C
	2.6. Effects of MEDs on Update Packing Efficiency		2.6. Effects of MEDs on Update Packing Efficiency
	Multiple unfeasible routes can be advertised in a single BGP Update		Multiple unfeasible routes can be advertised in a single BGP Update
	message. In addition, one or more feasible routes can be advertised		message. In addition, one or more feasible routes can be advertised
	in a single Update message so long as all prefixes share a common		in a single Update message so long as all prefixes share a common
	attribute set.		attribute set.
	The BGP4 protocol permits advertisement of multiple prefixes with a		The BGP4 protocol permits advertisement of multiple prefixes with a
	common set of path attributes to be advertised in a single update		common set of path attributes to be advertised in a single update
	message, this is commonly referred to as "update packing". When		message, this is commonly referred to as "update packing". When
	skipping to change at page 11, line 5		skipping to change at page 11, line 5
	MED-based best path selection. These usually involved methods used		MED-based best path selection. These usually involved methods used
	to store the oldest route along with ordering routes for MED in		to store the oldest route along with ordering routes for MED in
	earlier implementations that cause non-deterministic behavior on		earlier implementations that cause non-deterministic behavior on
	whether the oldest route would truly be selected or not.		whether the oldest route would truly be selected or not.
	The reasoning for this is that "older" paths are presumably more		The reasoning for this is that "older" paths are presumably more
	stable, and thus more preferable. However, temporal behavior in		stable, and thus more preferable. However, temporal behavior in
	route selection results in non-deterministic behavior, and as such,		route selection results in non-deterministic behavior, and as such,
	is often undesirable.		is often undesirable.
			=0C
	3. Deployment Considerations		3. Deployment Considerations
	Empirical data [MFN/Ixia Monitoring Project] has shown that accepting		Empirical data [MFN/Ixia Monitoring Project] has shown that accepting
	MEDs from other autonomous systems have the potential to cause		MEDs from other autonomous systems have the potential to cause
	traffic flow churns in the network. Some implementations only		traffic flow churns in the network. Some implementations only
	ratchet down the MED and never move it back up to prevent excessive		ratchet down the MED and never move it back up to prevent excessive
	churn.		churn.
	However, if that session is reset, the MEDs being advertised have the		However, if that session is reset, the MEDs being advertised have the
	potential of changing. If an network is relying on received MEDs to		potential of changing. If an network is relying on received MEDs to
	skipping to change at page 12, line 5		skipping to change at page 12, line 5
	This allows MEDs to reasonably reflect IGP topologies when		This allows MEDs to reasonably reflect IGP topologies when
	advertising routes to peers. While this is fine when comparing MEDs		advertising routes to peers. While this is fine when comparing MEDs
	between multiple paths learned from a single AS, it can result in		between multiple paths learned from a single AS, it can result in
	potentially "weighted" decisions when comparing MEDs between		potentially "weighted" decisions when comparing MEDs between
	different autonomous systems. This is most typically the case when		different autonomous systems. This is most typically the case when
	the autonomous systems use different mechanisms to derive IGP		the autonomous systems use different mechanisms to derive IGP
	metrics, BGP MEDs, or perhaps even use different IGP protocols with		metrics, BGP MEDs, or perhaps even use different IGP protocols with
	vastly contrasting metric spaces (e.g., OSPF v. traditional metric		vastly contrasting metric spaces (e.g., OSPF v. traditional metric
	space in IS-IS).		space in IS-IS).
			=0C
	3.2. Effects of Aggregation on MEDs`		3.2. Effects of Aggregation on MEDs`
	Another MED deployment consideration involves the impact that		Another MED deployment consideration involves the impact that
	aggregation of BGP routing information has on MEDs. Aggregates are		aggregation of BGP routing information has on MEDs. Aggregates are
	often generated from multiple locations in an AS in order to		often generated from multiple locations in an AS in order to
	accommodate stability, redundancy and other network design goals.		accommodate stability, redundancy and other network design goals.
	When MEDs are derived from IGP metrics associated with said		When MEDs are derived from IGP metrics associated with said
	aggregates the MED value advertised to peers can result in very		aggregates the MED value advertised to peers can result in very
	suboptimal routing.		suboptimal routing.
	skipping to change at page 13, line 5		skipping to change at page 13, line 5
	increase a network's susceptibility to exploitation by peers.		increase a network's susceptibility to exploitation by peers.
	4.1. Acknowledgments		4.1. Acknowledgments
	Thanks to John Scudder for applying his usual keen eye and		Thanks to John Scudder for applying his usual keen eye and
	constructive insight. Also, thanks to Curtis Villamizar and JR		constructive insight. Also, thanks to Curtis Villamizar and JR
	Mitchell.		Mitchell.
	Others to be supplied.		Others to be supplied.
			=0C
	5. References		5. References
	[RFC 1519] Fuller, V., Li. T., Yu J., and K. Varadhan, "Classless		[RFC 1519] Fuller, V., Li. T., Yu J., and K. Varadhan, "Classless
	Inter-Domain Routing (CIDR): an Address Assignment and		Inter-Domain Routing (CIDR): an Address Assignment and
	Aggregation Strategy", RFC 1519, September 1993.		Aggregation Strategy", RFC 1519, September 1993.
	[RFC 1771] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4		[RFC 1771] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4
	(BGP-4)", RFC 1771, March 1995.		(BGP-4)", RFC 1771, March 1995.
	[RFC 2439] Villamizar, C. and Chandra, R., "BGP Route Flap Damping",		[RFC 2439] Villamizar, C. and Chandra, R., "BGP Route Flap Damping",
	skipping to change at page 13, line 45		skipping to change at page 13, line 47
	Danny McPherson		Danny McPherson
	Arbor Networks		Arbor Networks
	Email: danny@arbor.net		Email: danny@arbor.net
	Vijay Gill		Vijay Gill
	AOL		AOL
	Email: VijayGill9@aol.com		Email: VijayGill9@aol.com
	7. Full Copyright Statement		7. Full Copyright Statement
	Copyright (C) The Internet Society (2003). All Rights Reserved.		Copyright (C) The Internet Society (2004). All Rights Reserved.
			=0C
	This document and translations of it may be copied and furnished to		This document and translations of it may be copied and furnished to
	others, and derivative works that comment on or otherwise explain it		others, and derivative works that comment on or otherwise explain it
	or assist in its implementation may be prepared, copied, published		or assist in its implementation may be prepared, copied, published
	and distributed, in whole or in part, without restriction of any		and distributed, in whole or in part, without restriction of any
	kind, provided that the above copyright notice and this paragraph are		kind, provided that the above copyright notice and this paragraph are
	included on all such copies and derivative works. However, this		included on all such copies and derivative works. However, this
	document itself may not be modified in any way, such as by removing		document itself may not be modified in any way, such as by removing
	the copyright notice or references to the Internet Society or other		the copyright notice or references to the Internet Society or other
	Internet organizations, except as needed for the purpose of		Internet organizations, except as needed for the purpose of
	developing Internet standards in which case the procedures for		developing Internet standards in which case the procedures for
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/