draft-ietf-idr-ix-bgp-route-server-05.txt		draft-ietf-idr-ix-bgp-route-server-06.txt
	IDR Working Group E. Jasinska		IDR Working Group E. Jasinska
	Internet-Draft Netflix, Inc		Internet-Draft Netflix, Inc
	Intended status: Standards Track N. Hilliard		Intended status: Standards Track N. Hilliard
	Expires: December 11, 2014 INEX		Expires: June 13, 2015 INEX
	R. Raszuk		R. Raszuk
	NTT MCL Inc.		Mirantis Inc.
	N. Bakker		N. Bakker
	Akamai Technologies B.V.		Akamai Technologies B.V.
	June 9, 2014		December 10, 2014
	Internet Exchange Route Server		Internet Exchange Route Server
	draft-ietf-idr-ix-bgp-route-server-05		draft-ietf-idr-ix-bgp-route-server-06
	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 December 11, 2014.		This Internet-Draft will expire on June 13, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 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
	skipping to change at page 7, line 50		skipping to change at page 7, line 50
	to a route server client, then route server clients would no longer		to a route server client, then route server clients would no longer
	depend on receiving a single best path to a particular prefix;		depend on receiving a single best path to a particular prefix;
	consequently, the path hiding problem described in Section 2.3.1		consequently, the path hiding problem described in Section 2.3.1
	would disappear.		would disappear.
	We present two methods which describe how such increased path		We present two methods which describe how such increased path
	diversity could be implemented.		diversity could be implemented.
	2.3.2.2.1. Diverse BGP Path Approach		2.3.2.2.1. Diverse BGP Path Approach
	The Diverse BGP Path proposal as defined in		The Diverse BGP Path proposal as defined in [RFC6774] is a simple way
	[I-D.ietf-grow-diverse-bgp-path-dist] is a simple way to distribute		to distribute multiple prefix paths from a route server to a route
	multiple prefix paths from a route server to a route server client by		server client by using a separate BGP session from the route server
	using a separate BGP session from the route server to a client for		to a client for each different path.
	each different path.
	The number of paths which may be distributed to a client is		The number of paths which may be distributed to a client is
	constrained by the number of BGP sessions which the server and the		constrained by the number of BGP sessions which the server and the
	client are willing to establish with each other. The distributed		client are willing to establish with each other. The distributed
	paths may be established from the global BGP Loc-RIB on the route		paths may be established from the global BGP Loc-RIB on the route
	server in addition to any per-client Loc-RIB. As there may be more		server in addition to any per-client Loc-RIB. As there may be more
	potential paths to a given prefix than configured BGP sessions, this		potential paths to a given prefix than configured BGP sessions, this
	method is not guaranteed to eliminate the path hiding problem in all		method is not guaranteed to eliminate the path hiding problem in all
	situations. Furthermore, this method may significantly increase the		situations. Furthermore, this method may significantly increase the
	number of BGP sessions handled by the route server, which may		number of BGP sessions handled by the route server, which may
	skipping to change at page 9, line 47		skipping to change at page 9, line 46
	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.
	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-08 (work in
	progress), July 2012.
	[I-D.ietf-idr-add-paths]		[I-D.ietf-idr-add-paths]
	Walton, D., Retana, A., Chen, E., and J. Scudder,		Walton, D., Retana, A., Chen, E., and J. Scudder,
	"Advertisement of Multiple Paths in BGP",		"Advertisement of Multiple Paths in BGP",
	draft-ietf-idr-add-paths-09 (work in progress),		draft-ietf-idr-add-paths-10 (work in progress),
	October 2013.		October 2014.
	[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.
	[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.
			[RFC6774] Raszuk, R., Fernando, R., Patel, K., McPherson, D., and K.
			Kumaki, "Distribution of Diverse BGP Paths", RFC 6774,
			November 2012.
	Authors' Addresses		Authors' Addresses
	Elisa Jasinska		Elisa Jasinska
	Netflix, Inc		Netflix, Inc
	100 Winchester Circle		100 Winchester Circle
	Los Gatos, CA 95032		Los Gatos, CA 95032
	USA		USA
	Email: elisa@netflix.com		Email: elisa@netflix.com
	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
	Robert Raszuk		Robert Raszuk
	NTT MCL Inc.		Mirantis Inc.
	101 S Ellsworth Avenue Suite 350		615 National Ave. #100
	San Mateo, CA 94401		Mt View, CA 94043
	US		USA
			Phone:
			Fax:
	Email: robert@raszuk.net		Email: robert@raszuk.net
			URI:
	Niels Bakker		Niels Bakker
	Akamai Technologies B.V.		Akamai Technologies B.V.
	Kingsfordweg 151		Kingsfordweg 151
	Amsterdam 1043 GR		Amsterdam 1043 GR
	NL		NL
	Email: nbakker@akamai.com		Email: nbakker@akamai.com
End of changes. 12 change blocks.
	23 lines changed or deleted		23 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/