Summary

  • BGP's MinRouteAdvertisementIntervalTimer limits how frequently one speaker advertises changes for the same destination to one peer; it does not stop the local Decision Process from selecting routes during the wait.
  • If the local choice changes repeatedly before the next advertisement is permitted, RFC 4271 requires the last selected route to be sent at expiry. The peer receives a current result but not the full local timeline.
  • A shorter interval buys freshness with more UPDATE and remote processing work; a longer interval coalesces churn but can delay failure, replacement or repair information. The correct trade must be measured per peer class and implementation.

Imagine one prefix and two neighboring networks. At 10:00:00, the local speaker selects path A and tells its peer. At 10:00:04, A fails and path B becomes best. At 10:00:09, a policy change makes path C best. The local RIB has recorded three choices. The peer may hear only A and then C. Path B was real enough to influence local forwarding, but it never became an external statement.

That missing middle is the purpose of the Minimum Route Advertisement Interval, usually shortened to MRAI. RFC 4271 defines it as the minimum time that must separate UPDATEs sent to a peer when they advertise and/or withdraw routes for a common set of destinations. The timer value is set per peer, while the limiting effect is per destination. One relationship receives one configured cadence, but unrelated prefixes do not logically have to wait behind every other prefix.

The specification avoids requiring a literal timer object for every destination. Such state could itself become excessive. An implementation may use another scheduling technique if it guarantees the minimum separation and also places a constant upper bound on the delay. The contract is externally observable timing, not a mandated internal data structure.

MRAI does not rate-limit the BGP Decision Process. Local policy can evaluate every arriving UPDATE. Best path can change repeatedly. The forwarding table may follow those selections. What waits is the next statement to a particular neighbor about the affected destination. RFC 4271 makes the coalescing rule explicit: when new routes are selected multiple times during the interval, the last route selected is advertised when the interval ends.

This is temporal compression. The neighbor learns the last eligible state, not every intermediate state that produced it. Compression saves link bandwidth and prevents the peer from repeating selection work for states that may vanish almost immediately. It also deprives the peer of information it could have used earlier. The saved message and the delayed fact are the same event viewed from opposite autonomous systems.

That trade arose from real control-plane pressure. RFC 4271 places MRAI in its section on controlling routing traffic overhead, naming both UPDATE bandwidth and Decision Process computation. The SIGCOMM 1997 routing-instability study found far more pathological routing updates in its measured exchange-point data than simple topology change would predict. The result was not a timeless count, but it established that BGP's message stream could contain large amounts of work that did not correspond to durable reachability.

The later SIGCOMM 2000 convergence study showed the other side. In its passive measurements and controlled fault injections, interdomain failure, failover and repair could take minutes. Independent route selection and path exploration created transient loss and delay. MRAI was not the only cause, and the historic measurements are not a 2026 global constant. They demonstrate why a timer that removes messages can also lengthen the time before distributed knowledge settles.

A lower interval is therefore not automatically better. It can expose a replacement sooner, but it can also export intermediate path exploration to every downstream decision process. One router's desire for instant disclosure becomes many routers' processing workload. Synchronized peers can form update peaks, which is why RFC 4271 recommends jitter for MRAI and several other timers.

A higher interval is not automatically safer. It can coalesce noisy local choices, yet withhold a valid replacement or repair from a peer whose customers are losing reachability. The local control plane may already use path C while the neighbor still acts on path A or its withdrawal. Protection becomes harm when the information budget is selected without a freshness budget.

The initial message needs a precise boundary. This article does not claim that every first advertisement waits a full interval. RFC 4271 defines minimum spacing between relevant consecutive UPDATEs. The effect of a change depends on the previous advertisement for that destination, the running scheduler and the implementation. Claims about universal fast withdrawals or universal delayed withdrawals are equally unsafe without platform evidence.

Internal and external relationships also differ. RFC 4271 says fast convergence is needed within an AS. It therefore recommends a shorter interval for iBGP than eBGP or no application of the procedure to routes sent to internal peers. That is not an order to make every iBGP timer zero. It recognizes that an AS cannot use fresh local choices coherently if its own distribution layer unnecessarily conceals them.

RFC 4271's suggested values—30 seconds for eBGP and five seconds for iBGP—often survive in explanations as if they described every network. They do not. RFC 4273 exposes a per-peer managed timer and repeats those suggestions, while real products choose different contexts. Cisco IOS documentation, for example, documents 30 seconds for ordinary eBGP, zero for iBGP and zero for eBGP in a VRF in the cited release family. Another platform or release may differ.

Configuration hierarchy adds another source of fiction. A value can come from an address family, neighbor, peer group, neighbor group or session group. Precedence can make the line an operator inspected different from the value in force. Cisco IOS XR operational output can report the minimum time between advertisement runs for the neighbor. That running value is stronger evidence than the apparent parent configuration.

Even the running value is not the outcome. To evaluate MRAI, an operator needs timestamped local best-path changes, Adj-RIB-Out changes, sent UPDATEs and the peer's received UPDATEs for the same NLRI. FIB events and reachability measurements then reveal whether the withheld intermediate state mattered. Without this timeline, fewer UPDATEs can be mistaken for healthier routing even when recovery became slower.

The distinction from Route Flap Damping is fundamental. Damping remembers instability as a penalty that decays over time and may suppress a route from use or advertisement. MRAI does not judge a route's historical character. It spaces statements to a peer. A route can be selected locally throughout the wait and still remain undisclosed; it has not been damped.

MRAI is also not a liveness timer. HoldTimer and Keepalive determine whether the BGP session remains alive. BFD may detect a forwarding failure quickly. Fast detection can cause the local route selection to change sooner, but it does not guarantee the resulting UPDATE bypasses outbound cadence. RFC 7938 tells data-center designers to consider MRAI in event-propagation timing for exactly this reason.

ADD-PATH changes what may be said, not when every statement must be said. It allows several paths for one NLRI to coexist under path identifiers, which can expose alternatives hidden by best-only advertisement. It does not make every intermediate local selection valuable or abolish outbound scheduling. Visibility and cadence remain separate control surfaces.

The peer relationship therefore contains an asymmetric temporal delegation. The sender decides how often it will reveal changes; the receiver experiences the resulting knowledge age. The receiver cannot force an UPDATE during the interval, but it can measure arrival spacing, negotiate service expectations, diversify upstreams and decide how much stale knowledge the relationship can tolerate.

Heng Lu's minimum-initial-specification principle fits that boundary. A common protocol must specify enough timing behavior for interoperability and bounded overhead. It should not impose one universal interval on networks with different processors, topologies, peer roles and customer consequences. Future timer choices remain local because the costs are local—provided their effects are observable to the parties that bear them.

Running-code primacy supplies the accountability test. The configured number is an intention. The effective inheritance, scheduler, actual UPDATE trace, peer observation and packet delivery are the system. If the running evidence shows that a “protective” timer extends customer loss, a successful commit does not defend the choice.

Data sovereignty here is not ownership of the route. It is control over disclosure from one's own routing process, bounded by the operational dependence created in a peering or transit relationship. The sender may protect its machinery; it cannot pretend the withheld freshness is costless to the receiver. Autonomy survives when both the local choice and its external effect remain measurable.

Three route choices becoming one message is neither deception nor truth purification. It is a scheduling decision. The last route is the latest local answer at the permitted moment, not a certified stable future. Leadership begins by naming what the timer spends: fewer control messages in exchange for older distributed knowledge.

Sources