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/