Summary

  • A new individual IETF draft proposes event and periodic push modes for the RPKI-to-Router protocol, with six new packet types and an opt-in subscription.
  • Its event packet signals a change but carries no changed route-security data. RFC 8210 already lets a cache send an unsolicited Serial Notify; the proposed periodic packet is the path that actually carries data.

When a routing-origin authorization changes, the interesting question is how soon a router gets usable new data. A bell can ring instantly. A router still needs the bytes and a serial number it can trust. The 28 October push proposal advertises a faster RPKI-to-Router path, then splits those two jobs across different messages.

The old bell is real. RFC 8210 gives the cache a Serial Notify packet it can send without a router request. The router may respond immediately with a Serial Query or Reset Query rather than wait for its refresh timer. The current 8210bis draft preserves that choice. A notify alerts; a query starts the exchange that returns changed announcements and withdrawals. Calling that whole sequence “pull” hides the unsolicited first move.

The new draft puts a subscription on top of the RTR session. After initial synchronization, a router can request event-driven alerts, scheduled updates, or both. It can cancel the subscription. The proposal asks IANA for six new packet types, including Subscribe Request and Response, Unsubscribe Request and Response, Push Notify, and Periodic Update. That is more protocol machinery and per-subscriber state, so the payoff needs to be visible at the router, not just in the packet list.

The event-driven Push Notify carries a subscription ID, a change type and a serial number. The draft mentions ROAs, ASPAs and router keys as possible changes. Its packet diagram carries none of those changed objects. It also leaves the follow-up exchange after this new alarm undefined. The packet may arrive sooner than a polling timer; the document does not show how that event itself moves the data into the router. RFC 8210's older alarm already gives the router a way to start a query immediately.

The payload appears in the other lane. Periodic Update starts a sequence of Cache Response, zero or more data packets and End of Data at a negotiated interval. It includes the serial number the cache thinks the router holds. If the router's actual serial differs, the router must not process the data. That check keeps the receiver's state from being silently overwritten by a sender's guess. It also makes the practical question sharp: what is the end-to-end time from a changed validated object to a router that has accepted a matching update?

The Datatracker record lists this as an individual Standards Track proposal at I-D Exists. The text provides no reproducible latency comparison or deployment trial. A later draft that specifies event data transfer and measurement conditions would settle the speed claim. Today the design specifies a new alarm and scheduled data delivery; it does not specify the urgent data handoff its motivation asks for.