draft-ietf-idr-bgp-optimal-route-reflection-06.txt		draft-ietf-idr-bgp-optimal-route-reflection-07.txt
	IDR Working Group R. Raszuk		IDR Working Group R. Raszuk
	Internet-Draft NTT I3		Internet-Draft Individual
	Intended status: Standards Track C. Cassar		Intended status: Standards Track C. Cassar
	Expires: July 6, 2014 Cisco Systems		Expires: February 1, 2015 Cisco Systems
	E. Aman		E. Aman
	TeliaSonera		TeliaSonera
	B. Decraene		B. Decraene
	S. Litkowski		S. Litkowski
	Orange		Orange
	January 2, 2014		July 31, 2014
	BGP Optimal Route Reflection (BGP-ORR)		BGP Optimal Route Reflection (BGP-ORR)
	draft-ietf-idr-bgp-optimal-route-reflection-06		draft-ietf-idr-bgp-optimal-route-reflection-07
	Abstract		Abstract
	[RFC4456] asserts that, because the Interior Gateway Protocol (IGP)		[RFC4456] asserts that, because the Interior Gateway Protocol (IGP)
	cost to a given point in the network will vary across routers, "the		cost to a given point in the network will vary across routers, "the
	route reflection approach may not yield the same route selection		route reflection approach may not yield the same route selection
	result as that of the full IBGP mesh approach." One practical		result as that of the full IBGP mesh approach." One practical
	implication of this assertion is that the deployment of route		implication of this assertion is that the deployment of route
	reflection may thwart the ability to achieve hot potato routing. Hot		reflection may thwart the ability to achieve hot potato routing. Hot
	potato routing attempts to direct traffic to the closest AS egress		potato routing attempts to direct traffic to the closest AS egress
	skipping to change at page 2, line 20		skipping to change at page 2, line 20
	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 July 6, 2014.		This Internet-Draft will expire on February 1, 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 3, line 36		skipping to change at page 3, line 36
	between BGP speakers belonging to the same administrative domain.		between BGP speakers belonging to the same administrative domain.
	Traditionally route reflectors have been deployed in the forwarding		Traditionally route reflectors have been deployed in the forwarding
	path and carefully placed on the POP to core boundaries. That model		path and carefully placed on the POP to core boundaries. That model
	of BGP route reflector placement has started to evolve. The		of BGP route reflector placement has started to evolve. The
	placement of route reflectors outside the forwarding path was		placement of route reflectors outside the forwarding path was
	triggered by applications which required traffic to be tunneled from		triggered by applications which required traffic to be tunneled from
	AS ingress PE to egress PE: for example L3VPN.		AS ingress PE to egress PE: for example L3VPN.
	This evolving model of intra-domain network design has enabled		This evolving model of intra-domain network design has enabled
	deployments of centralized route reflectors. Initially this model		deployments of centralized route reflectors. Initially this model
	was only employed for new address families e.g. L3VPNs, L2VPNs etc		was only employed for new address families e.g. L3VPNs, L2VPNs etc
	With edge to edge MPLS or IP encapsulation also being used to carry		With edge to edge MPLS or IP encapsulation also being used to carry
	internet traffic, this model has been gradually extended to other BGP		internet traffic, this model has been gradually extended to other BGP
	address families including IPv4 and IPv6 Internet routing. This is		address families including IPv4 and IPv6 Internet routing. This is
	also applicable to new services achieved with BGP as control plane		also applicable to new services achieved with BGP as control plane
	for example 6PE.		for example 6PE.
	Such centralized route reflectors can be placed on the POP to core		Such centralized route reflectors can be placed on the POP to core
	boundaries, but they are often placed in arbitrary locations in the		boundaries, but they are often placed in arbitrary locations in the
	core of large networks.		core of large networks.
	skipping to change at page 4, line 46		skipping to change at page 4, line 46
	amount of BGP state to all the edge routers. In many networks, the		amount of BGP state to all the edge routers. In many networks, the
	number of EBGP peers over which full Internet routing information is		number of EBGP peers over which full Internet routing information is
	received would correlate directly to the number of paths present in		received would correlate directly to the number of paths present in
	each ASBR. This could easily result in tens of paths for each		each ASBR. This could easily result in tens of paths for each
	prefix.		prefix.
	Notwithstanding this drawback, there are a number of reasons for		Notwithstanding this drawback, there are a number of reasons for
	sending more than just the single best path to the clients. Improved		sending more than just the single best path to the clients. Improved
	path diversity at the edge is a requirement for fast connectivity		path diversity at the edge is a requirement for fast connectivity
	restoration, and a requirement for effective BGP level load		restoration, and a requirement for effective BGP level load
	balancing. Protocol extensions like add-paths		balancing.
	[I-D.ietf-idr-add-paths] or [RFC6774] diverse-path allow for such
	improved path diversity and can be used to address the same problems
	addressed by the mechanisms proposed in this draft.
	In practical terms, add/diverse path deployments are expected to		In practical terms, add/diverse path deployments are expected to
	result in the distribution of 2, 3 or n (where n is a small number)		result in the distribution of 2, 3 or n (where n is a small number)
	'good' paths rather than all domain external paths. While the route		'good' paths rather than all domain external paths. While the route
	reflector chooses one set of n paths and distributes those same n		reflector chooses one set of n paths and distributes those same n
	paths to all its route reflector clients, those n paths may not be		paths to all its route reflector clients, those n paths may not be
	the right n paths for all clients. In the context of the problem		the right n paths for all clients. In the context of the problem
	described above, those n paths will not necessarily include the		described above, those n paths will not necessarily include the
	closest egress point out of the network for each route reflector		closest egress point out of the network for each route reflector
	client. The mechanisms proposed in this document are likely to be		client. The mechanisms proposed in this document are likely to be
	skipping to change at page 14, line 11		skipping to change at page 14, line 11
	CLIENT A		CLIENT A
	POP3		POP3
	N - represents the different exit points for a given prefix. POP2 is		N - represents the different exit points for a given prefix. POP2 is
	a geographically large PoP with two paths; N2 and N3.		a geographically large PoP with two paths; N2 and N3.
	In a deployment where the centralized RRs tie break on the basis of		In a deployment where the centralized RRs tie break on the basis of
	their IGP-based view of the network, N1 above would be advertised to		their IGP-based view of the network, N1 above would be advertised to
	all clients on the basis that it is closest to the RR. Path N4 would		all clients on the basis that it is closest to the RR. Path N4 would
	be a more appropriate choice for client B. Similarly, N5 would be		be a more appropriate choice for client B. Similarly, N5 would be
	more appropriate for client A since path N5 is closer to client A		more appropriate for client A since path N5 is closer to client A
	then path N1.		then path N1.
	4.2. Proposed solution		4.2. Proposed solution
	The proposed solution revolves around the operator establishing the		The proposed solution revolves around the operator establishing the
	angular position of the route-reflector clients and inter-domain exit		angular position of the route-reflector clients and inter-domain exit
	points in the network. The route reflector then picks the path to		points in the network. The route reflector then picks the path to
	advertise to a client based on the client's angular position versus		advertise to a client based on the client's angular position versus
	the angular position of the inter-domain exit points originating the		the angular position of the inter-domain exit points originating the
	skipping to change at page 20, line 36		skipping to change at page 20, line 36
	IANA is requested to allocate a type code for the Standard BGP		IANA is requested to allocate a type code for the Standard BGP
	Community to be used for inter cluster propagation of angular		Community to be used for inter cluster propagation of angular
	position of the clients.		position of the clients.
	IANA is requested to allocate a new type code from BGP OPEN Optional		IANA is requested to allocate a new type code from BGP OPEN Optional
	Parameter Types registry to be used for Group_ID propagation.		Parameter Types registry to be used for Group_ID propagation.
	9. Acknowledgments		9. Acknowledgments
	Authors would like to thank Eric Rosen, Clarence Filsfils, Uli		Authors would like to thank Eric Rosen, Clarence Filsfils, Uli
	Bornhauser Russ White, Jakob Heitz and Mike Shand for their valuable		Bornhauser Russ White, Jakob Heitz, Mike Shand and Jon Mitchell for
	input.		their valuable input.
	10. References		10. References
	10.1. Normative References		10.1. Normative References
	[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.
	skipping to change at page 22, line 4		skipping to change at page 21, line 47
	Specific BGP Extended Community", RFC 5668, October 2009.		Specific BGP Extended Community", RFC 5668, October 2009.
	[RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", RFC		[RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", RFC
	5714, January 2010.		5714, January 2010.
	[RFC6774] Raszuk, R., Fernando, R., Patel, K., McPherson, D., and K.		[RFC6774] Raszuk, R., Fernando, R., Patel, K., McPherson, D., and K.
	Kumaki, "Distribution of Diverse BGP Paths", RFC 6774,		Kumaki, "Distribution of Diverse BGP Paths", RFC 6774,
	November 2012.		November 2012.
	Authors' Addresses		Authors' Addresses
	Robert Raszuk		Robert Raszuk
	NTT I3		Individual
	101 S Ellsworth Avenue Suite 350
	San Mateo, CA 94401
	US
	Email: robert@raszuk.net		Email: robert@raszuk.net
	Christian Cassar		Christian Cassar
	Cisco Systems		Cisco Systems
	10 New Square Park		10 New Square Park
	Bedfont Lakes, FELTHAM TW14 8HA		Bedfont Lakes, FELTHAM TW14 8HA
	UK		UK
	Email: ccassar@cisco.com		Email: ccassar@cisco.com
	Erik Aman		Erik Aman
	TeliaSonera		TeliaSonera
End of changes. 12 change blocks.
	18 lines changed or deleted		12 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/