draft-ietf-grow-bgp-med-considerations-03.txt		draft-ietf-grow-bgp-med-considerations-04.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: September 2005 March 2005		Expires: December 2005 June 2005
	BGP MED Considerations		BGP MED Considerations
	<draft-ietf-grow-bgp-med-considerations-03.txt>		<draft-ietf-grow-bgp-med-considerations-04.txt>
	Status of this Memo
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is subject to all provisions		By submitting this Internet-Draft, each author represents that any
	of Section 3 of RFC 3667. By submitting this Internet-Draft, each		applicable patent or other IPR claims of which he or she is aware have
	author represents that any applicable patent or other IPR claims of		been or will be disclosed, and any of which he or she becomes aware
	which he or she is aware have been or will be disclosed, and any of		will be disclosed, in accordance with Section 6 of BCP 79.
	which he or she become aware will be disclosed, in accordance with
	RFC 3668.
	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
	other groups may also distribute working documents as		groups may also distribute working documents as Internet-Drafts.
	Internet-Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six
	and may be updated, replaced, or obsoleted by other documents at any		months and may be updated, replaced, or obsoleted by other documents
	time. It is inappropriate to use Internet-Drafts as reference		at any 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/1id-abstracts.html
	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 August 28, 2005.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2005). All Rights Reserved.		Copyright (C) The Internet Society (2005). All Rights Reserved.
	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
	skipping to change at page 3, line 10		skipping to change at page 3, line 10
	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.
	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 Potatos. . . . . . . . . . . . . . . . . . . . . . 5		1.2. MEDs and Potatos. . . . . . . . . . . . . . . . . . . . . . 5
	2. Implementation and Protocol Considerations . . . . . . . . . . 6		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
	Systems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8		Systems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	2.4. MEDs, Route Reflection and AS Confederations		2.4. MEDs, Route Reflection and AS Confederations
	for BGP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8		for BGP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	2.5. Route Flap Damping and MED Churn. . . . . . . . . . . . . . 9		2.5. Route Flap Damping and MED Churn. . . . . . . . . . . . . . 9
	2.6. Effects of MEDs on Update Packing Efficiency. . . . . . . . 9		2.6. Effects of MEDs on Update Packing Efficiency. . . . . . . . 10
	2.7. Temporal Route Selection. . . . . . . . . . . . . . . . . . 10		2.7. Temporal Route Selection. . . . . . . . . . . . . . . . . . 10
	3. Deployment Considerations. . . . . . . . . . . . . . . . . . . 10		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` . . . . . . . . . . . . . . 11		3.2. Effects of Aggregation on MEDs` . . . . . . . . . . . . . . 12
	4. Security Considerations. . . . . . . . . . . . . . . . . . . . 12		4. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 12
	4.1. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 12		5. Security Considerations. . . . . . . . . . . . . . . . . . . . 12
	5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13		5.1. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 12
	5.1. Normative References. . . . . . . . . . . . . . . . . . . . 14		6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
	5.2. Informative References. . . . . . . . . . . . . . . . . . . 15		6.1. Normative References. . . . . . . . . . . . . . . . . . . . 14
	6. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15		6.2. Informative References. . . . . . . . . . . . . . . . . . . 15
			7. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15
	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		While reading this document it's important to keep in mind that the
	regarding BGP MEDs and provides information which implementors and		goal is to discuss both implementation and deployment considerations
	network operators should be familiar with.		regarding BGP MEDs and provide and guidance which both implementors
			and network operators should be familiar with. In some instances
			implementation advice varies from deployment advice.
	1.1. About the MULTI_EXIT_DISC (MED) Attribute		1.1. About the MULTI_EXIT_DISC (MED) Attribute
	The BGP MULTI_EXIT_DISC (MED) attribute, formerly known as the		The BGP MULTI_EXIT_DISC (MED) attribute, formerly known as the
	INTER_AS_METRIC, is currently defined in section 5.1.4 of [BGP4], as		INTER_AS_METRIC, is currently defined in section 5.1.4 of [BGP4], as
	follows:		follows:
	The MULTI_EXIT_DISC is an optional non-transitive attribute which		The MULTI_EXIT_DISC is an optional non-transitive attribute which
	is intended to be used on external (inter-AS) links to discriminate		is intended to be used on external (inter-AS) links to discriminate
	among multiple exit or entry points to the same neighboring AS.		among multiple exit or entry points to the same neighboring AS.
	skipping to change at page 6, line 21		skipping to change at page 6, line 23
	get rid of it quickly. Hot potato routing is accomplished by not		get rid of it quickly. Hot potato routing is accomplished by not
	passing the EGBP learned MED into IBGP. This minimizes transit		passing the EGBP learned MED into IBGP. This minimizes transit
	traffic for the provider routing the traffic. Far less common is		traffic for the provider routing the traffic. Far less common is
	"cold potato routing" (or best-exit) where the transit provider uses		"cold potato routing" (or best-exit) where the transit provider uses
	their own transit capacity to get the traffic to the point that		their own transit capacity to get the traffic to the point that
	adjacent transit provider advertised as being closest to the		adjacent transit provider advertised as being closest to the
	destination. Cold potato routing is accomplished by passing the EBGP		destination. Cold potato routing is accomplished by passing the EBGP
	learned MED into IBGP.		learned MED into IBGP.
	If one transit provider uses hot potato routing and another uses cold		If one transit provider uses hot potato routing and another uses cold
	potato, traffic between the two tends to be more symmetric.		potato, traffic between the two tends to be more symmetric. However,
			if both providers employ cold potato routing, or both providers
			employ hot potato routing between their networks, it's likely that a
			larger amount of asymmetry would exist.
	Depending on the business relationships, if one provider has more		Depending on the business relationships, if one provider has more
	capacity or a significantly less congested backbone network, then		capacity or a significantly less congested backbone network, then
	that provider may use cold potato routing. An example of widespread		that provider may use cold potato routing. An example of widespread
	use of cold potato routing was the NSF funded NSFNET backbone and NSF		use of cold potato routing was the NSF funded NSFNET backbone and NSF
	funded regional networks in the mid 1990s.		funded regional networks in the mid 1990s.
	In some cases a provider may use hot potato routing for some		In some cases a provider may use hot potato routing for some
	destinations for a given peer AS and cold potato routing for others.		destinations for a given peer AS and cold potato routing for others.
	An example of this is the different treatment of commercial and		An example of this is the different treatment of commercial and
	research traffic in the NSFNET in the mid 1990s. Today many		research traffic in the NSFNET in the mid 1990s. Today many
	skipping to change at page 7, line 41		skipping to change at page 8, line 6
	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
	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 (i.e., set
	values on ingress to conform to their internal routing policies		to zero or some other 'fixed' value) all MED values on ingress to
	(i.e., to include policy that requires that MED values of 0 and		conform to their internal routing policies (i.e., to include policy
	2^32-1 NOT be used in configurations, whether the MEDs are directly		that requires that MED values of 0 and 2^32-1 NOT be used in
	computed or configured), so as to not have to rely on all their		configurations, whether the MEDs are directly computed or
	routers having the same missing-MED behavior.		configured), so as to not have to rely on all their routers having
			the same missing-MED behavior.
			Because implementations don't normally provide a mechanism to disable
			MED comparisons in the decision algorithm, "not using MEDs" usually
			entails explicitly setting all MEDs to some fixed value upon ingress
			to the routing domain. By assigning a fixed MED value consistently
			to all routes across the network, MEDs are a effectively a non-issue
			in the decision algorithm.
	2.3. Comparing MEDs Between Different Autonomous Systems		2.3. Comparing MEDs Between Different Autonomous Systems
	The MED was intended to be used on external (inter-AS) links to		The MED was intended to be used on external (inter-AS) links to
	discriminate among multiple exit or entry points to the same		discriminate among multiple exit or entry points to the same
	neighboring AS. However, a large number of MED applications now		neighboring AS. However, a large number of MED applications now
	employ MEDs for the purpose of determining route preference between		employ MEDs for the purpose of determining route preference between
	like routes received from different autonomous systems.		like routes received from different autonomous systems.
	A large number of implementations provide the capability to enable		A large number of implementations provide the capability to enable
	skipping to change at page 8, line 30		skipping to change at page 9, line 4
	2.4. MEDs, Route Reflection and AS Confederations for BGP		2.4. MEDs, Route Reflection and AS Confederations for BGP
	In particular configurations, the BGP scaling mechanisms defined in		In particular configurations, the BGP scaling mechanisms defined in
	"BGP Route Reflection - An Alternative to Full Mesh IBGP" [RFC 2796]		"BGP Route Reflection - An Alternative to Full Mesh IBGP" [RFC 2796]
	and "Autonomous System Confederations for BGP" [RFC 3065] will		and "Autonomous System Confederations for BGP" [RFC 3065] will
	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
	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
	is discussed in other sections), or not utilizing MEDs at all,		discussed in section 2.3), 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
	session (e.g., standard IBGP, AS confederations EIBGP, route		session (e.g., standard IBGP, AS confederations EIBGP, route
	reflection, etc..) is NOT recommended.		reflection, etc..) is NOT recommended.
	2.5. Route Flap Damping and MED Churn		2.5. Route Flap Damping and MED Churn
	skipping to change at page 10, line 26		skipping to change at page 10, line 43
	decrease in update packing efficiency.		decrease in update packing efficiency.
	2.7. Temporal Route Selection		2.7. Temporal Route Selection
	Some implementations have had bugs which lead to temporal behavior in		Some implementations have had bugs which lead to temporal behavior in
	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.
	3. Deployment Considerations		3. Deployment Considerations
	It has been discussed that accepting MEDs from other autonomous		It has been discussed that accepting MEDs from other autonomous
	systems have the potential to cause traffic flow churns in the		systems have the potential to cause traffic flow churns in the
	network. Some implementations only ratchet down the MED and never		network. Some implementations only ratchet down the MED and never
	move it back up to prevent excessive churn.		move it back up to prevent excessive churn.
	skipping to change at page 12, line 5		skipping to change at page 12, line 19
	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.
	4. Security Considerations		4. IANA Considerations
			This document introduces no new IANA considerations.
			5. Security Considerations
	The MED was purposely designed to be a "weak" metric that would only		The MED was purposely designed to be a "weak" metric that would only
	be used late in the best-path decision process. The BGP working		be used late in the best-path decision process. The BGP working
	group was concerned that any metric specified by a remote operator		group was concerned that any metric specified by a remote operator
	would only affect routing in a local AS IF no other preference was		would only affect routing in a local AS IF no other preference was
	specified. A paramount goal of the design of the MED was to ensure		specified. A paramount goal of the design of the MED was to ensure
	that peers could not "shed" or "absorb" traffic for networks that		that peers could not "shed" or "absorb" traffic for networks that
	they advertise. As such, accepting MEDs from peers may in some sense		they advertise. As such, accepting MEDs from peers may in some sense
	increase a network's susceptibility to exploitation by peers.		increase a network's susceptibility to exploitation by peers.
	4.1. Acknowledgments		5.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, JR Mitchell		constructive insight. Also, thanks to Curtis Villamizar, JR Mitchell
	and Pekka Savola for their valuable feedback.		and Pekka Savola for their valuable feedback.
	5. References		6. References
	5.1. Normative References		6.1. Normative 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 2796] Bates, T., Chandra, R., Chen, E., "BGP Route Reflection		[RFC 2796] Bates, T., Chandra, R., Chen, E., "BGP Route Reflection
	- An Alternative to Full Mesh IBGP", RFC 2796, April		- An Alternative to Full Mesh IBGP", RFC 2796, April
	2000.		2000.
	[RFC 3065] Traina, P., McPherson, D., Scudder, J.. "Autonomous System		[RFC 3065] Traina, P., McPherson, D., Scudder, J.. "Autonomous System
	Confederations for BGP", RFC 3065, February 2001.		Confederations for BGP", RFC 3065, February 2001.
	[BGP4] Rekhter, Y., T. Li., and Hares. S, Editors, "A Border		[BGP4] Rekhter, Y., T. Li., and Hares. S, Editors, "A Border
	Gateway Protocol 4 (BGP-4)", BGP Draft, Work in Progress.		Gateway Protocol 4 (BGP-4)", BGP Draft, Work in Progress.
	5.2. Informative References		6.2. Informative References
	[RFC 2439] Villamizar, C. and Chandra, R., "BGP Route Flap Damping",		[RFC 2439] Villamizar, C. and Chandra, R., "BGP Route Flap Damping",
	RFC 2439, November 1998.		RFC 2439, November 1998.
	[RFC 3345] McPherson, D., Gill, V., Walton, D., and Retana, A, "BGP		[RFC 3345] McPherson, D., Gill, V., Walton, D., and Retana, A, "BGP
	Persistent Route Oscillation Condition", RFC 3345,		Persistent Route Oscillation Condition", RFC 3345,
	August 2002.		August 2002.
	6. Authors' Addresses		7. Authors' Addresses
	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
	Intellectual Property Statement		Intellectual Property Statement
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/