Summary

  • Two reachable RPKI validators can expose different validated payload sets because repository collection and validation do not complete everywhere at the same moment.
  • Selecting or switching the cache used by a router can change the evidence behind origin validation; availability and policy authority therefore cannot be treated as the same control.
  • A useful discrepancy protocol records validated-set digests, collection outcomes, router-to-cache assignment, a named decision owner, switch conditions and rollback evidence.

During a maintenance window, Validator A and Validator B are both healthy. Their RTR sessions are established, their processes answer checks, and no service alarm is red. Yet A has completed a repository cycle that reflects a recently withdrawn ROA while B is still using an earlier validated object from one publication point. Routers attached to A and routers attached to B can now classify the same prefix-origin pair differently.

Nothing in that scene requires a broken protocol. RFC 7115 describes the global RPKI as loosely consistent. Publication, retrieval, validation and delivery happen on separate clocks, so caches and routers can temporarily hold different information about the same prefix. Redundancy preserves access to more than one relying party; it does not manufacture one globally simultaneous answer.

The distinction matters because a validated cache is not a passive copy. It has collected repository objects, evaluated their validity and exposed a resulting set of validated payloads. A router consumes the set presented by the cache it is configured to use. Moving the router from A to B may restore connectivity while also changing which origin authorizations inform local routing policy. That is an operational choice, even when the failover mechanism is automatic.

Repository evidence explains how disagreement can arise. RFC 9286 requires a relying party to assess manifest timing. A manifest past nextUpdate is stale and causes failed-fetch handling, but that failure may be confined to one publication point. RFC 8182 gives RRDP its own session, serial and hash checks. A relying party may follow a contiguous delta sequence or retrieve a snapshot when recovery requires it. Snapshot retrieval is a defined recovery path, not proof that a validator is wrong; its meaning depends on whether validation completed and which repository state was accepted.

The router boundary adds another stage. Under RFC 8210, a router adopts a cache's current state after the complete response represented by an End of Data PDU. Refresh, retry and expire intervals determine how it asks again and how long previously received data may remain usable. A green TCP session or responsive cache does not show that two validators produced identical payloads, that every router completed the same update, or that switching caches will be policy-neutral.

This is why a dashboard should compare outputs and dependencies, not merely availability. For each validator, retain a digest or otherwise stable inventory of the validated payload set, the last fully successful collection, publication points with failed or stale material, trust-anchor and local-policy configuration, and the routers currently consuming it. A difference deserves investigation; it does not by itself prove which side is correct.

APNIC-hosted operational accounts point in the same direction. Guidance for installing a validator recommends multiple validators, while the Vocus implementation account describes monitoring client connections so routers do not quietly continue with stale databases. The lesson is not simply to deploy two processes. It is to observe the actual validator-to-router relationships and the state each process is serving.

Sources