--- 1/draft-ietf-idr-bgp-optimal-route-reflection-18.txt 2019-07-08 10:15:58.460031040 -0700 +++ 2/draft-ietf-idr-bgp-optimal-route-reflection-19.txt 2019-07-08 10:15:58.496031946 -0700 @@ -1,25 +1,25 @@ IDR Working Group R. Raszuk, Ed. Internet-Draft Bloomberg LP Intended status: Standards Track C. Cassar -Expires: October 5, 2019 Tesla +Expires: January 9, 2020 Tesla E. Aman Telia Company B. Decraene Orange K. Wang Juniper Networks - April 3, 2019 + July 8, 2019 BGP Optimal Route Reflection (BGP-ORR) - draft-ietf-idr-bgp-optimal-route-reflection-18 + draft-ietf-idr-bgp-optimal-route-reflection-19 Abstract This document proposes a solution for BGP route reflectors to allow them to choose the best path for their clients that the clients themselves would have chosen under the same conditions, without requiring further state or any new features to be placed on the clients. This facilitates, for example, best exit point policy (hot potato routing). This solution is primarily applicable in deployments using centralized route reflectors. @@ -39,21 +39,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on October 5, 2019. + This Internet-Draft will expire on January 9, 2020. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -63,51 +63,55 @@ the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Definitions of Terms Used in This Memo . . . . . . . . . . . 2 2. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 4 3.2. Existing/Alternative Solutions . . . . . . . . . . . . . 5 - 4. Proposed Solutions . . . . . . . . . . . . . . . . . . . . . 6 + 4. Two Proposed Solutions . . . . . . . . . . . . . . . . . . . 6 4.1. Client's Perspective IGP Based Best Path Selection . . . 7 + 4.1.1. Restriction when BGP next hop is BGP prefix . . . . . 8 4.2. Client's Perspective Policy Based Best Path Selection . . 8 - 4.3. Solution Interactions . . . . . . . . . . . . . . . . . . 8 - 5. CPU and Memory Scalability . . . . . . . . . . . . . . . . . 9 + 4.3. Solution Interactions . . . . . . . . . . . . . . . . . . 9 + 4.3.1. IGP and policy based optimal route refresh . . . . . 9 + 4.3.2. Add-paths plus IGP and policy optimal route refresh . 9 + 4.3.3. Likely Deployments and need for backup . . . . . . . 9 + 5. CPU and Memory Scalability . . . . . . . . . . . . . . . . . 10 6. Advantages and Deployment Considerations . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 - 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 - 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 - 10.2. Informative References . . . . . . . . . . . . . . . . . 12 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 + 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 10.1. Normative References . . . . . . . . . . . . . . . . . . 12 + 10.2. Informative References . . . . . . . . . . . . . . . . . 13 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 1. Definitions of Terms Used in This Memo NLRI - Network Layer Reachability Information. RIB - Routing Information Base. AS - Autonomous System number. VRF - Virtual Routing and Forwarding instance. PE - Provider Edge router RR - Route Reflector POP - Point Of Presence - L3VPN - Layer 3 Virtual Private Networks RFC4364 + L3VPN - Layer 3 Virtual Private Networks [RFC4364] 6PE - IPv6 Provider Edge Router IGP - Interior Gateway Protocol SPT - Shortest Path Tree best path - the route chosen by the decision process detailed in [RFC 4271] section 9.1.2 and its subsections @@ -263,142 +268,159 @@ o defer selection to end clients, but lose potential route scale capacity The latter can be a viable option, but it is clearly a decision that needs to be made on an application and address family basis, with strong consideration for the number of available paths per prefix (which may even vary per prefix range, depending on peering policy, e.g. consider bilateral peerings versus onward transit arrangements) -4. Proposed Solutions +4. Two Proposed Solutions - The goal of this document is to propose a solution to allow a route - reflector to choose the best path for its clients that the clients - themselves would have chosen had they considered the same set of - candidate paths. For purposes of route selection, the perspective of - a client can differ from that of a route reflector or another client - in two distinct ways: it can, and usually will, have a different - position in the IGP topology, and it can have a different routing - policy. These factors correspond to the issues described earlier. - Accordingly, we propose two distinct modifications to the best path - algorithm, to address these two distinct factors. A route reflector - can implement either or both of the modifications, as needed, in + This document is describes two solution to allow a route reflector to + choose the best path for its clients that the clients themselves + would have chosen had they considered the same set of candidate + paths. + + For purposes of route selection, the perspective of a client can + differ from that of a route reflector or another client in two + distinct ways: + + it can, and usually will, have a different position in the IGP + topology, and + + it can have a different routing policy. + + These factors correspond to the issues described earlier. + Accordingly, this document specifies two distinct modifications to + the best path algorithm, to address these two distinct factors. A + route reflector can implement either or both of the modifications in order to allow it to choose the best path for its clients that the clients themselves would have chosen given the same set of candidate paths. Both modifications rely upon all route reflectors learning all paths that are eligible for consideration. In order to satisfy this requirement, path diversity enhancing mechanisms such as add-path/ diverse paths may need to be deployed between route reflectors. A significant advantage of these approaches is that the route reflector clients do not need to run new software or hardware. 4.1. Client's Perspective IGP Based Best Path Selection The core of this solution is the ability for an operator to specify - on a per route reflector basis or per peer/update group basis or per - peer basis the virtual IGP location placement of the route reflector. - This enables having a given group of clients receive routes with - shortest distance to the next hops from the position of the - configured virtual IGP location. This provides for freedom of route - reflector location, and allows transient or permanent migration of - this network control plane function to an arbitrary location. + on a per route reflector basis, or per peer/update group basis, or + per peer basis the virtual IGP location placement of the route + reflector. This core ability enables the route reflector to send to + a given group of clients routes with shortest distance to the next + hops from the position of the configured virtual IGP location. This + core ability provides for freedom of route reflector location, and + allows transient or permanent migration of this network control plane + function to an arbitrary location. - The choice of specific granularity left as an implementation + The choice of specific granularity (route reflector basis, peer/ + update group basis, or peer peer basis) is left as an implementation decision. An implementation is considered compliant with the document if it supports at least one listed grouping of virtual IGP location. In this approach, optimal refers to the decision made during best path selection at the IGP metric to BGP next hop comparison step. This approach does not apply to path selection preference based on other policy steps and provisions. The computation of the virtual IGP location with any of the above described granularity is outside of the scope of this document. The operator may configure it manually, implementation may automate it based on heuristics, or it can be computed centrally and configured by an external system. - In situations where the BGP next hop is a BGP prefix itself the IGP - metric of a route used for its resolution SHOULD be the final IGP - cost to reach such next hop. Implementations which can not inform - BGP of the final IGP metric to a recursive next hop SHOULD treat such - paths as least preferred during next hop metric comparison. However - such paths SHOULD still be considered valid for best path selection. - This solution does not require any BGP or IGP protocol changes, as all required changes are contained within the route reflector implementation. This solution applies to NLRIs of all address families, that can be route reflected. +4.1.1. Restriction when BGP next hop is BGP prefix + + In situations where the BGP next hop is a BGP prefix itself the IGP + metric of a route used for its resolution SHOULD be the final IGP + cost to reach such next hop. Implementations which can not inform + BGP of the final IGP metric to a recursive next hop SHOULD treat such + paths as least preferred during next hop metric comparison. However + such paths SHOULD still be considered valid for best path selection. + 4.2. Client's Perspective Policy Based Best Path Selection Optimal route reflection based on virtual IGP location could reflect the best path to the client from IGP cost perspective. However, there are also cases where the client might want the best path based on factors beyond IGP cost. Examples include, but not limited to: o Selecting the best path for the clients from a traffic engineering perspective. o Dedicating certain exit points for certain ingress points. - The solution proposed here allows the user to apply a general policy - on the route reflector to select a subset of exit points as the - candidate exit points for its clients. For a given client, the - policy SHOULD also allow the operator to select different candidate - exit points for different address families. Regular path selection, - including client's perspective IGP based best path selection stated - above, will be applied to the candidate paths to select the final - paths to advertise to the clients. + The user MAY specify and apply a general policy on the route + reflector to select a subset of exit points as the candidate exit + points for its clients. For a given client, the policy SHOULD also + allow the operator to select different candidate exit points for + different address families. Regular path selection, including + client's perspective IGP based best path selection stated above, will + be applied to the candidate paths to select the final paths to + advertise to the clients. Since the policy is applied on the route reflector on behalf of its clients, the route reflector will be able to reflect only the optimal paths to its clients. An additional advantage of this approach is that configuration need only be done on a small number of route reflectors, rather than on a significantly larger number of clients. 4.3. Solution Interactions +4.3.1. IGP and policy based optimal route refresh + Depending on the actual deployment scenarios, service providers may configure IGP based optimal route reflection or policy based optimal route reflection. It is also possible to configure both approaches together. In cases where both are configured together, policy based - optimal route reflection will be applied first to select the - candidate paths, then IGP based optimal route reflection will be + optimal route reflection MUST be applied first to select the + candidate paths, then IGP based optimal route reflection can be applied on top of the candidate paths to select the final path to advertise to the client. The expected use case for optimal route reflection is to avoid - reflecting all paths to the client because the client either does not - support add-paths or does not have the capacity to process all of the - paths. Typically the route reflector would just reflect a single + reflecting all paths to the client because the client either: does + not support add-paths or does not have the capacity to process all of + the paths. Typically the route reflector would just reflect a single optimal route to the client. However, the solutions MUST NOT prevent reflecting more than one optimal path to the client as path diversity may be desirable for load balancing or fast restoration. In cases where add-path and optimal route reflection are configured together, the route reflector MUST reflect n optimal paths to a client, where n is the add-path count. +4.3.2. Add-paths plus IGP and policy optimal route refresh + The most complicated scenario is where add-path is configured together with both IGP based and policy based optimal route reflection. In this scenario, the policy based optimal route - reflection will be applied first to select the candidate paths. - Subsequently, IGP based optimal route reflection will be applied on - top of the candidate paths to select the best n paths to advertise to - the client. + reflection MUST be applied first to select the candidate paths (from + add-path). Subsequently, IGP based optimal route reflection will be + applied on top of the candidate paths to select the best n paths to + advertise to the client. + +4.3.3. Likely Deployments and need for backup With IGP based optimal route reflection, even though the virtual IGP location could be specified on a per route reflector basis or per peer/update group basis or per peer basis, in reality, it's most likely to be specified per peer/update group basis. All clients with the same or similar IGP location can be grouped into the same peer/ update group. A virtual IGP location is then specified for the peer/ update group. The virtual location is usually specified as the location of one of the clients from the peer group or an ABR to the area where clients are located. Also, one or more backup virtual @@ -482,22 +504,36 @@ compromising an operator's closest exit operational principle. This enables edge-to-edge LSP/IP encapsulation for traffic to IPv4 and IPv6 prefixes. Regarding the client's IGP best-path selection, it should be self evident that this solution does not interfere with policies enforced above IGP tie breaking in the BGP best path algorithm. 7. Security Considerations - No new security issues are introduced to the BGP protocol by this - specification. + This document does not introduce any new BGP functionality therefor + it does not change the underlying security issues inherent in the + existing IBGP path propagation when BGP Route Reflection [RFC4456] is + used. + + It however enables the deployment of base BGP Route Reflection as + described in [RFC4456] to be possible using virtual compute + environments without any negative consequence on the BGP routing path + optimality. + + This document does not introduce requirements for any new protection + measures, but it also does not relax best operational practices for + keeping the IGP network stable or to pace rate of policy based IGP + cost to next hops such that it does not have any substantial effect + on BGP path changes and their propagation to route reflection + clients. 8. IANA Considerations This document does not request any IANA allocations. 9. Acknowledgments Authors would like to thank Keyur Patel, Eric Rosen, Clarence Filsfils, Uli Bornhauser, Russ White, Jakob Heitz, Mike Shand, Jon Mitchell, John Scudder, Jeff Haas, Martin Djernaes, Daniele