draft-ietf-idr-bgp-optimal-route-reflection-26.txt		draft-ietf-idr-bgp-optimal-route-reflection-27.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.		Updates: 4456 (if approved) B. Decraene, Ed.
	Intended status: Standards Track Orange		Intended status: Standards Track Orange
	Expires: December 18, 2021 C. Cassar		Expires: December 19, 2021 C. Cassar
	E. Aman		E. Aman
	K. Wang		K. Wang
	Juniper Networks		Juniper Networks
	June 16, 2021		June 17, 2021
	BGP Optimal Route Reflection (BGP ORR)		BGP Optimal Route Reflection (BGP ORR)
	draft-ietf-idr-bgp-optimal-route-reflection-26		draft-ietf-idr-bgp-optimal-route-reflection-27
	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
	deployments using centralized route reflectors, where choosing the		deployments using centralized route reflectors, where choosing the
	best route based on the route reflector's Interior Gateway Protocol		best route based on the route reflector's IGP location is suboptimal.
	(IGP) location is suboptimal. This facilitates, for example, best		This facilitates, for example, best exit point policy (hot potato
	exit point policy (hot potato routing).		routing).
	The solution relies upon all route reflectors learning all paths		The solution relies upon all route reflectors learning all paths
	which are eligible for consideration. BGP Route Selection is		which are eligible for consideration. BGP Route Selection is
	performed in the route reflectors based on the IGP cost from		performed in the route reflectors based on the IGP cost from
	configured locations in the link state IGP.		configured locations in the link state IGP.
	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.
	skipping to change at page 2, line 7 ¶		skipping to change at page 2, line 7 ¶
	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 https://datatracker.ietf.org/drafts/current/.		Drafts is at https://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 18, 2021.		This Internet-Draft will expire on December 19, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2021 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
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://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 2, line 44 ¶		skipping to change at page 2, line 44 ¶
	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
	1. Introduction		1. Introduction
	There are three types of BGP (Border Gateway Protocol) deployments		There are three types of BGP deployments within Autonomous Systems
	within Autonomous Systems today: full mesh, confederations and route		today: full mesh, confederations and route reflection. BGP route
	reflection. BGP route reflection [RFC4456] is the most popular way		reflection [RFC4456] is the most popular way to distribute BGP routes
	to distribute BGP routes between BGP speakers belonging to the same		between BGP speakers belonging to the same Autonomous System.
	Autonomous System. However, in some situations, this method suffers		However, in some situations, this method suffers from non-optimal
	from non-optimal path selection.		path selection.
	[RFC4456] asserts that, because the IGP cost to a given point in the		[RFC4456] asserts that, because the IGP cost to a given point in the
	network will vary across routers, "the route reflection approach may		network will vary across routers, "the route reflection approach may
	not yield the same route selection result as that of the full		not yield the same route selection result as that of the full
	Internal BGP (IBGP) mesh approach." One practical implication of		Internal BGP (IBGP) mesh approach." One practical implication of
	this fact is that the deployment of route reflection may thwart the		this fact is that the deployment of route reflection may thwart the
	ability to achieve hot potato routing. Hot potato routing attempts		ability to achieve hot potato routing. Hot potato routing attempts
	to direct traffic to the closest Autonomous System (AS) exit point in		to direct traffic to the closest Autonomous System (AS) exit point in
	cases where no higher priority policy dictates otherwise. As a		cases where no higher priority policy dictates otherwise. As a
	consequence of the route reflection method, the choice of exit point		consequence of the route reflection method, the choice of exit point
	skipping to change at page 5, line 48 ¶		skipping to change at page 5, line 48 ¶
	interior cost. The interior cost of a route is determined by		interior cost. The interior cost of a route is determined by
	calculating the metric from the selected IGP location to the		calculating the metric from the selected IGP location to the
	NEXT_HOP for the route using the shortest IGP path tree rooted at		NEXT_HOP for the route using the shortest IGP path tree rooted at
	the selected IGP location.		the selected IGP location.
	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 specifing 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 prefix
	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
	skipping to change at page 7, line 11 ¶		skipping to change at page 7, line 11 ¶
	into account either the IGP cost between the client and the NEXT_HOP		into account either the IGP cost between the client and the NEXT_HOP
	(rather than the IGP cost from the route reflector to the NEXT_HOP)		(rather than the IGP cost from the route reflector to the NEXT_HOP)
	or other user configured policies.		or other user configured policies.
	The achievement of optimal routing between clients of different		The achievement of optimal routing between clients of different
	clusters relies upon all route reflectors learning all paths that are		clusters relies upon all route reflectors learning all paths that are
	eligible for consideration. In order to satisfy this requirement,		eligible for consideration. In order to satisfy this requirement,
	BGP add-path [RFC7911] needs to be deployed between route reflectors.		BGP add-path [RFC7911] needs to be deployed between route reflectors.
	This solution can be deployed in traditional hop-by-hop forwarding		This solution can be deployed in traditional hop-by-hop forwarding
	networks as well as in end-to-end tunneled environments. In networks		networks as well as in end-to-end tunneled environments. To avoid
	where there are multiple route reflectors and hop-by-hop forwarding		routing loops in networks with multiple route reflectors and hop-by-
	without encapsulation, such optimizations MUST be consistently		hop forwarding without encapsulation, it is essential that the
	enabled on all route reflectors. Otherwise, clients may receive an		network topology be carefully considered in designing a route
	inconsistent view of the network, in turn leading to intra-domain		reflection topology (see also Section 11 of [RFC4456]).
	forwarding loops.
	As discussed in section 11 of [RFC4456], the IGP locations of BGP		As discussed in section 11 of [RFC4456], the IGP locations of BGP
	route reflectors is important and has routing implications. This		route reflectors is important and has routing implications. This
	equally applies to the choice of the IGP locations configured on		equally applies to the choice of the IGP locations configured on
	optimal route reflectors. If a backup location is provided, it is		optimal route reflectors. If a backup location is provided, it is
	used when the primary IGP location disappears from the IGP (i.e.		used when the primary IGP location disappears from the IGP (i.e.
	fails). Just like the failure of a RR [RFC4456], it may result in		fails). Just like the failure of a RR [RFC4456], it may result in
	changing the paths selected and advertised to the clients and in		changing the paths selected and advertised to the clients and in
	general the post-failure paths are expected to be less optimal. This		general the post-failure paths are expected to be less optimal. This
	is dependent on the IGP topologies and the IGP distance between the		is dependent on the IGP topologies and the IGP distance between the
	skipping to change at page 8, line 45 ¶		skipping to change at page 8, line 44 ¶
	6. IANA Considerations		6. IANA Considerations
	This document does not request any IANA allocations.		This document does not request any IANA allocations.
	7. Acknowledgments		7. Acknowledgments
	Authors would like to thank Keyur Patel, Eric Rosen, Clarence		Authors would like to thank Keyur Patel, Eric Rosen, Clarence
	Filsfils, Uli Bornhauser, Russ White, Jakob Heitz, Mike Shand, Jon		Filsfils, Uli Bornhauser, Russ White, Jakob Heitz, Mike Shand, Jon
	Mitchell, John Scudder, Jeff Haas, Martin Djernaes, Daniele		Mitchell, John Scudder, Jeff Haas, Martin Djernaes, Daniele
	Ceccarelli, Kieran Milne, Job Snijders, Randy Bush, Alvaro Retana,		Ceccarelli, Kieran Milne, Job Snijders, Randy Bush, Alvaro Retana,
	Francesca Palombini, Benjamin Kaduk, Zaheduzzaman Sarker and Lars		Francesca Palombini, Benjamin Kaduk, Zaheduzzaman Sarker, Lars
	Eggert for their valuable input.		Eggert, Murray Kucherawy, Tom Petch and Nick Hilliard for their
			valuable input.
	8. Contributors		8. Contributors
	Following persons substantially contributed to the current format of		Following persons substantially contributed to the current format of
	the document:		the document:
	Stephane Litkowski		Stephane Litkowski
	Cisco System		Cisco System
	slitkows.ietf@gmail.com		slitkows.ietf@gmail.com
End of changes. 9 change blocks.
	22 lines changed or deleted		22 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/