draft-ietf-idr-bgp-optimal-route-reflection-04.txt		draft-ietf-idr-bgp-optimal-route-reflection-05.txt
	IDR Working Group R. Raszuk		IDR Working Group R. Raszuk
	Internet-Draft NTT MCL		Internet-Draft NTT I3
	Intended status: Standards Track C. Cassar		Intended status: Standards Track C. Cassar
	Expires: June 7, 2013 Cisco Systems		Expires: December 06, 2013 Cisco Systems
	E. Aman		E. Aman
	TeliaSonera		TeliaSonera
	B. Decraene		B. Decraene
	France Telecom
	S. Litkowski		S. Litkowski
	Orange		Orange
	December 4, 2012		June 04, 2013
	BGP Optimal Route Reflection (BGP-ORR)		BGP Optimal Route Reflection (BGP-ORR)
	draft-ietf-idr-bgp-optimal-route-reflection-04		draft-ietf-idr-bgp-optimal-route-reflection-05
	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 5		skipping to change at page 2, line 5
	services, tunneled (LSP/IP tunneling) networks with centralized route		services, tunneled (LSP/IP tunneling) networks with centralized route
	reflectors became commonplace. This is one type of common deployment		reflectors became commonplace. This is one type of common deployment
	where it would be impractical to satisfy the constraints described in		where it would be impractical to satisfy the constraints described in
	Section 11 of [RFC4456]. Yet, in such an environment, hot potato		Section 11 of [RFC4456]. Yet, in such an environment, hot potato
	routing policy remains desirable.		routing policy remains desirable.
	This document proposes two new solutions which can be deployed to		This document proposes two new solutions which can be deployed to
	facilitate the application of closest exit point policy centralized		facilitate the application of closest exit point policy centralized
	route reflection deployments.		route reflection deployments.
	Status of this Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 June 7, 2013.		This Internet-Draft will expire on December 06, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 IETF Trust and the persons identified as the		Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Proposed solutions . . . . . . . . . . . . . . . . . . . . . . 5		2. Proposed solutions . . . . . . . . . . . . . . . . . . . . . 5
	3. Best path selection for BGP hot potato routing from		3. Best path selection for BGP hot potato routing from
	customized IGP network position . . . . . . . . . . . . . . . 7		customized IGP network position . . . . . . . . . . . . . . . 6
	3.1. Client's perspective best path selection algorithm . . . . 8		3.1. Client's perspective best path selection algorithm . . . 7
	3.1.1. Flat IGP network . . . . . . . . . . . . . . . . . . . 8		3.1.1. Flat IGP network . . . . . . . . . . . . . . . . . . 7
	3.1.2. Hierarchical IGP network . . . . . . . . . . . . . . . 9		3.1.2. Hierarchical IGP network . . . . . . . . . . . . . . 8
	3.2. Aside: Configuration-based flexible route reflector		3.2. Aside: Configuration-based flexible route reflector
	placement . . . . . . . . . . . . . . . . . . . . . . . . 10		placement . . . . . . . . . . . . . . . . . . . . . . . . 9
	3.3. Route reflector client grouping . . . . . . . . . . . . . 10		3.3. Route reflector client grouping . . . . . . . . . . . . . 9
	3.3.1. Route Reflector Client Group ID . . . . . . . . . . . 11		3.3.1. Route Reflector Client Group ID . . . . . . . . . . . 10
	3.4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 12		3.4. Discussion . . . . . . . . . . . . . . . . . . . . . . . 11
	3.5. Advantages . . . . . . . . . . . . . . . . . . . . . . . . 13		3.5. Advantages . . . . . . . . . . . . . . . . . . . . . . . 12
	4. Angular distance approximation for BGP warm potato routing . 13		4. Angular distance approximation for BGP warm potato routing . 12
	4.1. Problem statement . . . . . . . . . . . . . . . . . . . . 14		4.1. Problem statement . . . . . . . . . . . . . . . . . . . . 13
	4.2. Proposed solution . . . . . . . . . . . . . . . . . . . . 15		4.2. Proposed solution . . . . . . . . . . . . . . . . . . . . 14
	4.3. Centralized vs distributed route reflectors . . . . . . . 16		4.3. Centralized vs distributed route reflectors . . . . . . . 15
	5. Client's perspective policy based best path selection . . . . 17		5. Client's perspective policy based best path selection . . . . 16
	5.1. Proposal . . . . . . . . . . . . . . . . . . . . . . . . . 18		5.1. Proposal . . . . . . . . . . . . . . . . . . . . . . . . 17
	5.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 18		5.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 17
	5.3. Avoiding routing loops . . . . . . . . . . . . . . . . . . 19		5.3. Avoiding routing loops . . . . . . . . . . . . . . . . . 19
	6. Deployment considerations . . . . . . . . . . . . . . . . . . 20		6. Deployment considerations . . . . . . . . . . . . . . . . . . 19
	7. Security considerations . . . . . . . . . . . . . . . . . . . 21		7. Security considerations . . . . . . . . . . . . . . . . . . . 20
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
	10.1. Normative References . . . . . . . . . . . . . . . . . . . 21		10.1. Normative References . . . . . . . . . . . . . . . . . . 20
	10.2. Informative References . . . . . . . . . . . . . . . . . . 22		10.2. Informative References . . . . . . . . . . . . . . . . . 21
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
	1. Introduction		1. Introduction
	There are three types of BGP deployments within Autonomous Systems		There are three types of BGP deployments within Autonomous Systems
	today: full mesh, confederations and route reflection.		today: full mesh, confederations and route reflection.
	BGP route reflection is the most popular way to distribute BGP routes		BGP route reflection is the most popular way to distribute BGP routes
	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 7, line 5		skipping to change at page 6, line 18
	Besides these solutions to manage hot potato routing, there are		Besides these solutions to manage hot potato routing, there are
	deployment scenarios where service providers want to have more		deployment scenarios where service providers want to have more
	control of traffic exiting the AS by assigning per client preference		control of traffic exiting the AS by assigning per client preference
	to gateways.		to gateways.
	This document proposes to introduce a solution to perform a policy		This document proposes to introduce a solution to perform a policy
	based route-reflection to address those scenarios. This solution has		based route-reflection to address those scenarios. This solution has
	the same requirements (regarding path diversity) and advantages than		the same requirements (regarding path diversity) and advantages than
	the two IGP metric based solutions.		the two IGP metric based solutions.
	3. Best path selection for BGP hot potato routing from customized IGP		3. Best path selection for BGP hot potato routing from customized IGP
	network position		network position
	This section describes a method for calculating the order of		This section describes a method for calculating the order of
	preference of BGP paths from the point of view of each separate route		preference of BGP paths from the point of view of each separate route
	reflector client. More specifically, the route reflector will		reflector client. More specifically, the route reflector will
	compute the IGP metric to the BGP nexthop from the position of the		compute the IGP metric to the BGP nexthop from the position of the
	client to which the resulting path will be distributed, if the IGP		client to which the resulting path will be distributed, if the IGP
	metric is the tie breaker applied to a set of possible paths. In the		metric is the tie breaker applied to a set of possible paths. In the
	subsequent model authors will propose virtual reflector placement at		subsequent model authors will propose virtual reflector placement at
	operator's selected IGP location.		operator's selected IGP location.
	skipping to change at page 9, line 18		skipping to change at page 8, line 31
	Hierarchy introduces two challenges:		Hierarchy introduces two challenges:
	The first challenge is that the RR IGP view may differ from a		The first challenge is that the RR IGP view may differ from a
	client IGP view by virtue of one or the other having a summarized		client IGP view by virtue of one or the other having a summarized
	view versus the other. Summarization, by its nature, loses		view versus the other. Summarization, by its nature, loses
	information. Consider the example where a client within a PoP		information. Consider the example where a client within a PoP
	sees two prefixes with two metrics for two egress points within		sees two prefixes with two metrics for two egress points within
	the PoP, but where the RR only sees a single summary covering		the PoP, but where the RR only sees a single summary covering
	reachability to both nexthops as injected by the ABR. For		reachability to both nexthops as injected by the ABR. For
	clarification purposes in the case of ISIS by ABR we refer to		clarification purposes in the case of ISIS by ABR we refer to L1/
	L1/L2 node. However it needs to be observed that inter area		L2 node. However it needs to be observed that inter area networks
	networks running LDP are required to disable summarisation of all		running LDP are required to disable summarisation of all FEC
	FEC advertised in LDP (typically all loopbacks) unless [RFC5283]		advertised in LDP (typically all loopbacks) unless [RFC5283] is
	is deployed. Such deployments are not likely to suffer		deployed. Such deployments are not likely to suffer summarization
	summarization difficulties.		difficulties.
	The second challenge is that in cases where the client is in a		The second challenge is that in cases where the client is in a
	different level of hierarchy from the RR, the RR can not build a		different level of hierarchy from the RR, the RR can not build a
	Shortest Path First (SPF) tree with the client node as root,		Shortest Path First (SPF) tree with the client node as root,
	simply because the topology derived by the IGP will not include		simply because the topology derived by the IGP will not include
	the client node. It will instead only include reachability to the		the client node. It will instead only include reachability to the
	client from one or more ABRs. In order to overcome this problem,		client from one or more ABRs. In order to overcome this problem,
	the RR could compute an SPF tree from the ABRs in the area. The		the RR could compute an SPF tree from the ABRs in the area. The
	RR would then determine the shortest distance from a client which		RR would then determine the shortest distance from a client which
	lives behind the ABRs, to a nexthop, by adding the advertised		lives behind the ABRs, to a nexthop, by adding the advertised
	skipping to change at page 13, line 44		skipping to change at page 12, line 50
	retaining all available paths (potentially 10s) per each prefix at		retaining all available paths (potentially 10s) per each prefix at
	the edge.		the edge.
	The proposal allows for a fast and safe transition to BGP control		The proposal allows for a fast and safe transition to BGP control
	plane route reflection without compromising an operator's closest		plane route reflection without compromising an operator's closest
	exit operational principle. Hot potato routing is important to most		exit operational principle. Hot potato routing is important to most
	ISPs. The inability to perform hot potato routing effectively stops		ISPs. The inability to perform hot potato routing effectively stops
	migrations to centralized route reflection and edge-to-edge LSP/IP		migrations to centralized route reflection and edge-to-edge LSP/IP
	encapsulation for traffic to IPv4 and IPv6 prefixes.		encapsulation for traffic to IPv4 and IPv6 prefixes.
	4. Angular distance approximation for BGP warm potato routing		4. Angular distance approximation for BGP warm potato routing
	This section describes an alternative solution to the use of IGP		This section describes an alternative solution to the use of IGP
	topology information to virtually position the RR at the client		topology information to virtually position the RR at the client
	location in the network. This solution involves modeling the network		location in the network. This solution involves modeling the network
	topology as a set of elements (regions, PoPs or routers) arranged in		topology as a set of elements (regions, PoPs or routers) arranged in
	a circle. Route reflector clients and inter-domain exit points would		a circle. Route reflector clients and inter-domain exit points would
	then be statically assigned to those elements such that one can		then be statically assigned to those elements such that one can
	compute the angular distance between route-reflector clients and the		compute the angular distance between route-reflector clients and the
	various exit points in order to infer the distance between any two		various exit points in order to infer the distance between any two
	elements. This measure of distance can be used as an effective		elements. This measure of distance can be used as an effective
	alternative to the IGP distance as a tie breaker in the path		alternative to the IGP distance as a tie breaker in the path
	skipping to change at page 14, line 37		skipping to change at page 13, line 42
	CLIENT B		CLIENT B
	POP4 POP1 N1		POP4 POP1 N1
	CORE		CORE
	RR(s) POP2 N2		RR(s) POP2 N2
	N5 POP3 POP2 N3		N5 POP3 POP2 N3
	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.
	skipping to change at page 22, line 14		skipping to change at page 21, line 14
	[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.
	[RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement		[RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement
	with BGP-4", RFC 5492, February 2009.		with BGP-4", RFC 5492, February 2009.
	10.2. Informative References		10.2. Informative References
	[I-D.ietf-idr-add-paths]		[I-D.ietf-idr-add-paths]
	Walton, D., Chen, E., Retana, A., 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-
	draft-ietf-idr-add-paths-07 (work in progress), June 2012.		add-paths-08 (work in progress), December 2012.
	[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.
	[RFC1998] Chen, E. and T. Bates, "An Application of the BGP		[RFC1998] Chen, E. and T. Bates, "An Application of the BGP
	Community Attribute in Multi-home Routing", RFC 1998,		Community Attribute in Multi-home Routing", RFC 1998,
	August 1996.		August 1996.
	[RFC4384] Meyer, D., "BGP Communities for Data Collection", BCP 114,		[RFC4384] Meyer, D., "BGP Communities for Data Collection", BCP 114,
	RFC 4384, February 2006.		RFC 4384, February 2006.
	skipping to change at page 22, line 42		skipping to change at page 21, line 42
	[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.
	[RFC5283] Decraene, B., Le Roux, JL., and I. Minei, "LDP Extension		[RFC5283] Decraene, B., Le Roux, JL., and I. Minei, "LDP Extension
	for Inter-Area Label Switched Paths (LSPs)", RFC 5283,		for Inter-Area Label Switched Paths (LSPs)", RFC 5283,
	July 2008.		July 2008.
	[RFC5668] Rekhter, Y., Sangli, S., and D. Tappan, "4-Octet AS		[RFC5668] Rekhter, Y., Sangli, S., and D. Tappan, "4-Octet AS
	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",		[RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", RFC
	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 MCL		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
	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
	Marbackagatan 11		Marbackagatan 11
	Farsta, SE-123 86		Farsta SE-123 86
	Sweden		Sweden
	Email: erik.aman@teliasonera.com		Email: erik.aman@teliasonera.com
	Bruno Decraene		Bruno Decraene
	France Telecom		Orange
	38-40 rue du General Leclerc		38-40 rue du General Leclerc
	Issy les Moulineaux cedex 9, 92794		Issy les Moulineaux cedex 9 92794
	France		France
	Email: bruno.decraene@orange.com		Email: bruno.decraene@orange.com
	Stephane Litkowski		Stephane Litkowski
	Orange		Orange
	9 rue du chene germain		9 rue du chene germain
	Cesson Sevigne, 35512		Cesson Sevigne 35512
	France		France
	Email: stephane.litkowski@orange.com		Email: stephane.litkowski@orange.com
End of changes. 24 change blocks.
	57 lines changed or deleted		54 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/