BGP Optimal Route-Reflection

BGP Optimal Route-Reflection

Problem Statement

Let me start by describing the problem statement using the network below. The links show OSPF cost.

In figure 1, R1, R2 and R3 are route-reflector clients of route-reflector RR. In this case, the BGP path selection algorithm will select the route from R3 as the best-path due to lower IGP cost (201) compared to R2 (211) - considering all other BGP attributes are same.

RR# show ip bgp vpnv4 all 22.22.22.22

BGP routing table entry for 1:1:22.22.22.22/32, version 2

Paths: (2 available, best #2, no table)

Advertised to update-groups:

65001, (Received from a RR-client)

2.2.2.2 (metric 211) from 2.2.2.2 (2.2.2.2)

Origin IGP, metric 0, localpref 100, valid, internal

Extended Community: RT:1:1

mpls labels in/out nolabel/23

65001, (Received from a RR-client)

3.3.3.3 (metric 201) from 3.3.3.3 (3.3.3.3)

Origin IGP, metric 0, localpref 100, valid, internal, best

Extended Community: RT:1:1

mpls labels in/out nolabel/23

The RR advertises this prefix to R1 with next-hop as R3.

R1# show ip bgp vpnv4 all 22.22.22.22

BGP routing table entry for 1:1:22.22.22.22/32, version 20

Paths: (1 available, best #1, table A)

Not advertised to any peer

65001

3.3.3.3 (metric 101) from 4.4.4.4 (4.4.4.4)

Origin IGP, metric 0, localpref 100, valid, internal, best

Extended Community: RT:1:1

Originator: 3.3.3.3, Cluster list: 4.4.4.4

mpls labels in/out nolabel/23

Now, the cost from R1 to reach R3 is 100 while the cost to reach R2 is 10. So it is clear from the outputs that R1 had to install a less efficient path since RR considered IGP cost to determine the best path and chose its nearest exit point. The example network shows MPLS VPN network but same applies to IPv4 hop-by-hop forwarding as well.

Problem Solution

There are multiple approaches to address non-optimal route selection in BGP. One such approach is BGP Add-Paths described in this draft and proposes extensions to BGP by allowing multiple paths for the same prefix. In this case, the RR will advertise both paths learned from R2 and R3, and advertise to R1, which can select its own best path. This approach is great as it provides improved path diversity but can suffer a criticism that the same prefix could be potentially learnt from multiple BGP routers and advertising multiple paths for every prefix could mean introducing a large number of BGP states to all routers.

BGP ORR defined in the draft proposes 2 alternatives. In both solutions, the route-reflector selects and distributes the best path to each client based on what would be optimal from a client's perspective. This only applies to the stage in BGP path selection algorithm when IGP metric to BGP next-hop is considered [1]. In figure 1 for example, if R2 was to advertise a route with higher Local Preference compared to R3, RR would prefer R2 irrespective of the IGP metric.

Client's Perspective Best Path Selection Algorithm

The draft suggests that the route-reflector compute IGP metric to the BGP next-hop from the client's position to which the resulting path will be distributed only when [1] applies. The draft considers 2 scenarios - flat and Hierarchical IGP network.

For Flat IGP network, the route-reflector runs SPF from the client's point of view (i.e. putting the client at the root of the SPF tree - same thing is done in IP FRR) to determine the IGP metric to the BGP next-hops and also to determine what paths to advertise to the client. In our case, the RR will determine the cost from R1 to R2 and R3, and only advertise paths for which the distance from R1 is less i.e. paths advertised by R2.

For Hierarchical IGP network, it is little tricky as the RR and the client could not be present in the same IGP area. The draft proposes that the RR compute distance from ABRs (in OSPF) or L1/L2 node (in IS-IS) to BGP nexthops and add it to the distance advertised by ABRs to the client.

The draft also touches upon the ability to virtualize route-reflector and pretend its location within any of the other nodes in the IGP area depending upon the address-family (AF) or AF plus update/peer group. This allows the logical RR to advertise best paths per AF, for example, to clients. The placement of logical RRs is at network operator's discretion based on network topology.

The draft also proposes to use a new capability advertised in BGP OPEN message called BGP Route Reflector Client Group Identifier. This attribute is used by clients to notify the RR to which group they want to be part of on the RR based on the Group ID value (4 bytes).

Angular Distance Approximation

This solution involves modelling the network topology as a set of elements (regions and routers) in a circle. The route-reflector clients and exit points are associated to the elements and the angular distance (in degrees) is computed between them. This measure of distance can be used in BGP path selection algorithm instead of IGP metric.

The draft does not discuss a specific rule (or set of rules) of associating the routers to elements and assigning angular positions to them.

In our example, R1 is a route-reflector client and has 2 exit points (R2 and R3) for a prefix advertised by CE2. I can assign their angular positions as below for a prefix P1 and the RR performs the calculations from R1's perspective.

Exit Points: R2 R3

Angular Positions: 45 135

Angular position of Client R1: 270 degrees

Now, Angular Position of R1 calculated against Exit Points -

Exit Points: R2 R3

Angular Positions: 225 135

RR uses the angular position as the variable instead of IGP metric to run the BGP best path algorithm and chooses R3 as the "closest" exit point. In my view, this approach has serious drawbacks as it relies on network operator to assign angular positions.