Summary

  • RFC 7313 turns a route refresh into a demarcated reconciliation window: BoRR marks the peer's routes for one AFI/SAFI stale, replayed entries replace them, and EoRR removes only the entries that remain stale.
  • The procedure is available only after the peer advertises the Enhanced Route Refresh Capability. It preserves the BGP session, but it does not make stale state harmless or authenticate the routes being replayed.

A replay without an ending cannot prove what is missing

RFC 2918 lets a BGP speaker request that a peer re-advertise its Adj-RIB-Out for an address family. That avoids the blunt practice of resetting a session merely to make policy changes take effect. Yet a normal refresh request supplies no explicit transaction boundary. The receiver sees updates arrive, but it cannot use the protocol itself to distinguish the complete replay from ordinary incremental change or to know when an omitted route has become evidence of withdrawal.

That ambiguity matters most when the suspected error is absence rather than presence. A route that should have been withdrawn can remain in a local RIB even while every newly advertised path looks sound. Without a declared end, an operator has to compare state offline, infer completion from silence, or disrupt the adjacency to rebuild it. Each choice gives operational convenience more authority than the protocol can justify.

RFC 7313 supplies the missing boundary. A speaker that supports the procedure advertises Enhanced Route Refresh Capability code 70. When both sides have the negotiated context, the sender places a Beginning-of-RIB-Refresh, or BoRR, before the replay and an End-of-RIB-Refresh, or EoRR, after it has re-advertised the entire Adj-RIB-Out that existed at the start. The markers do not certify the truth of a route. They establish when reconciliation starts and when omission becomes actionable.

BoRR makes old state provisional; EoRR closes the authority

On receiving BoRR, the receiver marks all routes from that peer for the named AFI/SAFI stale. The routes are not immediately purged. As the peer re-advertises entries, the new copies replace their stale counterparts. When EoRR arrives, anything still marked stale is removed at once. The receiver therefore changes only the state that the bounded replay can account for, while the session and other address families remain intact.

This is a significant but narrow power. The receiver may treat non-reappearance as a withdrawal only inside the negotiated family and the declared window. Capability advertisement is the authorization boundary: it tells a peer that the speaker understands the subtypes and procedures. It is not permission to rewrite routing policy, accept an undesirable path, or infer intent outside the replay.

RFC 7313 also permits a locally configurable upper bound on stale-route retention. If EoRR never arrives, an implementation may remove the remaining stale routes when that limit expires. The timer prevents provisional state from becoming indefinite authority. But the standard does not supply a universally safe duration. The operator owns the trade-off between continuity and certainty.

Non-disruptive does not mean cost-free

The immediate beneficiary is the control plane around the inconsistency. A BGP adjacency need not be reset, valid routes can remain installed during the refresh, and missing withdrawals can be exposed online. Networks and users whose paths are unrelated to the stale entries avoid unnecessary reconvergence.

The cost does not disappear. The sender must replay its entire starting Adj-RIB-Out for the family. The receiver carries provisional stale state, processes the replay and must distinguish refreshed routes from those that never return. A long timer preserves reachability that may already be wrong; a short timer can remove useful routes before a delayed EoRR. If the sender changes an entry during the operation, only the modified route needs to be advertised, so implementation and telemetry must still separate replay from live churn.

There is also an ordering boundary with BGP Graceful Restart. A supporting speaker must not send BoRR for an AFI/SAFI before its End-of-RIB marker, and a receiver that has the neighbor's Graceful Restart capability must ignore a premature BoRR. That rule prevents one recovery mechanism from authorizing cleanup before the other has completed its own stale-state phase.

Errors preserve the same scope discipline

The capability does not license arbitrary subtype handling. A subtype 1 or 2 message with an invalid length triggers ROUTE-REFRESH Message Error code 7, subcode 1, and the complete bad message is carried in the notification data. A subtype other than 0, 1 or 2 must be ignored and should be logged. An EoRR without an associated BoRR may also be ignored and may be logged.

These rules reinforce the governance model. Unknown or malformed control markers cannot silently acquire cleanup authority. A useful implementation records capability negotiation, AFI/SAFI, BoRR time, EoRR time, stale counts, replay counts, timer expiry and ignored or malformed markers. A green session alone does not prove that reconciliation was complete.

Evidence and limits

RFC 7313 supports the capability, marker, stale-route, timeout, Graceful Restart ordering and error-handling claims. RFC 2918 supplies the base refresh mechanism, RFC 4271 the BGP state model, RFC 4724 the recovery boundary, RFC 5492 the capability framework, and IANA confirms code 70. The framing of these mechanisms as delegated operational authority is analysis. The sources do not prove deployment by a named operator, prescribe one safe timeout, authenticate route truth or guarantee that a refresh repairs every inconsistency.

Sources