draft-ietf-idr-bgp-optimal-route-reflection-27.txt		draft-ietf-idr-bgp-optimal-route-reflection-28.txt
	IDR Working Group R. Raszuk, Ed.		IDR Working Group R. Raszuk, Ed.
	Internet-Draft NTT Network Innovations		Internet-Draft NTT Network Innovations
	Updates: 4456 (if approved) B. Decraene, Ed.		Intended status: Standards Track B. Decraene, Ed.
	Intended status: Standards Track Orange		Expires: December 19, 2021 Orange
	Expires: December 19, 2021 C. Cassar		C. Cassar
	E. Aman		E. Aman
	K. Wang		K. Wang
	Juniper Networks		Juniper Networks
	June 17, 2021		June 17, 2021
	BGP Optimal Route Reflection (BGP ORR)		BGP Optimal Route Reflection (BGP ORR)
	draft-ietf-idr-bgp-optimal-route-reflection-27		draft-ietf-idr-bgp-optimal-route-reflection-28
	Abstract		Abstract
	This document defines an extension to BGP route reflectors. On route		This document defines an extension to BGP route reflectors. On route
	reflectors, BGP route selection is modified in order to choose the		reflectors, BGP route selection is modified in order to choose the
	best route from the standpoint of their clients, rather than from the		best route from the standpoint of their clients, rather than from the
	standpoint of the route reflectors. Depending on the scaling and		standpoint of the route reflectors. Depending on the scaling and
	precision requirements, route selection can be specific for one		precision requirements, route selection can be specific for one
	client, common for a set of clients or common for all clients of a		client, common for a set of clients or common for all clients of a
	route reflector. This solution is particularly applicable in		route reflector. This solution is particularly applicable in
	skipping to change at page 2, line 30 ¶		skipping to change at page 2, line 30 ¶
	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 . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Modifications to BGP Route Selection . . . . . . . . . . . . 4		3. Modifications to BGP Route Selection . . . . . . . . . . . . 4
	3.1. Route Selection from a different IGP location . . . . . . 5		3.1. Route Selection from a different IGP location . . . . . . 5
	3.1.1. Restriction when BGP next hop is a BGP prefix . . . . 6		3.1.1. Restriction when BGP next hop is a BGP route . . . . 6
	3.2. Multiple Route Selections . . . . . . . . . . . . . . . . 6		3.2. Multiple Route Selections . . . . . . . . . . . . . . . . 6
	4. Deployment Considerations . . . . . . . . . . . . . . . . . . 6		4. Deployment Considerations . . . . . . . . . . . . . . . . . . 6
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 8		5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
	7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8		7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
	8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 9		8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 9
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
	9.1. Normative References . . . . . . . . . . . . . . . . . . 9		9.1. Normative References . . . . . . . . . . . . . . . . . . 9
	9.2. Informative References . . . . . . . . . . . . . . . . . 10		9.2. Informative References . . . . . . . . . . . . . . . . . 10
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
	skipping to change at page 3, line 40 ¶		skipping to change at page 3, line 40 ¶
	VPNs [RFC4364], however it has been gradually extended to other BGP		VPNs [RFC4364], however it has been gradually extended to other BGP
	services, including the IPv4 and IPv6 Internet. In such		services, including the IPv4 and IPv6 Internet. In such
	environments, hot potato routing policy remains desirable.		environments, hot potato routing policy remains desirable.
	Route reflectors outside the forwarding path can be placed on the POP		Route reflectors outside the forwarding path can be placed on the POP
	to core boundaries, but they are often placed in arbitrary locations		to core boundaries, but they are often placed in arbitrary locations
	in the core of large networks.		in the core of large networks.
	Such deployments suffer from a critical drawback in the context of		Such deployments suffer from a critical drawback in the context of
	BGP Route Selection: A route reflector with knowledge of multiple		BGP Route Selection: A route reflector with knowledge of multiple
	paths for a given prefix will typically pick its best path and only		paths for a given route will typically pick its best path and only
	advertise that best path to its clients. If the best path for a		advertise that best path to its clients. If the best path for a
	prefix is selected on the basis of an IGP tie-break, the path		route is selected on the basis of an IGP tie-break, the path
	advertised will be the exit point closest to the route reflector.		advertised will be the exit point closest to the route reflector.
	However, the clients are in a different place in the network topology		However, the clients are in a different place in the network topology
	than the route reflector. In networks where the route reflectors are		than the route reflector. In networks where the route reflectors are
	not in the forwarding path, this difference will be even more acute.		not in the forwarding path, this difference will be even more acute.
	In addition, there are deployment scenarios where service providers		In addition, there are deployment scenarios where service providers
	want to have more control in choosing the exit points for clients		want to have more control in choosing the exit points for clients
	based on other factors, such as traffic type, traffic load, etc.		based on other factors, such as traffic type, traffic load, etc.
	This further complicates the issue and makes it less likely for the		This further complicates the issue and makes it less likely for the
	route reflector to select the best path from the client's		route reflector to select the best path from the client's
	skipping to change at page 6, line 5 ¶		skipping to change at page 6, line 5 ¶
	In order to be able to compute the shortest path tree rooted at the		In order to be able to compute the shortest path tree rooted at the
	selected IGP locations, knowledge of the IGP topology for the area/		selected IGP locations, knowledge of the IGP topology for the area/
	level that includes each of those locations is needed. This		level that includes each of those locations is needed. This
	knowledge can be gained with the use of the link state IGP such as		knowledge can be gained with the use of the link state IGP such as
	IS-IS [ISO10589] or OSPF [RFC2328] [RFC5340] or via BGP-LS [RFC7752].		IS-IS [ISO10589] or OSPF [RFC2328] [RFC5340] or via BGP-LS [RFC7752].
	When specifying logical location of a route reflector for a group of		When specifying logical location of a route reflector for a group of
	clients one or more backup IGP locations SHOULD be allowed to be		clients one or more backup IGP locations SHOULD be allowed to be
	specified for redundancy. Further deployment considerations are		specified for redundancy. Further deployment considerations are
	discussed in Section 4.		discussed in Section 4.
	3.1.1. Restriction when BGP next hop is a BGP prefix		3.1.1. Restriction when BGP next hop is a BGP route
	In situations where the BGP next hop is a BGP route itself, the IGP		In situations where the BGP next hop is a BGP route itself, the IGP
	metric of a route used for its resolution SHOULD be the final IGP		metric of a route used for its resolution SHOULD be the final IGP
	cost to reach such next hop. Implementations which cannot inform BGP		cost to reach such next hop. Implementations which cannot inform BGP
	of the final IGP metric to a recursive next hop MUST treat such paths		of the final IGP metric to a recursive next hop MUST treat such paths
	as least preferred during next hop metric comparison. However, such		as least preferred during next hop metric comparison. However, such
	paths MUST still be considered valid for BGP Phase 2 Route Selection.		paths MUST still be considered valid for BGP Phase 2 Route Selection.
	3.2. Multiple Route Selections		3.2. Multiple Route Selections
End of changes. 6 change blocks.
	8 lines changed or deleted		8 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/