--- 1/draft-ietf-idr-bgp-optimal-route-reflection-27.txt	2021-06-17 15:13:10.190567733 -0700
+++ 2/draft-ietf-idr-bgp-optimal-route-reflection-28.txt	2021-06-17 15:13:10.218568445 -0700
@@ -1,25 +1,25 @@
 
 IDR Working Group                                         R. Raszuk, Ed.
 Internet-Draft                                   NTT Network Innovations
-Updates: 4456 (if approved)                             B. Decraene, Ed.
-Intended status: Standards Track                                  Orange
-Expires: December 19, 2021                                     C. Cassar
+Intended status: Standards Track                        B. Decraene, Ed.
+Expires: December 19, 2021                                        Orange
+                                                               C. Cassar
 
                                                                  E. Aman
 
                                                                  K. Wang
                                                         Juniper Networks
                                                            June 17, 2021
 
                  BGP Optimal Route Reflection (BGP ORR)
-             draft-ietf-idr-bgp-optimal-route-reflection-27
+             draft-ietf-idr-bgp-optimal-route-reflection-28
 
 Abstract
 
    This document defines an extension to BGP route reflectors.  On route
    reflectors, BGP route selection is modified in order to choose the
    best route from the standpoint of their clients, rather than from the
    standpoint of the route reflectors.  Depending on the scaling and
    precision requirements, route selection can be specific for one
    client, common for a set of clients or common for all clients of a
    route reflector.  This solution is particularly applicable in
@@ -64,21 +64,21 @@
    include Simplified BSD License text as described in Section 4.e of
    the Trust Legal Provisions and are provided without warranty as
    described in the Simplified BSD License.
 
 Table of Contents
 
    1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
    2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
    3.  Modifications to BGP Route Selection  . . . . . . . . . . . .   4
      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
    4.  Deployment Considerations . . . . . . . . . . . . . . . . . .   6
    5.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
    6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
    7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   8
    8.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .   9
    9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
      9.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
      9.2.  Informative References  . . . . . . . . . . . . . . . . .  10
    Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10
@@ -120,23 +120,23 @@
    VPNs [RFC4364], however it has been gradually extended to other BGP
    services, including the IPv4 and IPv6 Internet.  In such
    environments, hot potato routing policy remains desirable.
 
    Route reflectors outside the forwarding path can be placed on the POP
    to core boundaries, but they are often placed in arbitrary locations
    in the core of large networks.
 
    Such deployments suffer from a critical drawback in the context of
    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
-   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.
    However, the clients are in a different place in the network topology
    than the route reflector.  In networks where the route reflectors are
    not in the forwarding path, this difference will be even more acute.
 
    In addition, there are deployment scenarios where service providers
    want to have more control in choosing the exit points for clients
    based on other factors, such as traffic type, traffic load, etc.
    This further complicates the issue and makes it less likely for the
    route reflector to select the best path from the client's
@@ -229,21 +229,21 @@
    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/
    level that includes each of those locations is needed.  This
    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].
    When specifying logical location of a route reflector for a group of
    clients one or more backup IGP locations SHOULD be allowed to be
    specified for redundancy.  Further deployment considerations are
    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
    metric of a route used for its resolution SHOULD be the final IGP
    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
    as least preferred during next hop metric comparison.  However, such
    paths MUST still be considered valid for BGP Phase 2 Route Selection.
 
 3.2.  Multiple Route Selections