Summary

  • RFC 9107 lets a route reflector calculate interior cost from a configured IGP location representing one client, a client group or a whole reflector, rather than from the reflector’s own physical position.
  • “Optimal” is narrow: it means the route that the configured perspective would select from the same eligible candidates under the relevant policy. Candidate gaps, stale topology, recursive next hops and earlier BGP preferences can produce another result.
  • Safe ORR separates root-assignment authority from route and forwarding proof. Operators must validate topology epoch, candidate completeness, group membership, computation capacity, backup-root behavior, client Adj-RIB-In and FIB outcome.

Imagine a virtual route reflector in a central data centre serving routers in three distant cities. Two border routers advertise the same prefix. One exit is near the eastern client; the other is near the western client. Local preference, AS-path length and other higher-priority attributes tie. The decision reaches the IGP-cost comparison.

The reflector asks a perfectly valid question: which next hop is closest to me? It chooses the western exit and reflects that path to both clients. The eastern client never sees the other candidate. Packets cross the backbone toward an exit that was optimal only from a control-plane machine that does not forward them.

Nothing is broken in isolation. The IGP metrics are correct. The BGP Decision Process is correct. The reflector is behaving as designed. The failure lies in the choice of perspective. A computation performed faithfully from the wrong place can produce a consistently wrong answer for the party expected to use it.

Route reflection accepts this possibility as part of its scaling bargain. RFC 4456 explains that a reflector summarizes information and normally reflects only its best path. It also warns that IGP metrics may differ by router and that certain reflection topologies may not produce the same result as a full IBGP mesh. The traditional mitigation is to align reflection topology with network topology closely enough that reflector and client perspectives do not diverge materially.

That alignment became harder as route reflectors left the forwarding path. A centralized or virtual reflector can be placed wherever compute and operations are convenient. Its physical IGP location then becomes an accidental input to traffic engineering. Moving the control service from one city to another can change selected exits even when no edge policy or external route changed.

RFC 9107 removes the accidental dependency. An operator can configure a logical IGP location for the calculation. The location is a node in the link-state topology, identified by an IP address such as a loopback. The reflector builds a shortest-path tree rooted there and uses the resulting cost to each candidate BGP next hop during the interior-cost comparison.

The logical root is a viewpoint, not a waypoint. Packets do not detour through it, and the reflector does not enter the forwarding path merely because it uses that root. The BGP route still names a next hop; the client’s recursive resolution and FIB determine where packets travel. Treating the root address as a traffic steering node confuses the model with the outcome.

Granularity is an explicit operator choice. One root can represent the entire route reflector. Different roots can represent groups of clients with similar topology. At the finest level, every client can have its own root. RFC 9107 regards an implementation as compliant if it supports at least one of these grouping categories; compliance does not promise per-client precision.

Each level encodes an approximation. A single root costs least but may reproduce traditional reflection for remote clients. A regional group can be accurate for the centre of a metro while being wrong at its edge. A per-client root comes closest to that client’s IGP position, but multiplies shortest-path and BGP computations. There is no free setting called “most optimal.”

The word “optimal” needs a strict boundary. In the basic ORR change, the reflector substitutes the selected root’s IGP cost at step e of RFC 4271’s Phase 2 tie breaking. Policies applied earlier in the Decision Process continue to dominate. A route with higher local preference can win even if its next hop is much farther from the client root.

Nor does the IGP metric measure everything an operator may care about. It does not by itself reveal latency, congestion, packet loss, transit price, carbon intensity, maintenance risk or application performance. ORR can support hot-potato routing—handing traffic to an external network at the closest eligible exit—but “closest under this topology metric after prior policy” is the accurate claim.

RFC 9107 also allows more than a different IGP root. If distinct client sets require different BGP policies, the reflector may run a larger portion of the Decision Process separately, potentially the whole process. That expands ORR from topological perspective to delegated policy perspective. A group mapping can decide not only which exit is nearer, but which business preference is evaluated for whom.

This is why the root-to-client map is a production policy object. Moving a client from one group to another can alter thousands of Adj-RIB-Out entries without any BGP UPDATE from the Internet and without any IGP link change. The mapping deserves version control, review, staged rollout and an exact route-set diff—just like an import or export policy.

The calculation also requires a complete candidate set. A reflector cannot select the route a client would have chosen if it never learned that route. RFC 9107 states that route reflectors need all paths eligible for consideration and that ADD-PATH is required between reflectors to achieve this across clusters.

That requirement is stronger than an ADD-PATH capability line. Direction must match for the relevant AFI/SAFI. The sending reflector’s path-set policy must include the useful candidates. Import policy must retain them. Adj-RIB-In must show them at the ORR computation point. A reflector can run an impeccable client-rooted SPF across an incomplete route set and still advertise the wrong exit.

ORR and ADD-PATH allocate state differently. Sending multiple paths to every edge lets each client make its own decision but increases edge RIB and update load. ORR can keep the fuller candidate set among reflectors, perform client-aware selection centrally and send a smaller result to each edge. It saves distributed state by concentrating information, compute and trust.

The topology input must be equally credible. RFC 9107 says the reflector needs knowledge of the link-state area or level containing each selected root and cites IS-IS, OSPF or BGP-LS as possible sources. The presence of a topology database proves only that data exists. It may be stale, missing an area, inconsistent between redundant reflectors or rooted at an address no longer representing the intended client.

BGP-LS illustrates the evidence boundary. It can distribute link-state and traffic-engineering information to a computation point. That distribution does not make the consumer’s view current or complete by magic. The ORR operator needs topology sequence or epoch evidence, expected node and link coverage, source-session health and comparison against the forwarding routers’ own IGP view. RFC 7752 is also obsolete in favor of RFC 9552, so current architecture should confirm which specification and implementation behavior actually supplies the data.

Recursive next hops create a subtler limit. If a BGP next hop is itself reached through a BGP route, the relevant value is the final IGP cost to the resolved next hop. RFC 9107 says an implementation unable to provide that final metric must treat such paths as least preferred in the next-hop metric comparison, while still treating them as valid for Phase 2. A candidate can therefore remain valid and yet lose systematically because the computation cannot see through its recursion.

The platform’s route-resolution model matters. Junos documentation, for example, describes restrictions when prefixes resolve over tables whose primary next-hop route comes from MPLS protocols rather than IS-IS or OSPF, and offers design adjustments for certain services. Cisco documents its own constraints, including IGP-learned rSPF routes and limitations involving BGP-LU or multiple IGP topologies. These are implementation boundaries, not additions to RFC 9107.

Vendor language must also be read carefully. A product can say it “ensures” the best route for a client because it correctly implements its configured ORR model. That does not independently prove the root was assigned to the right client, the topology was current, every candidate arrived or the client installed the advertisement. Product correctness is one link, not the whole assurance chain.

Backup roots expose the lifecycle of perspective. RFC 9107 recommends allowing backup IGP locations. Junos documents a primary and optional backup for a client group. When the primary disappears, the backup supplies a new view. The network may remain reachable, yet the selected exits can change across many prefixes because the observer moved.

The backup should therefore have a reviewed distance from the primary and a predicted route-set delta. “Backup configured” is not evidence that its perspective is acceptable. Operators need to remove the primary root in a bounded test, observe the SPF switch, compare advertisements by client group and confirm the resulting FIB and traffic paths.

Hop-by-hop forwarding adds another constraint. RFC 9107 can be used with hop-by-hop or tunneled designs, but warns that multiple-reflector networks without encapsulation require careful topology construction to avoid loops. An ORR choice can be individually rational from a modeled client position while interacting badly with the actual reflection and forwarding topology. The safety proof must cover the system, not only the metric calculation.

Compute is part of the control contract. One root means one shortest-path perspective. Hundreds of client roots may require hundreds of SPF trees and repeated portions of the BGP Decision Process over a large table. Fine granularity increases precision but can extend convergence time, consume memory and CPU, or delay updates precisely when the topology is changing fastest.

A capacity review should therefore model routes, clients, roots, IGP nodes and failure fan-out together. Measure steady-state CPU and memory, full-table recalculation time, incremental topology-change time, queue depth and the latency between IGP change, ORR decision and client advertisement. A design that is correct only in a quiet laboratory is not correct for the failure it was commissioned to handle.

The first production artefact is a perspective registry. For every client and address family, it records the primary root, backup root, group, policy version, intended hot-potato behavior and owner. It distinguishes a client’s literal location from a deliberately chosen surrogate. It also names any clients for which the approximation is accepted because a per-client computation is too expensive.

The second artefact is a candidate-completeness proof. Capture the relevant routes at every reflector exchange, including ADD-PATH direction and advertised-set policy, then show the ORR node’s Adj-RIB-In. For a sample of prefixes with multiple exits, verify that every route expected under the design reached the computation.

The third artefact follows the calculation. Record the topology epoch and shortest-path costs from each tested root to every candidate next hop. Record earlier BGP attributes to show why the decision reached the IGP comparison. Then capture the client-specific Adj-RIB-Out and explain the winning step. This prevents a correct outcome from being attributed to ORR when local preference or AS-path length actually decided it.

The fourth artefact belongs to the client. Verify the advertised path arrived, passed import policy, became best where intended, resolved to the expected next hop and entered the FIB. A packet trace or measured egress confirms the final boundary. If the client chose a different path because it learned another candidate elsewhere, that is an operational fact rather than an ORR failure to be hidden.

Change testing should include a client moved between groups, a root removed, a backup activated, one candidate withheld between reflectors, stale topology, recursive resolution, a higher-priority policy override and a compute-load event. Each scenario has an expected route-set delta and a maximum convergence envelope. Unexpected sameness can be as suspicious as unexpected change.

Rollback restores perspective, not merely syntax. Removing an ORR stanza may return the reflector to its own physical viewpoint, but the resulting route updates still have to reach clients and reverse their FIB choices. If the topology or external candidates changed during rollout, exact restoration may be impossible. The baseline remains evidence, not a promise of time travel.

Authority should be divided. Topology owners validate roots and failure domains. Routing-policy owners approve client grouping and earlier preferences. Reflector operators control compute budgets and rollout. Client or traffic owners verify egress results. An independent reviewer decides whether the model is accurate enough to expand. Giving one central team the right to define the client, compute for the client and certify the client’s outcome removes the point at which a false perspective can be challenged.

Heng Lu’s principle of minimum initial specification fits RFC 9107 closely. The common mechanism is modest: name a logical point and let the reflector use its topology distance in a defined decision stage. The standard does not require every network to centralize reflection, impose one grouping strategy or declare one universal meaning of optimality. Future decisions stay local.

Running-code primacy sets the acceptance order. The configured root and client group are claims. The topology actually learned, candidates actually retained, client-specific path actually advertised, next hop actually programmed and packets actually observed are the system. A correct configuration that computes from stale or incomplete inputs has not implemented the intended perspective.

Data sovereignty here is not possession of a topology database. It is practical control over the decision that database produces. The reflector formally owns the computation; the client owns forwarding; network teams own pieces of the inputs. Sovereignty becomes operational only when those parties can inspect the mapping, challenge the surrogate view and prove the result independently.

ORR solves a specific failure of centralization by adding another controlled form of centralization. It frees a reflector from its accidental physical position, but asks operators to govern logical positions as consequential policy. The right question is not whether the route is called optimal. It is whose eyes performed the calculation, which alternatives those eyes were allowed to see, and whether the client’s packets agreed.

Sources