Summary

  • draft-ietf-idr-bgp-rpki-yang-02 exposes origin-validation gauges at five named BGP RIB surfaces. The path, peer and address family are part of the observation; the number alone is not.
  • Two gauges can have the same value while describing different routes. Validation is also distinct from best-path eligibility, selection, export, remote acceptance and actual packet forwarding.

At 02:00 the dashboard showed 10,000 RPKI-valid routes. At 02:17, after a policy change, it still showed 10,000. The change ticket could therefore be closed—if the purpose of the change was to preserve a number.

It was not. The purpose was to preserve reachability to the intended destinations through the intended neighbors. One prefix had disappeared from the set; another had entered. The cardinality was stable. The network state was not.

This is the operational puzzle inside draft-ietf-idr-bgp-rpki-yang-02, published on 30 September 2026. The IDR Working Group draft defines YANG models for BGP information about RPKI. It gives management systems a common way to expose origin-AS validation, BGPsec and ASPA configuration and state. For origin validation, it places four gauges—unverified, unknown, invalid and valid—at five recognisable surfaces in the BGP pipeline.

That is valuable work. It is also exactly where leaders must resist turning observability into assurance.

Five locations, not one status light

The draft attaches origin-validation statistics to adj-rib-in-pre, adj-rib-in-post, loc-rib, adj-rib-out-pre and adj-rib-out-post, for IPv4 and IPv6. The names describe different moments.

The pre-policy inbound RIB is what a neighbor offered before inbound policy. The post-policy inbound RIB is what remains after that policy. The local RIB is the router's selected local view. The pre-policy outbound RIB is the material considered for advertisement to a neighbor. The post-policy outbound RIB is what remains after outbound policy.

A gauge at one location cannot be promoted into a claim about another. Ten invalid routes received from a neighbor do not prove that ten invalid routes survived import. Ten valid routes in the local RIB do not prove those routes were offered to a particular peer. Ten valid routes after export policy do not prove the peer accepted them. None of those values proves that packets followed the path.

The YANG path is therefore evidence, not plumbing. Remove the path and the observation loses the boundary that gives it meaning.

The same is true of address family and neighbor. An IPv4 total cannot quietly stand for IPv6. A total across peers can conceal a loss from one upstream and an equal-sized arrival from another. A global dashboard can look flat while the commercial, geographic or failure-domain exposure underneath it changes sharply.

Equal counts do not establish equal membership

Each of the four statistics is a gauge32: a current count at a named location. It is not a list of route identities and it is not a digest of that list.

This is a basic mathematical distinction with an expensive operational consequence. Two sets can contain the same number of members without containing the same members. A gauge can remain at 10,000 when one route leaves and another enters. It can remain flat while a policy swaps an entire class of prefixes. It can match at two pipeline stages even though the members rejected at the first boundary are replaced by different members before the second observation.

Nothing is wrong with the gauge in those cases. The mistake belongs to the interpretation.

An assurance system that needs to prove continuity must preserve route-set identity separately. That may mean a stable, canonical digest over the relevant prefix, origin, path and next-hop attributes; it may mean an exact bounded list for a critical set; it may mean membership tests for protected prefixes. The appropriate representation depends on scale and risk. The requirement does not: the receipt must identify what was counted.

Collection time matters too. The frozen draft does not promise that five independently addressed observations form one transactionally synchronized snapshot. Polling the inbound stage at 02:00:01 and the outbound stage at 02:00:08 during convergence can manufacture a difference—or hide one. A credible comparison records the collection method, timing window and consistency assumptions.

“Valid” answers a narrow question

RPKI origin validation asks whether the route's origin AS and prefix are consistent with validated ROA information. RFC 6811 supplies the foundation; RFC 8481 clarifies which routes are validated and separates validation from policy that has not been configured.

The label is useful because the question is useful. It is dangerous when the label is allowed to answer a different question.

An origin-valid route is not thereby the lowest-latency route, the preferred commercial path, a leak-free path, a BGPsec-valid path or an ASPA-valid path. It is not proof that the relying-party cache was fresh at the moment the dashboard was read. It is not proof that the route won best-path selection. It is not proof that export policy retained it. It is not proof that the neighbor installed it, or that forwarding hardware carries packets over it.

The draft itself preserves these distinctions by defining three models rather than one universal “secure” bit. Origin validation, BGPsec and ASPA concern different assertions. Collapsing them into one green badge would throw away the discipline the model provides.

The control settings sit beside the observations

The most important lines for an executive reader are not the counters. They are the choices around them.

Origin validation can be enabled per address family and restricted by an eligible-prefix policy. A separate route-selection container decides whether origin validity participates in best-path calculation. allow-invalid and allow-not-found determine whether those states may remain eligible, subject to the model's defaults and any further policy scope.

Advertisement is another decision. The router may send the Origin Validation State Extended Community described by RFC 8097, again with an eligible-prefix policy. Export is another decision still. The model can enable consideration of validation state for export, decide whether not-found routes may be sent and restrict that behavior with an export-specific policy, referring to RFC 8893.

The same observed validation distribution can therefore coexist with different routing behavior. A configuration epoch that changes allow-invalid, an eligible-prefix policy or export treatment can alter which routes are considered and sent while the aggregate valid count remains unchanged.

For that reason, a dashboard screenshot is not an audit trail. A defensible receipt binds the observation to the applied configuration and policy version—not merely the intended configuration stored in a controller. RFC 8342's Network Management Datastore Architecture is relevant here: configured values and operational values can differ while a device processes or applies change.

Build a chain of receipts, not a larger green tile

The remedy is not to discard the gauges. It is to put them in a chain whose claims are explicit.

  1. Validation inputs: identify the relying-party or cache source, its freshness state and a fingerprint of the VRP, router-key or ASPA material used.
  2. Applied configuration: record device and software identity, address family, neighbor, validation enablement, selection and export switches, policy identifiers and the operational configuration epoch.
  3. Stage observation: record the exact YANG path, stage, state, gauge value, peer, AFI/SAFI, timestamp and snapshot method.
  4. Route membership: preserve a digest or bounded list for the exact routes represented at that stage.
  5. Selection: record the candidates considered, validation-related eligibility and the route that actually won, with the other decision inputs needed to explain why.
  6. Export: preserve the peer-specific post-policy route set and the update or withdrawal emitted.
  7. Counterparty acceptance: gather evidence that the neighbor received and accepted the change under its own policy.
  8. Outcome: test forwarding, reachability and the intended service result in a bounded window.

No row proves the next. A fresh validation dataset does not prove that a router applied the intended policy. A correct gauge does not identify its members. A route set does not prove selection. Selection does not prove export. Export does not prove remote acceptance. Remote acceptance does not prove successful forwarding.

This chain also improves incident response. If a service fails while the valid-route total is flat, the team can locate the first boundary that diverged instead of debating whether the dashboard was “wrong”. Often it was right about the small thing it measured and silent about the larger thing leadership assumed.

The draft is a map, not a deployment report

Datatracker records revision 02 as an active Standards Track Internet-Draft in the IDR Working Group state I-D Exists. It is not an RFC. The frozen sources do not establish that a named vendor implements the model or that a production network exposes these paths.

That status boundary matters twice. First, operators should not write procurement or compliance claims as though the schema were already universal. Second, they should not wait for universal implementation before fixing the evidence design. Existing telemetry can already retain stage, peer, address family, policy epoch and route membership. The draft gives those distinctions a promising common shape; the operational need exists with or without a particular YANG module.

Running code decides what the count can prove

Heng Lu's Minimum Initial Specification and Running-Code Primacy offer the useful governance lens. Deterministic validation rules can be shared while later routing choices remain local. Publication does not make a model operational; implementation, configuration, validation and use do.

Applied here, an origin-valid label is a bounded fact produced under specified inputs. It does not grant a central system authority over best-path or export choices. Those remain visible local decisions. The management contract should help participants expose and verify them without pretending that one count describes the whole network.

Leadership should therefore ask a sharper question at the next change review. Not “did the valid-route count stay green?” but “which routes, at which stage, under which applied policy, were selected and exported—and what did the packets do?”

The first question produces a reassuring tile. The second produces an operational receipt.

Sources