Summary

  • A 2026 peer-reviewed study reports that updates around reconstructed RPKI events remain below 1% of observed BGP UPDATE volume.
  • The method counts every update inside a selected convergence window as related, a rule that can overstate the associated volume.
  • The ratio does not measure each peer’s processing burden, path changes, Route Refresh work or user reachability.

A small share answers a real question

The finding deserves credit. Samuele Quinzi, Cristel Pelsser and Giuseppe Di Battista estimate BGP UPDATE volume around changes to Route Origin Authorizations in a peer-reviewed paper published in Proceedings of the ACM on Networking. Its abstract says the updates associated with RPKI-related changes remain below 1% of total observed update volume, even as RPKI adoption and the routing table grow. That answers an important operational question: do these events dominate the observed stream of routing messages? In the measured series, they do not.

Quinzi’s APNIC guest post explains how the researchers reconstructed RPKI events from historical data and counted every UPDATE inside a selected convergence window as related. Some messages could have another cause. Including all of them tends to enlarge the numerator. So the result is a broad estimate of temporally associated message volume, not proof that every counted update was caused by RPKI. That is a useful conservative choice for this one measure, not a reason to dismiss the result.

Stability has several units

A percentage is only as clear as its numerator and denominator. Here, updates associated with events are compared with all observed BGP updates. The ratio is not the share of routers affected, prefixes changing validation state, selected paths changing, or customer traffic interrupted. An UPDATE carries routing information; it does not directly say whether an application remains reachable.

The observation system matters too. RIPE RIS collects routing data from BGP peerings. It lists RRC00 as an Amsterdam multihop collector with global scope. “Global” describes the collector’s reach; it does not make a peer-observation service a census of every forwarding path, every router’s CPU or every customer session. Nor does an aggregate share show whether activity is concentrated among a subset of peers.

The reverse inference would also be wrong. Many UPDATE messages do not prove that users lost service. Message volume, work performed by each peer, route-selection churn, convergence time and data-plane reachability are related, but they are different observables. The paper measures the first of these more directly than the others.

Route Refresh is a separate workload

RFC 9324 documents a distinct RPKI-related mechanism: after new validation data arrive, some implementations have asked peers for Route Refresh so that routes can be reevaluated. The RFC says this can transfer a serious resource burden to those peers and recommends retaining affected routes to avoid unnecessary refresh requests. It also records deployments in which ROV was turned off and peerings were ended.

That is a specific operational hazard, not a statement about every implementation and not a refutation of the study’s UPDATE ratio. A Route Refresh request and the resulting re-advertisement are distinct from counting UPDATEs in a reconstructed event window. They need separate counters: how much UPDATE volume coincides with RPKI events, and how much refresh work one speaker asks its neighbors to perform.

A broader answer needs separate measurements

The next step is not to replace one headline with another. It is to publish measures with their boundaries intact: UPDATEs per event and peer; Route Refresh requests and routes re-advertised; time until route state settles; frequency and duration of path changes; and, where available, independent reachability signals. Each measure needs a stated observation point, period, denominator and treatment of missing data.

RIPE’s historic RPKI archive uses daily snapshots. APNIC’s explanation notes that short-lived changes can fall between them. RPKI-Flutter observes events more frequently over a shorter, recent period, and the post says the overlapping update-volume estimates are similar. That cross-check supports the archive reconstruction for the quantity compared. It does not automatically measure peer resource use or user experience.

The fair conclusion is neither “RPKI is harmless” nor “RPKI destabilizes BGP.” The study is useful reassurance about one narrower concern: in the observed series, RPKI-related events do not account for a large share of UPDATE volume. A broader stability judgment must name the resource, path or service whose stability is at issue.

Sources

Primary sources and protocol references: