Summary

  • RIPE reported that the latest RRC07 update file was timestamped 19:20 UTC on 6 October, then marked the incident resolved at 21:53 UTC and said bview files had been created normally.
  • The current archive index lists 30 consecutive five-minute update filenames from 19:25 through 21:50. Their advertised modification times fall between 21:53 and 21:55; four sampled files decompress fully, but their MRT records were not parsed.

Analysis

Two clocks, two different claims

A routing-data archive carries more than one time. The timestamp embedded in an update filename identifies the file’s interval. The directory’s modification time records when the archive server says that object changed. Neither is a substitute for the other.

RIPE’s status notice first put the latest RRC07 update at 19:20 UTC. In the current public index, the preceding file, updates.20261006.1920.gz, is shown with a 19:25 modification time. The next 30 names run without a five-minute gap from 19:25 to 21:50. Twenty-five display a 21:53 modification time, four show 21:54 and one shows 21:55. That pattern is consistent with a delayed series becoming visible in a short burst. It does not reveal the internal processing path or the exact time each reader could first retrieve a file.

The incident page says the event was resolved at 21:53 UTC on 6 October and that bview files were created normally. RIPE describes bviews as snapshots of routing state at a point in time; update files carry changes for an interval. A normal snapshot therefore cannot answer whether every intervening update file was complete. The products support different kinds of analysis.

RIS data is used to examine routing state, investigate BGP events and follow longer trends. For a retrospective, a missing interval can make an empty chart ambiguous: it may represent no observed changes, or an observation file that was not available. A continuous list published later narrows that uncertainty about filenames, but not about the contents of every interval.

Four files at the edges of the sequence—19:20, 19:25, 21:45 and 21:50—were retrievable and passed a full gzip decompression check. That is a transport-level check only. The MRT entries were not parsed, and the other 26 files were not sampled. The current index also cannot establish what clients saw during the incident. RIPE’s public notice does not give an RRC07 root cause, report route loss or describe a traffic impact. None should be inferred from the publication gap.

Sources