Summary

  • Ties de Kock proposed collecting a new RIPE RIS peer feed for about two weeks, then deciding whether it should enter the permanent archive.
  • The trial separates permission to connect from the expensive decision to preserve every update for the long term.

“Forever” is the expensive part

An archive has a memory and a rent bill. Every BGP update kept for years can help reconstruct a routing event; every repeated or little-used feed adds bytes to the same bill. At RIPE 93, Ties de Kock described RIPE RIS as a project running since 1999 that depends on a bargain with network operators: RIPE NCC runs the infrastructure, while peers supply the BGP feeds the registry cannot produce by itself.

That bargain has become heavier. RIPE RIS expanded its collectors and sessions from 2015, and the volume of updates rose with the number of peers and the size of routing tables. Better compression helped, but it did not change the basic arithmetic of keeping data permanently. The current RIPE peering page says participating peers’ BGP traffic is recorded, stored in the RIS Database and made available to the Internet community. The same page currently says the online request form is closed.

RIPE’s collectors turn those sessions into records with different clocks. Its documentation describes periodic routing-table dumps and update files that capture changes; the updates are grouped at five-minute intervals. The record is useful well beyond a live dashboard. Researchers can trace long-term trends, and operators can revisit what collectors saw during an incident.

A chatty peer may be telling the truth

De Kock tied high update volume to real network events: changes inside a network or churn arriving from upstreams can both fill a feed. In the talk, RIPE used indicators such as unique BGP communities and adjacent autonomous systems to compare feeds. Those measures describe the information each view contributes and need to be read alongside what was happening in the network. A collector records what happened; the hard part is deciding how much of that view deserves permanent storage.

RIPE RIS once had an open peering approach, then became more selective as volume grew. Selective outreach produced some of the archive’s most distinctive feeds, yet the old selection rules were difficult to apply consistently to incoming requests. A strict gate can keep volume down while also turning away observations the existing network does not contain.

Let the feed audition first

De Kock’s proposed answer moves the decision later. Accept a session, collect its data for roughly two weeks, assess what it adds, and only then decide whether it belongs in the long-term archive. He said RIPE would try to use the trial data in its tools; how to expose it beyond those tools remained a question for the community. Permanent admission follows the post-trial assessment.

Selection turns on topological contribution; geography is one signal among several. A second session from the same autonomous system may show a different network path in another region. De Kock said RIPE would prefer full tables where possible, look for IXP route-server sessions, and be more selective with multihop peers, where each session can bring extra operational work. De Kock put those priorities to operators for feedback before RIPE writes a new policy.

The proposal trades a first-contact veto for a later archive decision. That gives a new peer a chance to demonstrate a distinct view, but it also makes the admission test more consequential: once a trial expires, missing updates cannot be recreated from a neighboring feed. RIPE NCC has not yet published the final admission scorecard or the retention and access rule for rejected trial feeds; those records would show how operators can challenge exclusion and whether researchers can use the short-lived data.

Sources: RIPE 93 transcript · Ties de Kock’s RIPE 93 talk and abstract · RIPE RIS peering policy · RIPE RIS route-collector documentation.