Summary

  • RIPE NCC’s Q4 2026 plan says a software change will add subsecond timestamps to RIS MRT files using RFC 6396 extended-timestamp support. The item is marked in progress; the page does not say it has shipped.
  • A five-minute RRC03 file contains 188,592 MRT records across 300 integer-second timestamps. Finer resolution could separate some records within a second, but it would not establish clock accuracy, capture semantics, or synchronization across collectors.

A crowded second in the archive

At 04:00 UTC on 16 October, RIPE RIS’s RRC03 archive published a five-minute file with a familiar name: updates.20261016.0400.gz. Its common MRT headers carry integer-second timestamps. Across the file, 188,592 records fall into 300 second values. Every second contains multiple records; one contains 2,432.

That count is not a count of route changes. The file holds BGP4MP records, not a one-record-per-prefix ledger, and the header-only parse says nothing about whether those messages altered the routing table. Nor does it show that file order is ambiguous: the record sequence is still present. It shows a narrower fact. In this sample, the time field assigns the same second to many records that the archive preserves separately.

That distinction is the right place to start with RIPE NCC’s Q4 2026 work plan. Under “Improve MRT file quality,” the plan says a software change will allow subsecond timestamps in MRT files through RFC 6396 extended timestamp support. The status is “In progress.” It gives no release date, collector-by-collector rollout, measured clock error, or migration result. A separate item proposes adding a synthetic BGP hold timer to the processing pipeline to address a specific stuck-route condition in RIB/bview files. The two planned changes should not be treated as one project or as evidence about each other.

What a finer timestamp changes

RFC 6396 defines the ordinary MRT common header with a four-byte timestamp expressed as integer seconds since the UTC epoch, excluding leap seconds. For supported extended types, the format adds a 32-bit microsecond offset to that value. BGP4MP_ET is one of the extended-timestamp types.

The extension gives a producer room to represent fractions of a second. If two records that currently share a second receive different offsets, researchers can distinguish their assigned times more finely. That can make a dense burst easier to inspect and can help a parser retain useful temporal detail instead of rounding it away.

But “more digits” is not a clock-health report. Resolution answers the granularity the format can represent. Accuracy asks how close the reading is to a reference. Synchronization asks how two clocks compare. Capture semantics ask when, in the collector’s processing path, the timestamp is assigned. A fractional field answers none of those questions by itself.

NTP’s own performance model makes the distinction explicit through separate quantities for clock offset, jitter, dispersion, and synchronization distance. That is not evidence that a RIS clock is wrong; it is a reminder that a precise representation and a defensible measurement are different things. An MRT timestamp can become more discriminating while remaining silent about the uncertainty around it.

The collector is a viewpoint

RIS archives are useful because they preserve observations from route collectors, not because any one collector sees the entire Internet. A record’s context includes the collector and its peers, the MRT type and subtype, the archive interval, and the process that produced the file. Subsecond time improves one part of that context. It does not turn observations from different vantage points into a synchronized global timeline.

The RRC03 sample is deliberately small: one five-minute object, retrieved after its Last-Modified time, with a stable local hash and a parse limited to the standard common header. It is not a survey of RIS. Its 2,432-record maximum establishes density in one second of one file, not a route surge, an outage, a measurement gap, or a general limitation of RIPE NCC’s archives. Readers should be able to reproduce the count from the linked archive object without accepting any larger claim.

That boundary also guards against a subtler error. If two records receive different microsecond offsets, a reader may be tempted to infer that one network event caused another. Such an inference still depends on what the timestamp marks, how the clock was disciplined, and whether the events were observed by the same collector. Cross-collector comparisons add the relative clock error and the independent observation paths. A finer field makes a comparison more legible; it does not make the comparison self-validating.

What a useful completion record would say

When the planned change is deployed, operators and researchers will need more than a new type code in a parser. The public record should identify which MRT types and collectors emit the extension, when the change took effect, and how old and new records are distinguished. It should say what event the timestamp represents—receipt, processing, or another defined point—and whether downstream tooling preserves the fractional field.

Clock information should be described separately from the timestamp. A published method for monitoring synchronization and uncertainty, together with its limits and observation period, would let users judge whether within-collector or cross-collector timing claims are warranted. If RIS does not expose a particular clock metric, saying so is more useful than allowing the extra digits to stand in for one.

The same evidence should include parser compatibility and a small reproducible example. Tests could show that an extended timestamp survives decompression, parsing, storage, and export without rounding or changing record order. A migration note could explain mixed-format periods and how users should compare files across the transition. None of those checks requires RIPE NCC to promise that every archived event has microsecond accuracy.

The planned change is sensible as a format improvement. The reporting question is whether the added resolution arrives with enough context to be interpreted as measurement. Until a release and validation record appear, the Q4 page establishes an intention in progress, while the archive sample establishes only how many records share integer-second values in one file.

Sources