draft-ietf-idr-bgp4-experience-protocol-00.txt		draft-ietf-idr-bgp4-experience-protocol-01.txt
	INTERNET-DRAFT Danny McPherson		INTERNET-DRAFT Danny McPherson
	draft-ietf-idr-bgp4-experience-00.txt Arbor Networks		draft-ietf-idr-bgp4-experience-protocol-01.txtArbor Networks
	Keyur Patel		Keyur Patel
	Cisco Systems		Cisco Systems
	Category Informational		Category Informational
	Expires: February 2004 August 2003		Expires: February 2004 August 2003
	Experience with the BGP-4 Protocol		Experience with the BGP-4 Protocol
	<draft-ietf-idr-bgp4-experience-protocol-00.txt>		<draft-ietf-idr-bgp4-experience-protocol-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 3, line 10		skipping to change at page 3, line 10
	requirement, this report augments RFC 1773 and describes additional		requirement, this report augments RFC 1773 and describes additional
	knowledge and understanding gained in the time between when the		knowledge and understanding gained in the time between when the
	protocol was made a Draft Standard and when it was submitted for		protocol was made a Draft Standard and when it was submitted for
	Standard.		Standard.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. BGP-4 Overview . . . . . . . . . . . . . . . . . . . . . . . . 4		2. BGP-4 Overview . . . . . . . . . . . . . . . . . . . . . . . . 4
	2.1. A Border Gateway Protocol . . . . . . . . . . . . . . . . . 4		2.1. A Border Gateway Protocol . . . . . . . . . . . . . . . . . 4
	2.2. BGP version 2 . . . . . . . . . . . . . . . . . . . . . . . 5		3. Management Information Base (MIB). . . . . . . . . . . . . . . 5
	2.3. BGP version 3 . . . . . . . . . . . . . . . . . . . . . . . 5		4. Implementations. . . . . . . . . . . . . . . . . . . . . . . . 5
	2.4. BGP version 4 . . . . . . . . . . . . . . . . . . . . . . . 6		5. Operational Experience . . . . . . . . . . . . . . . . . . . . 5
	3. Management Information Base (MIB). . . . . . . . . . . . . . . 7		6. Metrics. . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	4. Implementations. . . . . . . . . . . . . . . . . . . . . . . . 7		6.1. MULTI_EXIT_DISC (MED) . . . . . . . . . . . . . . . . . . . 7
	5. Operational Experience . . . . . . . . . . . . . . . . . . . . 8		6.1.1. Sending MEDs to BGP Peers. . . . . . . . . . . . . . . . 7
	6. Metrics. . . . . . . . . . . . . . . . . . . . . . . . . . . . 9		6.1.2. MED of Zero Versus No MED. . . . . . . . . . . . . . . . 8
	6.1. MULTI_EXIT_DISC (MED) . . . . . . . . . . . . . . . . . . . 9		6.1.3. MEDs and Temporal Route Selection. . . . . . . . . . . . 8
	6.1.1. Sending MEDs to BGP Peers. . . . . . . . . . . . . . . . 10		7. LOCAL_PREF . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	6.1.2. MED of Zero Versus No MED. . . . . . . . . . . . . . . . 10		8. Internal BGP In Large Autonomous Systems . . . . . . . . . . . 9
	6.1.3. MEDs and Temporal Route Selection. . . . . . . . . . . . 10		9. Internet Dynamics. . . . . . . . . . . . . . . . . . . . . . . 10
	7. LOCAL_PREF . . . . . . . . . . . . . . . . . . . . . . . . . . 10		10. BGP Routing Information Bases (RIBs). . . . . . . . . . . . . 11
	8. Internal BGP In Large Autonomous Systems . . . . . . . . . . . 11		11. Update Packing. . . . . . . . . . . . . . . . . . . . . . . . 11
	9. Internet Dynamics. . . . . . . . . . . . . . . . . . . . . . . 12		12. Limit Rate Updates. . . . . . . . . . . . . . . . . . . . . . 12
	10. BGP Routing Information Bases (RIBs). . . . . . . . . . . . . 12		13. Ordering of Path Attributes . . . . . . . . . . . . . . . . . 12
	11. Update Packing. . . . . . . . . . . . . . . . . . . . . . . . 13		14. AS_SET Sorting. . . . . . . . . . . . . . . . . . . . . . . . 12
	12. Limit Rate Updates. . . . . . . . . . . . . . . . . . . . . . 13		15. Control over Version Negotiation. . . . . . . . . . . . . . . 13
	13. Ordering of Path Attributes . . . . . . . . . . . . . . . . . 14		16. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	14. AS_SET Sorting. . . . . . . . . . . . . . . . . . . . . . . . 14		16.1. TCP MD5 Signature Option . . . . . . . . . . . . . . . . . 13
	15. Control over Version Negotiation. . . . . . . . . . . . . . . 14		16.2. BGP Over IPSEC . . . . . . . . . . . . . . . . . . . . . . 13
	16. Reciept of Non-Transitive Attributes from eBGP		16.3. Miscellaneous. . . . . . . . . . . . . . . . . . . . . . . 14
	Peer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14		16.4. PTOMAINE and GROW. . . . . . . . . . . . . . . . . . . . . 14
	17. Security Considerations . . . . . . . . . . . . . . . . . . . 15		16.5. Internet Routing Registries (IRRs) . . . . . . . . . . . . 15
	17.1. TCP MD5 Signature Option . . . . . . . . . . . . . . . . . 15		16.6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 15
	17.2. BGP Over IPSEC . . . . . . . . . . . . . . . . . . . . . . 15		17. References. . . . . . . . . . . . . . . . . . . . . . . . . . 16
	17.3. Miscellaneous. . . . . . . . . . . . . . . . . . . . . . . 16		18. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 17
	17.4. PTOMAINE and GROW. . . . . . . . . . . . . . . . . . . . . 16		19. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 17
	17.5. Internet Routing Registries (IRRs) . . . . . . . . . . . . 17
	17.6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 17
	18. References. . . . . . . . . . . . . . . . . . . . . . . . . . 18
	19. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 19
	20. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 19
	1. Introduction		1. Introduction
	The purpose of this memo is to document how the requirements for		The purpose of this memo is to document how the requirements for
	advancing a routing protocol from Draft Standard to full Standard		advancing a routing protocol from Draft Standard to full Standard
	have been satisfied by Border Gateway Protocol version 4 (BGP-4).		have been satisfied by Border Gateway Protocol version 4 (BGP-4).
	This report satisfies the requirement for "the second report", as		This report satisfies the requirement for "the second report", as
	described in Section 6.0 of RFC 1264. In order to fulfill the		described in Section 6.0 of RFC 1264. In order to fulfill the
	requirement, this report augments RFC 1773 and describes additional		requirement, this report augments RFC 1773 and describes additional
	knowledge and understanding gained in the time between when the		knowledge and understanding gained in the time between when the
	protocol was made a Draft Standard and when it was submitted for		protocol was made a Draft Standard and when it was submitted for
	Standard.		Standard.
	2. BGP-4 Overview		2. BGP-4 Overview
	BGP is an inter-autonomous system routing protocol designed for		BGP is an inter-autonomous system routing protocol designed for
	TCP/IP internets. The primary function of BGP is to exchange network		TCP/IP internets. The primary function of a BGP speaking system is
	reachability information with other BGP systems. This information is		to exchange network reachability information with other BGP systems.
	sufficient to construct a graph of loop-free AS connectivity and		This network reachability information includes information on the
	policy decisions at the AS level may be enforced.		list of Autonomous Systems (ASs) that reachability information
			traverses. This information is sufficient to construct a graph of AS
			connectivity for this reachability from which routing loops may be
			pruned and some policy decisions at the AS level may be enforced.
	The initial version of the BGP protocol was published in RFC 1105.		The initial version of the BGP protocol was published in RFC 1105.
	Since then BGP Versions 2, 3, and 4 have been developed and are		Since then BGP Versions 2, 3, and 4 have been developed and are
	specified in [RFC 1163], [RFC 1267], and [RFC 1771], respectively.		specified in [RFC 1163], [RFC 1267], and [RFC 1771], respectively.
	Changes since BGP-4 went to Draft Standard [RFC 1771] are listed in		Changes since BGP-4 went to Draft Standard [RFC 1771] are listed in
	Appendix N of [BGP4].		Appendix N of [BGP4].
	2.1. A Border Gateway Protocol		2.1. A Border Gateway Protocol
	The Initial Version of BGP [RFC 1105]		The Initial Version of BGP [RFC 1105]. BGP version 2 is defined in
			[RFC 1163]. BGP version 3 is defined in [RFC 1267]. BGP version 4
	Appendix D of [BGP4]; Comparison with 1105:		is defined in [RFC 1771] and [BGP4]. Appendices A, B, C and D of
			[BGP4] provide summaries of the changes between each iteriation of
	o Changes to FSM to accommdate BSD 4.3 TCP UI.		the BGP specification.
	o Notion of Up/Down/Horizontal relations have been removed.
	o Message format changes:
	- Hold Timer removed from BGP Header and added to OPEN Message
	- Version field removed from BGP Header and added to OPEN Message
	- Link Type field removed from OPEN Message
	- OPEN CONFIRM message deprecated and replaced with implicit
	confirmation provided by KEEPALIVE message.
	- UPDATE Message format changed. New fields were added to
	support multiple path attributes.
	- The Marker field was expanded and its role broadened to
	support authentication
	2.2. BGP version 2
	The Second Version of BGPv2 [RFC 1163]
	Appendix C of [BGP4] Comparison with RFC 1163
	o BGP Identifier introduced to deal with collision detection.
	o Removed restriction that border router of NEXT_HOP path attribute
	had to be part of same AS.
	o Optimized and simplified exchange of information about reachable
	routes.
	BGP version 2 removed from the protocol the concept of "up", "down",
	and "horizontal" relations between autonomous systems that were
	present in version 1. BGP version 2 introduced the concept of path
	attributes. In addition, BGP version 2 clarified parts of the
	protocol that were "under-specified".
	2.3. BGP version 3
	BGPv3 [RFC 1267]
	Appendix B of [BGP4] Comparison with RFC 1267:
	o Set of destination via single IP prefix. Concept of
	network classes, or subnetting is foreign to BGP-4.
	To accommodate these capabilities BGP-4 changes the
	semantics and encoding associated with the AS_PATH attribute.
	New text has been added to define semantics associated with
	IP Prefixes. These abilities allow BGP to support the
	proposed supernetting scheme [RFC 1518] (BGP4 Draft reference
	to [9] needs to be fixed).
	o LOCAL_PREF intrduced to facilitate route selection procedures.
	o INTER_AS_METRIC renamed to MULTI_EXIT_DISC
	o ATOMIC_AGGREGATE introduced to ensure that certain aggregates
	are not deaggregated.
	o Introduced AGGREGATOR.
	o Holdtimer neogtiation per-connection for symmetry. Lower value
	used. Hold Times of zero now supported.
	BGP version 3 lifted some of the restrictions on the use of the
	NEXT_HOP path attribute, and added the BGP Identifier field to the
	BGP OPEN message. It also clarifies the procedure for distributing
	BGP routes between the BGP speakers within an autonomous system.
	2.4. BGP version 4
	BGP v4 [RFC 1771] [BGP4]
	Appendix A of [BGP4] Comparison with RFC 1771:
	o Changes to reflect use of the TCP MD5 Signature Option,
	Route Reflectors, AS Confederations for BGP and BGP Route
	Refresh.
	o Clarified use of BGP Identifier in AGGREGATOR Attribute
	o Procedures for imposing upper bound of prefixes a speaker will
	accept from a peer.
	o Ability to include more than one instance of it's own AS in the
	AS_PATH attribute for the purpose of inter-AS traffic engineering.
	o Clarified various types of NEXT_HOPS
	o Claried use of ATOMIC_AGGREGATE attribute
	o Discussed relationship be BGP NEXT_HOP attribute and immediate
	next hop.
	o Clarified tie-breaking procedures
	o Clarified route advertisement frequency text.
	o Deprecated Optional Parameter Type 1 (Authentication Information)
	o UPDATE Message Error subcode 7 (AS Routing Loop) deprecated.
	o Use of Marker field for authentication has been deprecated.
	BGP version 4 redefines the (previously defined class-based) network
	layer reachability portion of the updates to specify prefixes of
	arbitrary length in order to represent multiple classful networks in
	a single entry as discussed in [RFC 1519]. BGP version 4 has also
	modified the AS_PATH attribute so that sets of autonomous systems, as
	well as individual ASs may be described. BGP version 4 has
	redescribed the INTER-AS METRIC attribute as the MULTI_EXIT_DISC and
	added new LOCAL_PREF and AGGREGATOR attributes.
	BGP version 4 defines procedures for imposing an upper bound on the
	number of prefixes that a BGP speaker may accept from its peer. BGP
	version 4 has modifed the AS_PATH attribute to have an ability to
	include more than one instance of its own AS for the purpose of
	inter-AS traffic engineering.
	BGP version 4 deprecates the use of OPTIONAL PARAMETER Type 1
	(Authentication Information). BGP version 4 also deprecates the use
	of UPDATE MESSAGE Error subcode 7 (AS Routing Loop).
	BGP version 4 provides clarifications on use of BGP Identifier in the
	AGGREGATOR attribute and use of the ATOMIC_AGGREGATOR attribute. BGP
	version 4 also provides clarifications on various types of NEXT_HOPs,
	BGP tie-breaking procedures and frequency of route announcements in
	BGP.
	Possible applications of BGP in the Internet are documented in [RFC
	1772].
	The BGP protocol was developed by the IDR Working Group of the
	Internet Engineering Task Force. This Working Group had a mailing
	list, idr@merit.edu, where discussions of protocol features and
	operation are held. The IDR Working Group meets regularly during the
	Internet Engineering Task Force meetings. Reports of these meetings
	are published in the IETF's Proceedings.
	3. Management Information Base (MIB)		3. Management Information Base (MIB)
	The BGP-4 Management Information Base (MIB) has been published [BGP-		The BGP-4 Management Information Base (MIB) has been published [BGP-
	MIB]. The MIB was updated from previous versions documented in [RFC		MIB]. The MIB was updated from previous versions documented in [RFC
	1657] and [RFC 1269], respectively.		1657] and [RFC 1269], respectively.
	Apart from a few system variables, the BGP MIB is broken into two		Apart from a few system variables, the BGP MIB is broken into two
	tables: the BGP Peer Table and the BGP Received Path Attribute Table.		tables: the BGP Peer Table and the BGP Received Path Attribute Table.
	skipping to change at page 8, line 25		skipping to change at page 5, line 44
	5. Operational Experience		5. Operational Experience
	This section discusses operational experience with BGP and BGP-4.		This section discusses operational experience with BGP and BGP-4.
	BGP has been used in the production environment since 1989, BGP-4		BGP has been used in the production environment since 1989, BGP-4
	since 1993. Production use of BGP includes utilization of all		since 1993. Production use of BGP includes utilization of all
	significant features of the protocol. The present production		significant features of the protocol. The present production
	environment, where BGP is used as the inter-autonomous system routing		environment, where BGP is used as the inter-autonomous system routing
	protocol, is highly heterogeneous. In terms of the link bandwidth it		protocol, is highly heterogeneous. In terms of the link bandwidth it
	varies from 56 Kbps to 10 Gbps. In terms of the actual routers that		varies from 56 Kbps to 10 Gbps. In terms of the actual routers that
	run BGP it ranges from a relatively slow performance PC/RT to a very		run BGP it ranges from a relatively slow performance Pentium to a
	high performance RISC-based CPUs, and includes both the special		very high performance RISC-based CPUs, and includes both the special
	purpose routers and the general purpose workstations running various		purpose routers and the general purpose workstations running various
	UNIX derivatives and other operating systems.		UNIX derivatives and other operating systems.
	In terms of the actual topologies it varies from very sparse to quite		In terms of the actual topologies it varies from very sparse to quite
	dense. The requirement for full-mesh IBGP topologies has been		dense. The requirement for full-mesh IBGP topologies has been
	largely remedied by BGP Route Reflection, Autonomous System		largely remedied by BGP Route Reflection, Autonomous System
	Confederations for BGP, and perhaps some mix of the two.. BGP Route		Confederations for BGP, and perhaps some mix of the two. BGP Route
	Reflection was initially defined in [RFC 1966] and subsequently		Reflection was initially defined in [RFC 1966] and subsequently
	updated in [RFC 2796]. Autonomous System Confederations for BGP were		updated in [RFC 2796]. Autonomous System Confederations for BGP were
	initially defined in [RFC 1965] and subsequently updated in [RFC		initially defined in [RFC 1965] and subsequently updated in [RFC
	3065].		3065].
	At the time of this writing BGP-4 is used as an inter-autonomous		At the time of this writing BGP-4 is used as an inter-autonomous
	system routing protocol between ALL Internet-attached autonomous		system routing protocol between all Internet-attached autonomous
	systems, with nearly 15k active autonomous systems in the global		systems, with nearly 15k active autonomous systems in the global
	Internet routing table.		Internet routing table.
	BGP is used both for the exchange of routing information between a		BGP is used both for the exchange of routing information between a
	transit and a stub autonomous system, and for the exchange of routing		transit and a stub autonomous system, and for the exchange of routing
	information between multiple transit autonomous systems. There is no		information between multiple transit autonomous systems. There is no
	protocol distinction between sites historically considered		protocol distinction between sites historically considered
	"backbones" versus "regional" or "edge" networks.		"backbones" versus "regional" or "edge" networks.
	The full set of exterior routes that is carried by BGP is well over		The full set of exterior routes that is carried by BGP is well over
	skipping to change at page 9, line 35		skipping to change at page 7, line 18
	DISC (MED). This value may be used in the tie-breaking process when		DISC (MED). This value may be used in the tie-breaking process when
	selecting a preferred path to a given address space, and provides BGP		selecting a preferred path to a given address space, and provides BGP
	speakers with the capability to convey to a peer AS the optimal entry		speakers with the capability to convey to a peer AS the optimal entry
	point into the local AS.		point into the local AS.
	Although the MED was meant to only be used when comparing paths		Although the MED was meant to only be used when comparing paths
	received from different external peers in the same AS, many		received from different external peers in the same AS, many
	implementations provide the capability to compare MEDs between		implementations provide the capability to compare MEDs between
	different ASs as well.		different ASs as well.
			Though this may seem a fine idea for some configurations, care must
			be taken when comparing MEDs between different autonomous systems.
			BGP speakers often derive MED values by obtaining the IGP metric
			associated with reaching a given BGP NEXT_HOP within the local AS.
			This allows MEDs to reasonably reflect IGP topologies when
			advertising routes to peers. While this is fine when comparing MEDs
			between multiple paths learned from a single AS, it can result in
			potentially bad decisions when comparing MEDs between difference
			automomous systems. This is most typically the case when the
			autonomous systems use different mechanisms to derive IGP metrics,
			BGP MEDs, or perhaps even use different IGP procotols with vastly
			contrasting metric spaces.
			Another MED deployment consideration involves the impact of
			aggregation of BGP routing information on MEDs. Aggregates are often
			generated from multiple locations in an AS in order to accommodate
			stability, redundancy and other network design goals. When MEDs are
			derived from IGP metrics associated with said aggregates the MED
			value advertised to peers can result in very suboptimal routing.
	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 ensure that		specified. A paramount goal of the design of the MED was to ensure
	peers could not "shed" or "absorb" traffic for networks that they		that peers could not "shed" or "absorb" traffic for networks that
	advertise.		they advertise.
	6.1.1. Sending MEDs to BGP Peers		6.1.1. Sending MEDs to BGP Peers
	[BGP4] allows MEDs received from any EBGP peers by a BGP speaker to		[BGP4] allows MEDs received from any EBGP peers by a BGP speaker to
	be passed to its IBGP peers. Although advertising MEDs to IBGP peers		be passed to its IBGP peers. Although advertising MEDs to IBGP peers
	is not a required behavior, it is a common default. MEDs received		is not a required behavior, it is a common default. MEDs received
	from EBGP peers by a BGP speaker MUST NOT be sent to other EBGP		from EBGP peers by a BGP speaker MUST NOT be sent to other EBGP
	peers.		peers.
			Note that many implementations provide a mechanism to derive MED
			values from IGP metrics in order to allow BGP MED information to
			reflect the IGP topologies and metrics of the network when
			propagating information to adjacent autonomous systems.
	6.1.2. MED of Zero Versus No MED		6.1.2. MED of Zero Versus No MED
	An implementation MUST provide a mechanism that allows for MED to be		An implementation MUST provide a mechanism that allows for MED to be
	removed. Previously, implementations did not consider a missing MED		removed. Previously, implementations did not consider a missing MED
	value to be the same as a MED of zero. No MED value should now be		value to be the same as a MED of zero. No MED value should now be
	equal to a value of zero.		equal to a value of zero.
			Note that many implementations provide an mechanism to explicitly
			define a missing MED value as "worst" or less preferable than zero or
			larger values.
	6.1.3. MEDs and Temporal Route Selection		6.1.3. MEDs and Temporal Route Selection
	Some implementations have hooks to apply temporal behavior in MED-		Some implementations have hooks to apply temporal behavior in MED-
	based best path selection. That is, all other things being equal up		based best path selection. That is, all other things being equal up
	to MED consideration, preference would be applied to the "oldest"		to MED consideration, preference would be applied to the "oldest"
	path, without preferring the lower MED value. The reasoning for this		path, without preferring the lower MED value. The reasoning for this
	is that "older" paths are presumably more stable, and thus more		is that "older" paths are presumably more stable, and thus more
	preferable. However, temporal behavior in route slection results in		preferable. However, temporal behavior in route slection results in
	non-deterministic behavior, and as such, is often undesirable.		non-deterministic behavior, and as such, is often undesirable.
	skipping to change at page 11, line 47		skipping to change at page 10, line 9
	raised by network operators who need to maintain autonomous systems		raised by network operators who need to maintain autonomous systems
	with a large number of peers. Each speaker peering with an external		with a large number of peers. Each speaker peering with an external
	router is responsible for propagating reachability and path		router is responsible for propagating reachability and path
	information to all other transit and border routers within that AS.		information to all other transit and border routers within that AS.
	This is typically done by establishing internal BGP connections to		This is typically done by establishing internal BGP connections to
	all transit and border routers in the local AS.		all transit and border routers in the local AS.
	In a large AS, this leads to a full mesh of TCP connections (n *		In a large AS, this leads to a full mesh of TCP connections (n *
	(n-1)) and some method of configuring and maintaining those		(n-1)) and some method of configuring and maintaining those
	connections. BGP does not specify how this information is to be		connections. BGP does not specify how this information is to be
	propagated, so alternatives, such as injecting BGP attribute		propagated, so alternatives, such as injecting BGP routing
	information into the local IGP have been suggested. Also, there is		information into the local IGP have been attempted, though it turned
	effort underway to develop internal BGP "route reflectors" or a		out to be a non-practical alternative (to say the least).
	reliable multicast transport of IBGP information which would reduce
	configuration, memory and CPU requirements of conveying information
	to all other internal BGP peers.
	BGP "Route Reflector" extensions has been defined in RFC 1966 to		Several alternatives to a full mesh IBGP have been defined, to
	alleviate the the need for "full mesh" IBGP.		include BGP Route Reflection [RFC 2796] and AS Confederations for BGP
			[RFC 2065], in order to alleviate the the need for "full mesh" IBGP.
	9. Internet Dynamics		9. Internet Dynamics
	As discussed in [BGP4-ANALYSIS], the driving force in CPU and		As discussed in [BGP4-ANALYSIS], the driving force in CPU and
	bandwidth utilization is the dynamic nature of routing in the		bandwidth utilization is the dynamic nature of routing in the
	Internet. As the net has grown, the number of route changes per		Internet. As the net has grown, the number of route changes per
	second has increased.		second has increased.
	We automatically get some level of damping when more specific NLRI is		We automatically get some level of damping when more specific NLRI is
	aggregated into larger blocks, however this isn't sufficient. In		aggregated into larger blocks, however, this isn't sufficient. In
	Appendix F of [BGP4] are descriptions of damping techniques that		Appendix F of [BGP4] are descriptions of damping techniques that
	should be applied to advertisements. In future specifications of		should be applied to advertisements. In future specifications of
	BGP-like protocols, damping methods should be considered for		BGP-like protocols, damping methods should be considered for
	mandatory inclusion in compliant implementations.		mandatory inclusion in compliant implementations.
			BGP Route Flap Damping is defined in [RFC 2439]. BGP Route Flap
			Damping defines a mechanism to help reduce the amount of routing
			information passed between BGP peers, and subsequently, the load on
			these peers, without adversely affecting route convergence time for
			relatively stable routes.
	Route changes are announced using BGP UPDATE messages. The greatest		Route changes are announced using BGP UPDATE messages. The greatest
	overhead in advertising UPDATE messages happens whenever route		overhead in advertising UPDATE messages happens whenever route
	changes to be announced are inefficiently packed.Announcing routing		changes to be announced are inefficiently packed. As previously
	changes sharing common attributes in a single BGP UPDATE message		discussed, announcing routing changes sharing common attributes in a
	[13.1] also helps save considerable bandwidth.		single BGP UPDATE message helps save considerable bandwidth and lower
			processing overhead.
	Persistent BGP errors may cause BGP peers to flap persistently if		Persistent BGP errors may cause BGP peers to flap persistently if
	peer dampening is not implemented. This would result in significant		peer dampening is not implemented. This would result in significant
	CPU utilization. Implementors may find it useful to implement peer		CPU utilization. Implementors may find it useful to implement peer
	dampening to avoid such persistent peer flapping [BGP4].		dampening to avoid such persistent peer flapping [BGP4].
	10. BGP Routing Information Bases (RIBs)		10. BGP Routing Information Bases (RIBs)
	[BGP4] states "Any local policy which results in routes being added		[BGP4] states "Any local policy which results in routes being added
	to an Adj-RIB-Out without also being added to the local BGP speaker's		to an Adj-RIB-Out without also being added to the local BGP speaker's
	skipping to change at page 13, line 19		skipping to change at page 11, line 28
	It may be desirable for an implementation to provide a knob that		It may be desirable for an implementation to provide a knob that
	permits advertisement of "inactive" BGP routes.		permits advertisement of "inactive" BGP routes.
	It may be also desirable for an implementation to provide a knob that		It may be also desirable for an implementation to provide a knob that
	allows a BGP speaker to advertise BGP routes that were not selected		allows a BGP speaker to advertise BGP routes that were not selected
	by descision process.		by descision process.
	11. Update Packing		11. Update Packing
			Multiple unfeasible routes can be advertised in a single BGP Update
			message. In addition, one or more feasible routes can be advertised
			in a single Update message so long as all prefixes share a common
			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
	possible, update packing is recommended as it provides a mechanism		possible, update packing is recommended as it provides a mechanism
	for more efficient behavior in a number of areas, to include:		for more efficient behavior in a number of areas, to include:
	o Reduction in system overhead due to generation or receipt of		o Reduction in system overhead due to generation or receipt of
	fewer Update messages.		fewer Update messages.
	o Reduction in network overhead as a result of less packets		o Reduction in network overhead as a result of less packets
	and lower bandwidth consumption.		and lower bandwidth consumption.
	o Allows you to process path attributes and look for matching		o Allows you to process path attributes and look for matching
	sets in your AS_PATH database (if you have one) less		sets in your AS_PATH database (if you have one) less
	frequently. Consistent ordering of the path attributes		frequently. Consistent ordering of the path attributes
	allows for ease of matching in the database as you don't have		allows for ease of matching in the database as you don't have
	different representations of the same data.		different representations of the same data.
	The BGP protocol suggests that withdrawal information should be		The BGP protocol suggests that withdrawal information should be
	packed in the begining of Update message along with information about		packed in the begining of Update message, followed by information
	more or less specific reachable routes in a single UPDATE message.		about more or less specific reachable routes in a single UPDATE
	This would help alleviate excessive route flapping in BGP.		message. This helps alleviate excessive route flapping in BGP.
	12. Limit Rate Updates		12. Limit Rate Updates
	The BGP protocol defines different mechanisms to rate limit the		The BGP protocol defines different mechanisms to rate limit the
	Updates. The BGP protocol defines MinRouteAdvertisementInterval		Updates. The BGP protocol defines MinRouteAdvertisementInterval
	parameter that determines the minimum time that must be elsape		parameter that determines the minimum time that must be elsape
	between the advertisement of routes to a particular destination from		between the advertisement of routes to a particular destination from
	a single BGP speaker. This value is set on a per BGP peer basis.		a single BGP speaker. This value is set on a per BGP peer basis.
	13. Ordering of Path Attributes		13. Ordering of Path Attributes
	skipping to change at page 14, line 35		skipping to change at page 13, line 11
	aggregation. AS_SETs are usually sorted in increasing order to		aggregation. AS_SETs are usually sorted in increasing order to
	facilitate efficient lookups of AS numbers within them. This		facilitate efficient lookups of AS numbers within them. This
	optimization is entirely optional.		optimization is entirely optional.
	15. Control over Version Negotiation		15. Control over Version Negotiation
	Because pre-BGP-4 route aggregation can't be supported by earlier		Because pre-BGP-4 route aggregation can't be supported by earlier
	version of BGP, an implementation that supports versions in addition		version of BGP, an implementation that supports versions in addition
	to BGP-4 should provide the version support on a per-peer basis.		to BGP-4 should provide the version support on a per-peer basis.
	16. Reciept of Non-Transitive Attributes from eBGP Peer		16. Security Considerations
	E.g., LOCAL_PREF, RR or confed, etc..
	NEEDS MORE WORK
	17. Security Considerations
	BGP provides flexible and extendable mechanism for authentication and		BGP provides flexible and extendable mechanism for authentication and
	security. The mechanism allows to support schemes with various		security. The mechanism allows to support schemes with various
	degree of complexity. BGP sessions are authenticated based on the IP		degree of complexity. BGP sessions are authenticated based on the IP
	address of a peer. In addition, all BGP sessions are authenticated		address of a peer. In addition, all BGP sessions are authenticated
	based on the autonomous system number advertised by a peer.		based on the autonomous system number advertised by a peer.
	Since BGP runs over TCP and IP, BGP's authentication scheme may be		Since BGP runs over TCP and IP, BGP's authentication scheme may be
	augmented by any authentication or security mechanism provided by		augmented by any authentication or security mechanism provided by
	either TCP or IP.		either TCP or IP.
	17.1. TCP MD5 Signature Option		16.1. TCP MD5 Signature Option
	RFC 2385 defines a way in which the TCP MD5 signature option can be		RFC 2385 defines a way in which the TCP MD5 signature option can be
	used to valid information transmitted between two peers. This method		used to valid information transmitted between two peers. This method
	prevents any third party from injecting information (e.g., a TCP RST)		prevents any third party from injecting information (e.g., a TCP RST)
	into the datastream, or modifying the routing information carried		into the datastream, or modifying the routing information carried
	between two BGP peers. RFC ???? provides suggestions for choosing		between two BGP peers. RFC ???? provides suggestions for choosing
	passwords to be used with MD5.		passwords to be used with MD5.
	TCP MD5 is not ubiquitously deployed at the moment, especially in		TCP MD5 is not ubiquitously deployed at the moment, especially in
	inter- domain scenarios, largely because of key distribution issues.		inter- domain scenarios, largely because of key distribution issues.
	Most key distribution mechanisms are considered to be too "heavy" at		Most key distribution mechanisms are considered to be too "heavy" at
	this point.		this point.
	17.2. BGP Over IPSEC		16.2. BGP Over IPSEC
	BGP can run over IPSEC, either in a tunnel, or in transport mode,		BGP can run over IPSEC, either in a tunnel, or in transport mode,
	where the TCP portion of the IP packet is encrypted. This not only		where the TCP portion of the IP packet is encrypted. This not only
	prevents random insertion of information into the data stream between		prevents random insertion of information into the data stream between
	two BGP peers, it also prevents an attacker from learning the data		two BGP peers, it also prevents an attacker from learning the data
	which is being exchanged between the peers.		which is being exchanged between the peers.
	IPSEC does, however, offer several options for exchanging session		IPSEC does, however, offer several options for exchanging session
	keys, which may be useful on inter-domain configurations. These		keys, which may be useful on inter-domain configurations. These
	options are being explored in many deployments, although no		options are being explored in many deployments, although no
	definitive solution has been reach on the issue of key exchange for		definitive solution has been reach on the issue of key exchange for
	BGP in IPSEC.		BGP in IPSEC.
	It should be noted that since BGP runs over TCP and IP, BGP is		It should be noted that since BGP runs over TCP and IP, BGP is
	vulnerable to the same denial of service or authentication attacks		vulnerable to the same denial of service or authentication attacks
	that are present in any other TCP based protocol.		that are present in any other TCP based protocol.
	17.3. Miscellaneous		16.3. Miscellaneous
	Another issue any routing protocol faces is providing evidence of the		Another issue any routing protocol faces is providing evidence of the
	validity and authority of the routing information carried within the		validity and authority of the routing information carried within the
	routing system. This is currently the focus of several efforts at		routing system. This is currently the focus of several efforts at
	the moment, including efforts to define the threats which can be used		the moment, including efforts to define the threats which can be used
	against this routing information in BGP [draft-murphy, attack tree],		against this routing information in BGP [draft-murphy, attack tree],
	and efforts at developing a means to provide validation and authority		and efforts at developing a means to provide validation and authority
	for routing information carried within BGP [SBGP] [soBGP].		for routing information carried within BGP [SBGP] [soBGP].
	In addition, the Routing Protocol Security Requirements (RPSEC)		In addition, the Routing Protocol Security Requirements (RPSEC)
	working group has been chartered within the Routing Area of the IETF		working group has been chartered within the Routing Area of the IETF
	in order to discuss and assist in addressing issues surrounding		in order to discuss and assist in addressing issues surrounding
	routing protocol security. It is the intent that this work within		routing protocol security. It is the intent that this work within
	RPSEC will result in feedback to BGPv4 and future enhancements to the		RPSEC will result in feedback to BGPv4 and future enhancements to the
	protocol where appropriate.		protocol where appropriate.
	17.4. PTOMAINE and GROW		16.4. PTOMAINE and GROW
	The Prefix Taxonomy (PTOMAINE) working group, recently replaced by		The Prefix Taxonomy (PTOMAINE) working group, recently replaced by
	the Global Routing Operations (GROW) working group, is chartered to		the Global Routing Operations (GROW) working group, is chartered to
	consider and measure the problem of routing table growth, the effects		consider and measure the problem of routing table growth, the effects
	of the interactions between interior and exterior routing protocols,		of the interactions between interior and exterior routing protocols,
	and the effect of address allocation policies and practices on the		and the effect of address allocation policies and practices on the
	global routing system. Finally, where appropriate, GROW will also		global routing system. Finally, where appropriate, GROW will also
	document the operational aspects of measurement, policy, security and		document the operational aspects of measurement, policy, security and
	VPN infrastructures.		VPN infrastructures.
	It is the intent that this work within GROW will result in feedback		One such item GROW is currently studying is the effects of route
	to BGPv4 and future enhancements to the protocol as necessary.
	One thing that I think you might want to add is something about
	aggregation and the inability to aggregate over multiple provider		aggregation and the inability to aggregate over multiple provider
	boundaries due to inadequate provider coordination. If you want you		boundaries due to inadequate provider coordination.
	can cite the ptomaine work if anything came of it or just mention
	that the WG was created to address problems in this area.
	If you want something on the PRD to IRR and RPSL I can put together a		It is the intent that this work within GROW will result in feedback
	few paragraphs.		to BGPv4 and future enhancements to the protocol as necessary.
	17.5. Internet Routing Registries (IRRs)		16.5. Internet Routing Registries (IRRs)
	Many organizations register their routing policy and prefix		Many organizations register their routing policy and prefix
	origination in the various distributed databases of the Internet		origination in the various distributed databases of the Internet
	Routing Registry. These databases provide access to the information		Routing Registry. These databases provide access to the information
	using the RPSL language as defined in [RFC 2622]. While registered		using the RPSL language as defined in [RFC 2622]. While registered
	information may be maintained and correct for certain providers, the		information may be maintained and correct for certain providers, the
	lack of timely or correct data in the various IRR databases has		lack of timely or correct data in the various IRR databases has
	prevented wide-spread use of this resource.		prevented wide-spread use of this resource.
	17.6. Acknowledgements		16.6. Acknowledgements
	We would like to thank Paul Traina and Yakov Rekhter for authoring		We would like to thank Paul Traina and Yakov Rekhter for authoring
	previous versions of this document. We would also like to		previous versions of this document. We would also like to
	acknowledge Russ White, Jeffrey Haas and Curtis Villamizar for		acknowledge Russ White, Jeffrey Haas and Curtis Villamizar for
	valuable feedback on this document.		valuable feedback on this document.
	18. References		17. References
	[RFC 1105] Lougheed, K., and Rekhter, Y, "Border Gateway Protocol		[RFC 1105] Lougheed, K., and Rekhter, Y, "Border Gateway Protocol
	BGP", RFC 1105, June 1989.		BGP", RFC 1105, June 1989.
	[RFC 1163] Lougheed, K., and Rekhter, Y, "Border Gateway Protocol		[RFC 1163] Lougheed, K., and Rekhter, Y, "Border Gateway Protocol
	BGP", RFC 1105, June 1990.		BGP", RFC 1105, June 1990.
	[RFC 1264] Hinden, R., "Internet Routing Protocol Standardization		[RFC 1264] Hinden, R., "Internet Routing Protocol Standardization
	Criteria", RFC 1264, October 1991.		Criteria", RFC 1264, October 1991.
	skipping to change at page 18, line 36		skipping to change at page 16, line 36
	[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 1772] Rekhter, Y., and P. Gross, Editors, "Application of the		[RFC 1772] Rekhter, Y., and P. Gross, Editors, "Application of the
	Border Gateway Protocol in the Internet", RFC 1772, March		Border Gateway Protocol in the Internet", RFC 1772, March
	1995.		1995.
	[RFC 1773] Traina, P., "Experience with the BGP-4 protocol", RFC		[RFC 1773] Traina, P., "Experience with the BGP-4 protocol", RFC
	1773, March 1995.		1773, March 1995.
			[RFC 2439] Villamizar, C. and Chandra, R., "BGP Route Flap Damping",
			RFC 2439, November 1998.
	[RFC 2622] C. Alaettinoglu et al., "Routing Policy Specification		[RFC 2622] C. Alaettinoglu et al., "Routing Policy Specification
	Language", RFC 2622, June 1999.		Language", RFC 2622, June 1999.
	[RFC 2796] Bates, T., Chandra, R., and Chen, E, "Route Reflection -		[RFC 2796] Bates, T., Chandra, R., and Chen, E, "Route Reflection -
	An Alternative to Full Mesh IBGP", RFC 2796, April 2000.		An Alternative to Full Mesh IBGP", RFC 2796, April 2000.
	[RFC 3065] Traina, P., McPherson, D., and Scudder, J, "Autonomous		[RFC 3065] Traina, P., McPherson, D., and Scudder, J, "Autonomous
	System Confederations for BGP", RFC 3065, Febuary 2001.		System Confederations for BGP", RFC 3065, Febuary 2001.
	[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.
	[BGP4-ANALYSIS] Work in Progress.		[BGP4-ANALYSIS] Work in Progress.
	[BGP4-IMPL] Work in Progress.		[BGP4-IMPL] Work in Progress.
	[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.
	19. Authors' Addresses		18. Authors' Addresses
	Danny McPherson		Danny McPherson
	Arbor Networks		Arbor Networks
	Email: danny@arbor.net		Email: danny@arbor.net
	Keyur Patel		Keyur Patel
	Cisco Systems		Cisco Systems
	Email: keyupate@cisco.com		Email: keyupate@cisco.com
	20. Full Copyright Statement		19. Full Copyright Statement
	Copyright (C) The Internet Society (2003). All Rights Reserved.		Copyright (C) The Internet Society (2003). All Rights Reserved.
	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
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/