Summary

  • RIPE NCC’s 1999 RIS proposal aimed to collect BGP announcements at several network locations and retain them so operators could investigate routing changes over time.
  • The proposal’s “full picture” was an ambition. Remote collectors at selected points could document the routes they received, not prove every network’s view, a packet’s path or end-to-end reachability.

A missing route raises a question about the observer

When a service becomes unreachable, an operator wants a practical answer: did the route disappear, or did this particular network stop seeing it? The distinction is older than today’s route-data dashboards. In October 1999, RIPE NCC published a design for a Routing Information Service, or RIS, built to collect BGP routing information at several locations and preserve its development over time.

The proposal described a powerful use for that record. If a user reported that a site had been unreachable earlier, historical routing information might help identify what changed. Operators could also inspect table development, convergence and route flaps. Rather than relying only on a live view after an incident, they could compare the network’s recorded state across time.

But the proposal paired this ambition with a more bounded architecture. It called for remote route collectors at a few major, “topologically interesting” points, such as exchange points. Those machines would collect BGP announcements and send the information to a central collector and database. The system would combine several vantage points; it would not sit everywhere in the network.

A BGP record belongs to a session

BGP is the protocol networks use to exchange reachability information between autonomous systems. A route collector participates in that control-plane exchange so it can receive and retain announcements from its peers. The resulting record tells an analyst what arrived at a configured session, at a particular place and time.

That is valuable evidence, but its scope matters. A route present in one peer’s table is not proof that every network received it. A route absent from one collector’s records is not proof that the route vanished everywhere. Nor does an announcement show that packets followed the advertised path, that a destination answered, or that a customer experienced a service outage. The proposal’s phrase “full picture” described what the project hoped its accumulated data would make possible; the document did not demonstrate universal coverage.

This is not a flaw unique to RIS. Networks have different policies and exchange different route views. A measurement system must observe through actual network relationships. More collectors can widen the record, but each one still speaks for the feeds and peers it can see. The location of an observer is part of the evidence, not background detail.

A project in development, not a finished service

RIPE NCC’s 2000 activity plan supplies the chronology. It says RIS had appeared in activity plans for several years but made little progress because of limited time and resources. A network engineer joined the New Projects group in 1999 and began working on it full time. The plan dates work to July 1999 and says a project plan was presented at RIPE-33.

The same document describes what was expected next: a first version for beta users in early 2000 and a regular service by the end of that year. RIPE-35 minutes record that the proposal had been presented at RIPE-34, finalized in October 1999 and made available as RIPE-200 for feedback. The documents therefore show a design moving toward a service, not a complete system whose coverage or operational results had already been measured.

That distinction changes how the record should be read. The project was not simply promising another live-looking-glass page. It was trying to make routing history inspectable and useful to operators. Yet a database can preserve only what its collectors receive and its system retains. The proposal does not report the eventual collector count, the launch date, uptime, user numbers or the incidents that the service later helped resolve.

What a route history can—and cannot—settle

The enduring contribution in the 1999 design was a method: gather routing announcements from multiple points, timestamp them, retain them and let operators examine change. That method gives an incident investigator a stronger starting point than an undated recollection or a single present-day table. It can help distinguish a change seen by one peer from a change visible across several feeds.

The method also sets a boundary on conclusions. A route archive is not a census of every forwarding decision. It is not a packet trace, a latency test, an application check or a registry record of who controls an address block. To infer broader reachability, an operator would need other evidence, such as measurements from the affected destination and network. Those separate observations should not be silently folded into the route collector’s record.

RIPE NCC’s original document is especially useful because it leaves both sides visible: the promise of a historical “full picture” and the engineering choice to collect at a few selected points. A good archive can make the Internet more observable without making it fully visible. Its value depends on knowing whose view is stored, which feeds supplied it and what remains outside the frame.

Sources: RIPE-200, RIPE NCC’s original RIS proposal (13 October 1999); RIPE NCC Activities & Expenditure 2000, RIPE-197; RIPE-35 minutes; RFC 1771, BGP-4; RIPE RIS MRT documentation.