draft-ietf-grow-ix-bgp-route-server-operations-01.txt		draft-ietf-grow-ix-bgp-route-server-operations-02.txt
	GROW Working Group N. Hilliard		GROW Working Group N. Hilliard
	Internet-Draft INEX		Internet-Draft INEX
	Intended status: Informational E. Jasinska		Intended status: Informational E. Jasinska
	Expires: March 01, 2014 Microsoft Corporation		Expires: September 4, 2014 Netflix, Inc
	R. Raszuk		R. Raszuk
	NTT I3		NTT I3
	N. Bakker		N. Bakker
	AMS-IX B.V.		Akamai Technologies B.V.
	August 28, 2013		March 3, 2014
	Internet Exchange Route Server Operations		Internet Exchange Route Server Operations
	draft-ietf-grow-ix-bgp-route-server-operations-01		draft-ietf-grow-ix-bgp-route-server-operations-02
	Abstract		Abstract
	The popularity of Internet exchange points (IXPs) brings new		The popularity of Internet exchange points (IXPs) brings new
	challenges to interconnecting networks. While bilateral eBGP		challenges to interconnecting networks. While bilateral eBGP
	sessions between exchange participants were historically the most		sessions between exchange participants were historically the most
	common means of exchanging reachability information over an IXP, the		common means of exchanging reachability information over an IXP, the
	overhead associated with this interconnection method causes serious		overhead associated with this interconnection method causes serious
	operational and administrative scaling problems for IXP participants.		operational and administrative scaling problems for IXP participants.
	skipping to change at page 1, line 48		skipping to change at page 1, line 48
	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 March 01, 2014.		This Internet-Draft will expire on September 4, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3		1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3
	2. Bilateral BGP Sessions . . . . . . . . . . . . . . . . . . . 3		2. Bilateral BGP Sessions . . . . . . . . . . . . . . . . . . . 3
	3. Multilateral Interconnection . . . . . . . . . . . . . . . . 4		3. Multilateral Interconnection . . . . . . . . . . . . . . . . 4
	4. Operational Considerations for Route Server Installations . . 5		4. Operational Considerations for Route Server Installations . . 5
	4.1. Path Hiding . . . . . . . . . . . . . . . . . . . . . . . 5		4.1. Path Hiding . . . . . . . . . . . . . . . . . . . . . . . 5
	4.2. Route Server Scaling . . . . . . . . . . . . . . . . . . 6		4.2. Route Server Scaling . . . . . . . . . . . . . . . . . . 6
	4.2.1. Tackling Scaling Issues . . . . . . . . . . . . . . . 6		4.2.1. Tackling Scaling Issues . . . . . . . . . . . . . . . 6
	4.2.1.1. View Merging and Decomposition . . . . . . . . . 7		4.2.1.1. View Merging and Decomposition . . . . . . . . . 7
	4.2.1.2. Destination Splitting . . . . . . . . . . . . . . 7		4.2.1.2. Destination Splitting . . . . . . . . . . . . . . 7
	4.2.1.3. NEXT_HOP Resolution . . . . . . . . . . . . . . . 8		4.2.1.3. NEXT_HOP Resolution . . . . . . . . . . . . . . . 8
	4.3. Prefix Leakage Mitigation . . . . . . . . . . . . . . . . 8		4.3. Prefix Leakage Mitigation . . . . . . . . . . . . . . . . 8
	4.4. Route Server Redundancy . . . . . . . . . . . . . . . . . 8		4.4. Route Server Redundancy . . . . . . . . . . . . . . . . . 8
	4.5. AS_PATH Consistency Check . . . . . . . . . . . . . . . . 9		4.5. AS_PATH Consistency Check . . . . . . . . . . . . . . . . 9
	4.6. Export Routing Policies . . . . . . . . . . . . . . . . . 9		4.6. Export Routing Policies . . . . . . . . . . . . . . . . . 9
	4.6.1. BGP Communities . . . . . . . . . . . . . . . . . . . 9		4.6.1. BGP Communities . . . . . . . . . . . . . . . . . . . 9
	4.6.2. Internet Routing Registry . . . . . . . . . . . . . . 9		4.6.2. Internet Routing Registry . . . . . . . . . . . . . . 9
	4.6.3. Client-accessible Databases . . . . . . . . . . . . . 10		4.6.3. Client-accessible Databases . . . . . . . . . . . . . 10
	4.7. Layer 2 Reachability Problems . . . . . . . . . . . . . . 10		4.7. Layer 2 Reachability Problems . . . . . . . . . . . . . . 10
	4.8. BGP NEXT_HOP Hijacking . . . . . . . . . . . . . . . . . 10		4.8. BGP NEXT_HOP Hijacking . . . . . . . . . . . . . . . . . 10
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 11		5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12		7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
	8.1. Normative References . . . . . . . . . . . . . . . . . . 12		8.1. Normative References . . . . . . . . . . . . . . . . . . 12
	8.2. Informative References . . . . . . . . . . . . . . . . . 12		8.2. Informative References . . . . . . . . . . . . . . . . . 12
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
	1. Introduction		1. Introduction
	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
	networking media such as Ethernet. The Border Gateway Protocol (BGP)		networking media such as Ethernet. The Border Gateway Protocol (BGP)
	[RFC4271] is normally used to facilitate exchange of network		[RFC4271] is normally used to facilitate exchange of network
	reachability information over these media.		reachability information over these media.
	As bilateral interconnection between IXP participants requires		As bilateral interconnection between IXP participants requires
	operational and administrative overhead, BGP route servers		operational and administrative overhead, BGP route servers
	[I-D.ietf-idr-ix-bgp-route-server] are often deployed by IXP		[I-D.ietf-idr-ix-bgp-route-server] are often deployed by IXP
	operators to provide a simple and convenient means of interconnecting		operators to provide a simple and convenient means of interconnecting
	skipping to change at page 3, line 48		skipping to change at page 4, line 5
	participant wishes to implement an open interconnection policy - i.e.		participant wishes to implement an open interconnection policy - i.e.
	a policy of interconnecting with as many other IXP participants as		a policy of interconnecting with as many other IXP participants as
	possible - it is necessary for the participant to liaise with each of		possible - it is necessary for the participant to liaise with each of
	their intended interconnection partners. Interconnection can then be		their intended interconnection partners. Interconnection can then be
	implemented bilaterally by configuring a BGP session on both		implemented bilaterally by configuring a BGP session on both
	participants' routers to exchange network reachability information.		participants' routers to exchange network reachability information.
	If each exchange participant interconnects with each other		If each exchange participant interconnects with each other
	participant, a full mesh of BGP sessions is needed, as shown in		participant, a full mesh of BGP sessions is needed, as shown in
	Figure 1.		Figure 1.
	___ ___		___ ___
	/ \ / \		/ \ / \
	..| AS1 |..| AS2 |..		..| AS1 |..| AS2 |..
	: \___/____\___/ :		: \___/____\___/ :
			: | \ / | :
	: | \ / | :		: | \ / | :
	: | \ / | :		: IXP | \/ | :
	: IXP | \/ | :		: | /\ | :
	: | /\ | :		: | / \ | :
	: | / \ | :		: _|_/____\_|_ :
	: _|_/____\_|_ :		: / \ / \ :
	: / \ / \ :		..| AS3 |..| AS4 |..
	..| AS3 |..| AS4 |..		\___/ \___/
	\___/ \___/
	Figure 1: Full-Mesh Interconnection at an IXP		Figure 1: Full-Mesh Interconnection at an IXP
	Figure 1 depicts an IXP platform with four connected routers,		Figure 1 depicts an IXP platform with four connected routers,
	administered by four separate exchange participants, each of them		administered by four separate exchange participants, each of them
	with a locally unique autonomous system number: AS1, AS2, AS3 and		with a locally unique autonomous system number: AS1, AS2, AS3 and
	AS4. Each of these four participants wishes to exchange traffic with		AS4. Each of these four participants wishes to exchange traffic with
	all other participants; this is accomplished by configuring a full		all other participants; this is accomplished by configuring a full
	mesh of BGP sessions on each router connected to the exchange,		mesh of BGP sessions on each router connected to the exchange,
	resulting in 6 BGP sessions across the IXP fabric.		resulting in 6 BGP sessions across the IXP fabric.
	skipping to change at page 5, line 17		skipping to change at page 5, line 19
	therefore not a router.		therefore not a router.
	In practical terms, this allows dense interconnection between IXP		In practical terms, this allows dense interconnection between IXP
	participants with low administrative overhead and significantly		participants with low administrative overhead and significantly
	simpler and smaller router configurations. In particular, new IXP		simpler and smaller router configurations. In particular, new IXP
	participants benefit from immediate and extensive interconnection,		participants benefit from immediate and extensive interconnection,
	while existing route server participants receive reachability		while existing route server participants receive reachability
	information from these new participants without necessarily having to		information from these new participants without necessarily having to
	modify their configurations.		modify their configurations.
	___ ___		___ ___
	/ \ / \		/ \ / \
	..| AS1 |..| AS2 |..		..| AS1 |..| AS2 |..
	: \___/ \___/ :		: \___/ \___/ :
	: \ / :		: \ / :
	: \ / :		: \ / :
	: \__/ :		: \__/ :
	: IXP / \ :		: IXP / \ :
	: | RS | :		: | RS | :
	: \____/ :		: \____/ :
	: / \ :		: / \ :
	: / \ :		: / \ :
	: __/ \__ :		: __/ \__ :
	: / \ / \ :		: / \ / \ :
	..| AS3 |..| AS4 |..		..| AS3 |..| AS4 |..
	\___/ \___/		\___/ \___/
	Figure 2: IXP-based Interconnection with Route Server		Figure 2: IXP-based Interconnection with Route Server
	As illustrated in Figure 2, each router on the IXP fabric requires		As illustrated in Figure 2, each router on the IXP fabric requires
	only a single BGP session to the route server, from which it can		only a single BGP session to the route server, from which it can
	receive reachability information for all other routers on the IXP		receive reachability information for all other routers on the IXP
	which also connect to the route server.		which also connect to the route server.
	4. Operational Considerations for Route Server Installations		4. Operational Considerations for Route Server Installations
	skipping to change at page 10, line 50		skipping to change at page 11, line 5
	4.8. BGP NEXT_HOP Hijacking		4.8. BGP NEXT_HOP Hijacking
	Section 5.1.3(2) of [RFC4271] allows eBGP speakers to change the		Section 5.1.3(2) of [RFC4271] allows eBGP speakers to change the
	NEXT_HOP address of an NLRI update to be a different internet address		NEXT_HOP address of an NLRI update to be a different internet address
	on the same subnet. This is the mechanism which allows route servers		on the same subnet. This is the mechanism which allows route servers
	to operate on a shared layer 2 IXP network. However, the mechanism		to operate on a shared layer 2 IXP network. However, the mechanism
	can be abused by route server clients to redirect traffic for their		can be abused by route server clients to redirect traffic for their
	prefixes to other IXP participant routers.		prefixes to other IXP participant routers.
	____		____
	/ \		/ \
			| AS99 |
	| AS99 |		\____/
	\____/		/ \
	/ \		/ \
	/ \		__/ \__
	__/ \__		/ \ / \
	/ \ / \		..| AS1 |..| AS2 |..
	..| AS1 |..| AS2 |..		: \___/ \___/ :
	: \___/ \___/ :		: \ / :
	: \ / :		: \ / :
	: \ / :		: \__/ :
	: \__/ :		: IXP / \ :
	: IXP / \ :		: | RS | :
	: | RS | :		: \____/ :
	: \____/ :		: :
	: :		....................
	....................
	Figure 3: BGP NEXT_HOP Hijacking using a Route Server		Figure 3: BGP NEXT_HOP Hijacking using a Route Server
	For example in Figure 3, if AS1 and AS2 both announce prefixes for		For example in Figure 3, if AS1 and AS2 both announce prefixes for
	AS99 to the route server, AS1 could set the NEXT_HOP address for		AS99 to the route server, AS1 could set the NEXT_HOP address for
	AS99's prefixes to be the address of AS2's router, thereby diverting		AS99's prefixes to be the address of AS2's router, thereby diverting
	traffic for AS99 via AS2. This may override the routing policies of		traffic for AS99 via AS2. This may override the routing policies of
	AS99 and AS2.		AS99 and AS2.
	Worse still, if the route server operator does not use inbound prefix		Worse still, if the route server operator does not use inbound prefix
	skipping to change at page 12, line 38		skipping to change at page 12, line 41
	include route server capabilities which are compliant with this		include route server capabilities which are compliant with this
	document.		document.
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[I-D.ietf-idr-ix-bgp-route-server]		[I-D.ietf-idr-ix-bgp-route-server]
	Jasinska, E., Hilliard, N., Raszuk, R., and N. Bakker,		Jasinska, E., Hilliard, N., Raszuk, R., and N. Bakker,
	"Internet Exchange Route Server", draft-ietf-idr-ix-bgp-		"Internet Exchange Route Server", draft-ietf-idr-ix-bgp-
	route-server-02 (work in progress), February 2013.		route-server-03 (work in progress), August 2013.
	[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.
	8.2. Informative References		8.2. Informative References
	[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.
	[RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D.,		[RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D.,
	skipping to change at page 13, line 18		skipping to change at page 13, line 23
	[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		[RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route
	Reflection: An Alternative to Full Mesh Internal BGP		Reflection: An Alternative to Full Mesh Internal BGP
	(IBGP)", RFC 4456, April 2006.		(IBGP)", RFC 4456, April 2006.
	[RFC4893] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS		[RFC4893] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS
	Number Space", RFC 4893, May 2007.		Number Space", RFC 4893, May 2007.
	[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
	IANA Considerations Section in RFCs", BCP 26, RFC 5226,
	May 2008.
	[RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection		[RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
	(BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, June		(BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, June
	2010.		2010.
	[RS-ARCH] Govindan, R., Alaettinoglu, C., Varadhan, K., and D.		[RS-ARCH] Govindan, R., Alaettinoglu, C., Varadhan, K., and D.
	Estrin, "A Route Server Architecture for Inter-Domain		Estrin, "A Route Server Architecture for Inter-Domain
	Routing", 1995,		Routing", 1995,
	<http://www.cs.usc.edu/research/95-603.ps.Z>.		<http://www.cs.usc.edu/research/95-603.ps.Z>.
	Authors' Addresses		Authors' Addresses
	Nick Hilliard		Nick Hilliard
	INEX		INEX
	4027 Kingswood Road		4027 Kingswood Road
	Dublin 24		Dublin 24
	IE		IE
	Email: nick@inex.ie		Email: nick@inex.ie
	Elisa Jasinska		Elisa Jasinska
	Microsoft Corporation		Netflix, Inc
	One Microsoft Way		100 Winchester Circle
	Redmond, WA 98052		Los Gatos, CA 95032
	US		USA
	Email: ejas@microsoft.com		Email: elisa@netflix.com
	Robert Raszuk		Robert Raszuk
	NTT I3		NTT I3
	101 S Ellsworth Avenue Suite 350		101 S Ellsworth Avenue Suite 350
	San Mateo, CA 94401		San Mateo, CA 94401
	US		US
	Email: robert@raszuk.net		Email: robert@raszuk.net
	Niels Bakker		Niels Bakker
	AMS-IX B.V.		Akamai Technologies B.V.
	Westeinde 12		Kingsfordweg 151
	Amsterdam, NH 1017 ZN		Amsterdam 1043 GR
	NL		NL
	Email: niels.bakker@ams-ix.net		Email: nbakker@akamai.com
End of changes. 17 change blocks.
	70 lines changed or deleted		65 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/