draft-ietf-idr-ix-bgp-route-server-00.txt		draft-ietf-idr-ix-bgp-route-server-01.txt
	IDR Working Group E. Jasinska		IDR Working Group E. Jasinska
	Internet-Draft Limelight Networks		Internet-Draft Limelight Networks
	Intended status: Standards Track N. Hilliard		Intended status: Standards Track N. Hilliard
	Expires: September 27, 2012 INEX		Expires: January 17, 2013 INEX
	R. Raszuk		R. Raszuk
	NTT MCL Inc.		NTT MCL Inc.
	N. Bakker		N. Bakker
	AMS-IX B.V.		AMS-IX B.V.
	March 26, 2012		July 16, 2012
	Internet Exchange Route Server		Internet Exchange Route Server
	draft-ietf-idr-ix-bgp-route-server-00		draft-ietf-idr-ix-bgp-route-server-01
	Abstract		Abstract
	This document outlines a specification for multilateral		This document outlines a specification for multilateral
	interconnections at Internet exchange points (IXPs). Multilateral		interconnections at Internet exchange points (IXPs). Multilateral
	interconnection is a method of exchanging routing information between		interconnection is a method of exchanging routing information between
	three or more exterior BGP speakers using a single intermediate		three or more exterior BGP speakers using a single intermediate
	broker system, referred to as a route server. Route servers are		broker system, referred to as a route server. Route servers are
	typically used on shared access media networks, such as Internet		typically used on shared access media networks, such as Internet
	exchange points (IXPs), to facilitate simplified interconnection		exchange points (IXPs), to facilitate simplified interconnection
	skipping to change at page 1, line 42		skipping to change at page 1, line 42
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on September 27, 2012.		This Internet-Draft will expire on January 17, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 IETF Trust and the persons identified as the		Copyright (c) 2012 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction to Multilateral Interconnection . . . . . . . . . 3		1. Introduction to Multilateral Interconnection . . . . . . . . . 3
	1.1. Specification of Requirements . . . . . . . . . . . . . . 3		1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 3
	2. Technical Considerations for Route Server Implementations . . 4		2. Technical Considerations for Route Server Implementations . . 4
	2.1. Client UPDATE Messages . . . . . . . . . . . . . . . . . . 4		2.1. Client UPDATE Messages . . . . . . . . . . . . . . . . . . 4
	2.2. Attribute Transparency . . . . . . . . . . . . . . . . . . 4		2.2. Attribute Transparency . . . . . . . . . . . . . . . . . . 4
	2.2.1. NEXT_HOP Attribute . . . . . . . . . . . . . . . . . . 4		2.2.1. NEXT_HOP Attribute . . . . . . . . . . . . . . . . . . 4
	2.2.2. AS_PATH Attribute . . . . . . . . . . . . . . . . . . 4		2.2.2. AS_PATH Attribute . . . . . . . . . . . . . . . . . . 4
	2.2.3. MULTI_EXIT_DISC Attribute . . . . . . . . . . . . . . 5		2.2.3. MULTI_EXIT_DISC Attribute . . . . . . . . . . . . . . 5
	2.2.4. Communities Attributes . . . . . . . . . . . . . . . . 5		2.2.4. Communities Attributes . . . . . . . . . . . . . . . . 5
	2.3. Per-Client Policy Control in Multilateral		2.3. Per-Client Policy Control in Multilateral
	Interconnection . . . . . . . . . . . . . . . . . . . . . 5		Interconnection . . . . . . . . . . . . . . . . . . . . . 5
	2.3.1. Path Hiding on a Route Server . . . . . . . . . . . . 6		2.3.1. Path Hiding on a Route Server . . . . . . . . . . . . 6
	2.3.2. Implementing Per-Client Policy Control . . . . . . . . 7		2.3.2. Mitigation of Path Hiding . . . . . . . . . . . . . . 7
	2.3.2.1. Multiple Route Server RIBs . . . . . . . . . . . . 7		2.3.2.1. Multiple Route Server RIBs . . . . . . . . . . . . 7
	2.3.2.2. Advertising Multiple Paths . . . . . . . . . . . . 7		2.3.2.2. Advertising Multiple Paths . . . . . . . . . . . . 7
			2.3.3. Implementation Recommendations . . . . . . . . . . . . 8
	3. Security Considerations . . . . . . . . . . . . . . . . . . . 8		3. Security Considerations . . . . . . . . . . . . . . . . . . . 8
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
	5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9		5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
	6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9		6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	6.1. Normative References . . . . . . . . . . . . . . . . . . . 9		6.1. Normative References . . . . . . . . . . . . . . . . . . . 9
	6.2. Informative References . . . . . . . . . . . . . . . . . . 9		6.2. Informative References . . . . . . . . . . . . . . . . . . 9
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
	1. Introduction to Multilateral Interconnection		1. Introduction to Multilateral Interconnection
	Internet exchange points (IXPs) provide IP data interconnection		Internet exchange points (IXPs) provide IP data interconnection
	facilities for their participants, typically using shared Layer-2		facilities for their participants, typically using shared Layer-2
	skipping to change at page 3, line 35		skipping to change at page 3, line 35
	reachability information to the route server using exterior BGP, and		reachability information to the route server using exterior BGP, and
	the route server in turn forwards this information to each other		the route server in turn forwards this information to each other
	route server client connected to it, according to its configuration.		route server client connected to it, according to its configuration.
	Although a route server uses BGP to exchange reachability information		Although a route server uses BGP to exchange reachability information
	with each of its clients, it does not forward traffic itself and is		with each of its clients, it does not forward traffic itself and is
	therefore not a router.		therefore not a router.
	A route server can be viewed as similar in function to an [RFC4456]		A route server can be viewed as similar in function to an [RFC4456]
	route reflector, except that it operates using EBGP instead of iBGP.		route reflector, except that it operates using EBGP instead of iBGP.
	Certain adaptions to [RFC4271] are required to enable an EBGP router		Certain adaptions to [RFC4271] are required to enable an EBGP router
	to operate as a route server, which are outlined in Section 2 of this		to operate as a route server; these are outlined in Section 2 of this
	document.		document.
	The term "route server" is often in a different context used to		The term "route server" is often in a different context used to
	describe a BGP node whose purpose is to accept BGP feeds from		describe a BGP node whose purpose is to accept BGP feeds from
	multiple clients for the purpose of operational analysis and		multiple clients for the purpose of operational analysis and
	troubleshooting. A system of this form may alternatively be known as		troubleshooting. A system of this form may alternatively be known as
	a "route collector" or a "route-views server". This document uses		a "route collector" or a "route-views server". This document uses
	the term "route server" exclusively to describe multilateral peering		the term "route server" exclusively to describe multilateral peering
	brokerage systems.		brokerage systems.
	1.1. Specification of Requirements		1.1. Notational Conventions
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in		"OPTIONAL" in this document are to be interpreted as described in
	[RFC2119].		[RFC2119].
	2. Technical Considerations for Route Server Implementations		2. Technical Considerations for Route Server Implementations
	2.1. Client UPDATE Messages		2.1. Client UPDATE Messages
	A route server MUST accept all UPDATE messages received from each of		A route server MUST accept all UPDATE messages received from each of
	its clients for inclusion in its Adj-RIB-In. These UPDATE messages		its clients for inclusion in its Adj-RIB-In. These UPDATE messages
	MAY by omitted from the route server's Loc-RIB or Loc-RIBs, due to		MAY be omitted from the route server's Loc-RIB or Loc-RIBs, due to
	filters configured for the purposes of implementing routing policy.		filters configured for the purposes of implementing routing policy.
	The route server SHOULD perform one or more BGP Decision Processes to		The route server SHOULD perform one or more BGP Decision Processes to
	select routes for subsequent advertisement to its clients, taking		select routes for subsequent advertisement to its clients, taking
	into account possible configuration to provide multiple NLRI paths to		into account possible configuration to provide multiple NLRI paths to
	a particular client as described in Section 2.3.2.2 or multiple Loc-		a particular client as described in Section 2.3.2.2 or multiple Loc-
	RIBs as described in Section 2.3.2.1. The route server SHOULD		RIBs as described in Section 2.3.2.1. The route server SHOULD
	forward UPDATE messages where appropriate from its Loc-RIB or Loc-		forward UPDATE messages where appropriate from its Loc-RIB or Loc-
	RIBs to its clients.		RIBs to its clients.
	2.2. Attribute Transparency		2.2. Attribute Transparency
	skipping to change at page 4, line 39		skipping to change at page 4, line 39
	default (unless explicitly configured) update well-known BGP		default (unless explicitly configured) update well-known BGP
	attributes received from route server clients before redistributing		attributes received from route server clients before redistributing
	them to their other route server clients. Optional recognized and		them to their other route server clients. Optional recognized and
	unrecognized BGP attributes, whether transitive or non-transitive,		unrecognized BGP attributes, whether transitive or non-transitive,
	SHOULD NOT be updated by the route server (unless enforced by local		SHOULD NOT be updated by the route server (unless enforced by local
	IX operator configuration) and SHOULD be passed on to other route		IX operator configuration) and SHOULD be passed on to other route
	server clients.		server clients.
	2.2.1. NEXT_HOP Attribute		2.2.1. NEXT_HOP Attribute
	The NEXT_HOP, a well-known mandatory BGP attribute, defines the IP		The NEXT_HOP is a well-known mandatory BGP attribute which defines
	address of the router used as the next hop to the destinations listed		the IP address of the router used as the next hop to the destinations
	in the Network Layer Reachability Information field of the UPDATE		listed in the Network Layer Reachability Information field of the
	message. As the route server does not participate in the actual		UPDATE message. As the route server does not participate in the
	routing of traffic, the NEXT_HOP attribute MUST be passed unmodified		actual routing of traffic, the NEXT_HOP attribute MUST be passed
	to the route server clients, similar to the "third party" next hop		unmodified to the route server clients, similar to the "third party"
	feature described in section 5.1.3. of [RFC4271].		next hop feature described in section 5.1.3. of [RFC4271].
	2.2.2. AS_PATH Attribute		2.2.2. AS_PATH Attribute
	AS_PATH is a well-known mandatory attribute which identifies the		AS_PATH is a well-known mandatory attribute which identifies the
	autonomous systems through which routing information carried in the		autonomous systems through which routing information carried in the
	UPDATE message has passed.		UPDATE message has passed.
	As a route server does not participate in the process of forwarding		As a route server does not participate in the process of forwarding
	data between client routers, and because modification of the AS_PATH		data between client routers, and because modification of the AS_PATH
	attribute could affect route server client best path calculations,		attribute could affect route server client best path calculations,
	the route server SHOULD NOT prepend its own AS number to the AS_PATH		the route server SHOULD NOT prepend its own AS number to the AS_PATH
	segment nor modify the AS_PATH segment in any other way.		segment nor modify the AS_PATH segment in any other way.
	2.2.3. MULTI_EXIT_DISC Attribute		2.2.3. MULTI_EXIT_DISC Attribute
	MULTI_EXIT_DISC is an optional non-transitive attribute intended to		MULTI_EXIT_DISC is an optional non-transitive attribute intended to
	be used on external (inter-AS) links to discriminate among multiple		be used on external (inter-AS) links to discriminate among multiple
	exit or entry points to the same neighboring AS. If applied to an		exit or entry points to the same neighboring AS. Contrary to section
	NLRI UPDATE sent to a route server, the attribute (contrary to		5.1.4 of [RFC4271], if applied to an NLRI UPDATE sent to a route
	section 5.1.4 of [RFC4271]) SHOULD be propagated to other route		server, this attribute SHOULD be propagated to other route server
	server clients and the route server SHOULD NOT modify the value of		clients and the route server SHOULD NOT modify its value.
	this attribute.
	2.2.4. Communities Attributes		2.2.4. Communities Attributes
	The BGP COMMUNITIES ([RFC1997]) and Extended Communities ([RFC4360])		The BGP COMMUNITIES ([RFC1997]) and Extended Communities ([RFC4360])
	attributes are attributes intended for labeling information carried		attributes are attributes intended for labeling information carried
	in BGP UPDATE messages. Transitive as well as non-transitive		in BGP UPDATE messages. Transitive as well as non-transitive
	Communities attributes applied to an NLRI UPDATE sent to a route		Communities attributes applied to an NLRI UPDATE sent to a route
	server SHOULD NOT be modified, processed or removed. However, if		server SHOULD NOT be modified, processed or removed. However, if
	such an attribute is intended for processing by the route server		such an attribute is intended for processing by the route server
	itself, it MAY be modified or removed.		itself, it MAY be modified or removed.
	2.3. Per-Client Policy Control in Multilateral Interconnection		2.3. Per-Client Policy Control in Multilateral Interconnection
	While IXP participants often use route servers with the intention of		While IXP participants often use route servers with the intention of
	interconnecting with as many other route server participants as		interconnecting with as many other route server participants as
	possible, there are circumstances where control of path distribution		possible, there are circumstances where control of path distribution
	on a per-client basis is important for ensuring that desired		on a per-client basis is important to ensure that desired
	interconnection policies are met.		interconnection policies are met.
	The control of path distribution on a per-client basis can lead to a		The control of path distribution on a per-client basis can lead to a
	path being hidden from the route server client. We refer to this as		path being hidden from the route server client. We refer to this as
	"path hiding", which is described in Section 2.3.1.		"path hiding".
	Route server implementations SHOULD implement one of the methods
	described in Section 2.3.2, for the operator to be able to allow the
	control of path distribution on a per-client basis without the
	occurrence of "path hiding".
	2.3.1. Path Hiding on a Route Server		2.3.1. Path Hiding on a Route Server
	___ ___		___ ___
	/ \ / \		/ \ / \
	..| AS1 |..| AS2 |..		..| AS1 |..| AS2 |..
	: \___/ \___/ :		: \___/ \___/ :
	: \ / | :		: \ / | :
	: \ / | :		: \ / | :
	: IXP \/ | :		: IXP \/ | :
	skipping to change at page 7, line 7		skipping to change at page 7, line 7
	For example, in Figure 1, if the same prefix were sent to the route		For example, in Figure 1, if the same prefix were sent to the route
	server via AS2 and AS4, and the route via AS2 was preferred according		server via AS2 and AS4, and the route via AS2 was preferred according
	to BGP's traditional best path selection, but AS1's policy prevents		to BGP's traditional best path selection, but AS1's policy prevents
	AS2's path from being accepted, then AS1 would never receive a path		AS2's path from being accepted, then AS1 would never receive a path
	to this prefix, even though the route server had previously received		to this prefix, even though the route server had previously received
	a valid alternative path via AS4. This happens because the best path		a valid alternative path via AS4. This happens because the best path
	selection is performed only once on the route server for all clients.		selection is performed only once on the route server for all clients.
	Path hiding will only occur on route servers which employ per-client		Path hiding will only occur on route servers which employ per-client
	policy control; if an IXP operator deploys a route server without the		policy control; if an IXP operator deploys a route server without
	possibility for policy control, then path hiding does not occur, as		implementing a per-client routing policy control system, then path
	all paths are considered equally valid from the point of view of the		hiding does not occur as all paths are considered equally valid from
	route server.		the point of view of the route server.
	2.3.2. Implementing Per-Client Policy Control		2.3.2. Mitigation of Path Hiding
	In this section, we describe the alternatives to provide per-client		There are several approaches which can be taken to mitigate against
	policy control while preventing the occurrence of path hiding.		path hiding.
	2.3.2.1. Multiple Route Server RIBs		2.3.2.1. Multiple Route Server RIBs
	The most portable means to allow for per-client policy control		The most portable method to allow for per-client policy control
	without the occurrence of path hiding, is by using a route server BGP		without the occurrence of path hiding, is by using a route server BGP
	implementation which performs the per-client best path calculation		implementation which performs the per-client best path calculation
	for each set of paths to a prefix, which results after the route		for each set of paths to a prefix, which results after the route
	server's client policies have been taken into consideration. This		server's client policies have been taken into consideration. This
	can be implemented by using per-client Loc-RIBs, with path filtering		can be implemented by using per-client Loc-RIBs, with path filtering
	implemented between the Adj-RIB-In and the per-client Loc-RIB.		implemented between the Adj-RIB-In and the per-client Loc-RIB.
	Implementations MAY optimize this by maintaining paths not subject to		Implementations MAY optimize this by maintaining paths not subject to
	filtering policies in a global Loc-RIB, with per-client Loc-RIBs		filtering policies in a global Loc-RIB, with per-client Loc-RIBs
	stored as deltas.		stored as deltas.
	skipping to change at page 8, line 39		skipping to change at page 8, line 39
	If the ADD-PATH capability is negotiated bidirectionally between the		If the ADD-PATH capability is negotiated bidirectionally between the
	route server and a route server client, and the route server client		route server and a route server client, and the route server client
	propagates multiple paths for the same prefix to the route server,		propagates multiple paths for the same prefix to the route server,
	then this could potentially cause the propagation of inactive,		then this could potentially cause the propagation of inactive,
	invalid or suboptimal paths to the route server, thereby causing loss		invalid or suboptimal paths to the route server, thereby causing loss
	of reachability to other route server clients. For this reason, ADD-		of reachability to other route server clients. For this reason, ADD-
	PATH implementations on a route server SHOULD enforce send-only mode		PATH implementations on a route server SHOULD enforce send-only mode
	with the route server clients, which would result in negotiating		with the route server clients, which would result in negotiating
	receive-only mode from the client to the route server.		receive-only mode from the client to the route server.
			2.3.3. Implementation Recommendations
			A route server SHOULD implement one of the methods described in
			Section 2.3.2 to allow per-client routing policy control without
			"path hiding".
	3. Security Considerations		3. Security Considerations
	The path hiding problem outlined in section Section 2.3.1 can be used		The path hiding problem outlined in section Section 2.3.1 can be used
	in certain circumstances to proactively block third party path		in certain circumstances to proactively block third party path
	announcements from other route server clients.		announcements from other route server clients. Route server
			operators should be aware that security issues may arise unless steps
			are taken to mitigate against path hiding.
	4. IANA Considerations		4. IANA Considerations
	The new set of mechanism for route servers does not require any new		The new set of mechanisms for route servers does not require any new
	allocations from IANA.		allocations from IANA.
	5. Acknowledgments		5. Acknowledgments
	The authors would like to thank Ryan Bickhart, Steven Bakker, Chris		The authors would like to thank Ryan Bickhart, Steven Bakker, Martin
	Hall, Bruno Decraene and Pierre Francois for their valuable input.		Pels, Chris Hall, Aleksi Suhonen, Bruno Decraene, Pierre Francois and
			Eduardo Ascenco Reis for their valuable input.
	In addition, the authors would like to acknowledge the developers of		In addition, the authors would like to acknowledge the developers of
	BIRD, OpenBGPD and Quagga, whose open source BGP implementations		BIRD, OpenBGPD and Quagga, whose open source BGP implementations
	include route server capabilities which are compliant with this		include route server capabilities which are compliant with this
	document.		document.
	6. References		6. References
	6.1. Normative References		6.1. Normative References
	[I-D.ietf-grow-diverse-bgp-path-dist]
	Raszuk, R., Fernando, R., Patel, K., McPherson, D., and K.
	Kumaki, "Distribution of diverse BGP paths.",
	draft-ietf-grow-diverse-bgp-path-dist-06 (work in
	progress), November 2011.
	[I-D.ietf-idr-add-paths]
	Walton, D., Chen, E., Retana, A., and J. Scudder,
	"Advertisement of Multiple Paths in BGP",
	draft-ietf-idr-add-paths-06 (work in progress),
	September 2011.
	[RFC1997] Chandrasekeran, R., Traina, P., and T. Li, "BGP		[RFC1997] Chandrasekeran, R., Traina, P., and T. Li, "BGP
	Communities Attribute", RFC 1997, August 1996.		Communities Attribute", RFC 1997, August 1996.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway		[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
	Protocol 4 (BGP-4)", RFC 4271, January 2006.		Protocol 4 (BGP-4)", RFC 4271, January 2006.
	[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended		[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
	Communities Attribute", RFC 4360, February 2006.		Communities Attribute", RFC 4360, February 2006.
	[RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route
	Reflection: An Alternative to Full Mesh Internal BGP
	(IBGP)", RFC 4456, April 2006.
	6.2. Informative References		6.2. Informative References
			[I-D.ietf-grow-diverse-bgp-path-dist]
			Raszuk, R., Fernando, R., Patel, K., McPherson, D., and K.
			Kumaki, "Distribution of diverse BGP paths.",
			draft-ietf-grow-diverse-bgp-path-dist-07 (work in
			progress), May 2012.
			[I-D.ietf-idr-add-paths]
			Walton, D., Chen, E., Retana, A., and J. Scudder,
			"Advertisement of Multiple Paths in BGP",
			draft-ietf-idr-add-paths-07 (work in progress), June 2012.
	[RFC1863] Haskin, D., "A BGP/IDRP Route Server alternative to a full		[RFC1863] Haskin, D., "A BGP/IDRP Route Server alternative to a full
	mesh routing", RFC 1863, October 1995.		mesh routing", RFC 1863, October 1995.
	[RFC4223] Savola, P., "Reclassification of RFC 1863 to Historic",		[RFC4223] Savola, P., "Reclassification of RFC 1863 to Historic",
	RFC 4223, October 2005.		RFC 4223, October 2005.
	[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,		[RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route
	"Multiprotocol Extensions for BGP-4", RFC 4760,		Reflection: An Alternative to Full Mesh Internal BGP
	January 2007.		(IBGP)", RFC 4456, April 2006.
	[RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous
	System Confederations for BGP", RFC 5065, August 2007.
	[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an		[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
	IANA Considerations Section in RFCs", BCP 26, RFC 5226,		IANA Considerations Section in RFCs", BCP 26, RFC 5226,
	May 2008.		May 2008.
	Authors' Addresses		Authors' Addresses
	Elisa Jasinska		Elisa Jasinska
	Limelight Networks		Limelight Networks
	2220 W 14th St		222 South Mill Avenue
	Tempe, AZ 85281		Tempe, AZ 85281
	US		US
	Email: elisa@llnw.com		Email: elisa@llnw.com
	Nick Hilliard		Nick Hilliard
	INEX		INEX
	4027 Kingswood Road		4027 Kingswood Road
	Dublin 24		Dublin 24
	IE		IE
End of changes. 28 change blocks.
	64 lines changed or deleted		60 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/