BGP Optimal Route Reflection (BGP ORR)
Extracted elements (16)
BGP ORR allows an operator to specify one or more IGP locations for which the route reflector calculates interior cost to the next hop, enabling hot potato routing even when the route reflector is not in the forwarding path. A significant advantage is that route reflector clients do not need to be modified.
Compared with deploying ADD-PATH on all routers, BGP ORR reduces the amount of state that needs to be pushed to the edge of the network in order to perform hot potato routing, while enabling hot potato routing even when route reflection has moved out of the forwarding plane.
Granularity of IGP location configuration presents a precision-vs-performance tradeoff: per-client is most precise but most CPU-intensive (one SPF and Decision Process subset per client); per-set-of-clients reduces precision but lowers compute load; per-routing-instance is equivalent in both precision and performance to standard RFC 4456 route reflection.
If a backup IGP location is configured and the primary IGP location disappears from the IGP (fails), the backup is used. Similar to the failure of a route reflector itself, this may result in less optimal paths being selected and advertised; the smaller the IGP distance between primary and backup, the smaller the impact.
Knowledge of the IGP topology for the area/level that includes each selected IGP location is needed to compute the shortest path tree. This knowledge can be gained via a link-state IGP (IS-IS or OSPF) or via BGP-LS (RFC 7752).
Route reflectors placed outside the forwarding path select the best path based on their own IGP location, not their clients'. When IGP tie-breaking determines the best path, the exit point chosen is closest to the route reflector, not to the clients, making hot potato routing unachievable.
BGP ORR can be deployed in both hop-by-hop forwarding networks and end-to-end tunneled environments. To avoid routing loops in networks with multiple route reflectors using hop-by-hop forwarding without encapsulation, the network topology must be carefully considered when designing a route reflection topology.
An implementation is considered compliant with this document if it supports at least one grouping category for IGP location configuration: per route reflector, per set of clients, or per client.
In situations where the BGP next hop is itself a BGP route, the IGP metric used for resolution SHOULD be the final IGP cost to reach that next hop. Implementations that cannot provide the final IGP metric to a recursive next hop MUST treat such paths as least preferred during next-hop metric comparisons.
In the modified BGP Decision Process step e), the interior cost of a route is determined by calculating the metric from the selected IGP location to the NEXT_HOP for the route using the shortest IGP path tree rooted at the selected IGP location, rather than from the route reflector itself.
Paths where the BGP next hop is a recursive BGP route and the final IGP metric cannot be determined MUST still be considered valid for BGP Phase 2 route selection, even though they are treated as least preferred during next-hop metric comparisons.
To achieve optimal routing between clients of different clusters, all route reflectors must learn all paths eligible for consideration. BGP ADD-PATH (RFC 7911) needs to be deployed between route reflectors to satisfy this requirement.
When specifying the logical IGP location of a route reflector for a group of clients, one or more backup IGP locations SHOULD be allowed to be specified for redundancy.
An IGP location is defined as a node in the IGP topology, identified by an IP address of that node (e.g., a loopback address). It may be configured on a per-route-reflector basis, per set of clients, or on a per-client basis.
BGP ORR may require multiple BGP Decision Processes or subsets thereof in order to consider different IGP locations or BGP policies for different sets of clients. If only IGP cost optimization is needed, only step e) and subsequent steps need to run multiple times; if different BGP policies are needed, a larger portion or the entire Decision Process must run multiple times.
BGP ORR provides a new metric value using additional IGP information for computing routes on route reflectors. While any improperly used metric value could impact network resiliency, this extension does not change the underlying security issues inherent in existing IBGP per RFC 4456, and introduces no requirements for new protection measures.