Summary

  • RFC 9972 adds BMP 64-bit Gauges for current route counts at explicit stages, including pre-policy and post-policy Adj-RIB-In, selected Adj-RIB-Out views and, for selected types, Loc-RIB. The stage is part of the fact.
  • A Gauge can support a bounded statement about a count. It does not reveal an individual prefix and its attributes, the reason a policy accepted or rejected it, a peer’s received UPDATE, FIB programming, or packet delivery.

A number needs a location

“The router has 900,000 routes” sounds like a complete operational sentence. It is not. Before a BGP speaker selects a route, it can hold information received from peers in an Adj-RIB-In. Inbound policy can filter or alter that information. The post-policy Adj-RIB-In still precedes best-path selection. The Loc-RIB is the selected result and may also include routes imported from an IGP or a local static configuration. An Adj-RIB-Out is a peer-specific view prepared for advertisement, with another policy boundary on its way out.

Those are different places in the decision chain. A count from one of them should not be silently moved to another.

RFC 9972, Advanced BGP Monitoring Protocol (BMP) Statistics Types, gives that distinction a common telemetry vocabulary. Mukul Srivastava and Changwang Lin are its editors; Yisong Liu and Jinming Li are fellow authors. The IETF consensus document defines new 64-bit BMP Gauges while retaining the existing Statistics Report format. Its purpose is more refined route monitoring for maintenance and troubleshooting, not a universal declaration that every number observed on a router means the same thing.

Types 18 and 19 report the current pre-policy Adj-RIB-In count globally and by AFI/SAFI. Types 20 and 21 report the post-policy version. Type 22 is particularly revealing: it reports the current per-AFI/SAFI number rejected by an inbound policy during ongoing policy-configuration changes. It is not the old monotonically increasing event counter. Type 23 reports a current accepted post-policy count. Each is useful because it says where the observation stopped.

The count is not the route

A count of accepted routes cannot show which route was accepted. It cannot preserve prefix, next hop, AS_PATH, communities, timestamp, peer, policy version or the rule that produced the decision. It does not show whether the selected route entered the Loc-RIB, whether an outbound policy prepared it for a specific peer, whether an UPDATE reached that peer, whether a FIB entry was programmed, or whether traffic used it. Those may be connected events, but they are not columns hidden inside one Gauge.

The same caution applies to a rejected count. Ten routes rejected by a current inbound-policy Gauge is evidence of a defined quantity in a defined view. It is not an explanation for ten particular rejections unless route-level evidence identifies the affected prefixes and the policy result. A route can also be absent for other reasons: feature state, peer state, route selection, damping, threshold enforcement or a different collection scope.

This is why a good dashboard should resist compressing every measure into a single “routing health” colour. A global count, a per-AFI/SAFI count and a route-level trace each answer a different question. Joining them can be excellent operations; replacing one with another is not.

Partitions may disagree honestly

RFC 9972 permits global and corresponding per-AFI/SAFI statistics to be reported together. That does not authorize an operator to assume that their values must always sum exactly. The RFC says producers and collectors may perform consistency checks but must not assume strict dependencies: race conditions or partial failures can leave a partition sum different from a global count. The stated response is a warning, not disruption of protocol operation.

That clause is a small lesson in measurement discipline. A mismatch may point to a sampling interval, asynchronous update, incomplete report or implementation fault. It should prompt a timestamped investigation. It cannot, by itself, prove that a routing table is corrupt, a peer is malicious or an outage exists.

The lifetime of the number matters too. A Gauge can reset through manual clearance or overflow. RFC 9972 requires producers and collectors to track and log the discontinuity. A graph that glides from one value to another without recording the reset invites an invented story about route withdrawal or recovery. The receipt needs the raw value and its continuity state.

A common wire shape leaves decisions local

The specification keeps its common layer deliberately compact. Global values are one 64-bit Gauge; per-AFI/SAFI values pair AFI, SAFI and a 64-bit Gauge. Only negotiated, supported AFI/SAFI values with data to report appear. Unknown statistic types must be ignored by a BMP implementation. Some new Gauges concern GR, LLGR, RPKI or other configured features and should only be generated when those features are enabled.

That is not an omission. It means report scheduling, rate limits, enabled subsets, alert thresholds and investigation practice remain operational decisions. RFC 9972 advises operators to rate-limit statistics, enable only what is needed and configure subsets per router. It does not claim that a registered type proves a feature is active on an observed device.

Heng Lu’s Running-Code Primacy makes the practical test plain. The portable standard gives a name and scope to an observation. The running system supplies the actual record: which producer emitted it, when, under which configuration, after which reset, and what other evidence supports any larger claim. Telemetry becomes stronger when it remains honest about its edge.

Sources