Summary

  • Holterbach’s project had three IXP route-server BMP feeds and 60 participant sessions on 27 October; he said they exposed about 200 route-server sessions and more than 1,000 bilateral sessions.
  • A RIPE 93 audience question put storage, query speed and export scope at the centre of the adoption problem.

Analysis

Thomas Holterbach came to RIPE 93 with a working map and a request. The computer-networks researcher, who earned his PhD at ETH Zurich in 2021 and later worked at the University of Strasbourg, is building bgproutes.io. An IXP is a shared switching fabric where networks exchange routes through a route server or direct BGP sessions. His 27 October plenary talk presented the IXP Explorer as a way to see routing activity through feeds from exchange route servers and participant routers using the BGP Monitoring Protocol (BMP).

The request was simple to state: more operators should contribute. The evidence on the screen was already tangible. Holterbach said three smaller IXPs had connected their route servers to the platform. Sixty BMP sessions from IXP participants exposed roughly 200 BGP sessions between participants and route servers, plus more than 1,000 bilateral sessions. Holterbach presented them as the project’s 27 October snapshot.

The gap he described is practical. A collector’s BGP session sees the routes its peer exports to it. A route-server looking glass can reveal more local state, but polling it gives snapshots. BMP can stream selected routing information and peer-state changes, depending on what a router exports. The IETF’s RFC 7854 defines BMP as a monitoring interface for BGP sessions and route views.

Then the Q&A supplied the uncomfortable arithmetic. Maria Matejka described a hypothetical IXP with 1,500 BGP connections and a peer importing 50,000 routes. A route event can multiply across connections when a session flaps. Matejka framed her numbers as a hypothetical load case. Holterbach agreed that processing and storing BMP data while keeping queries fast was one of the hardest parts of the system.

The next question was who gets to choose the feed. Holterbach said operators can select peers at the router or exclude peers when configuring a platform session. He also said an IXP and its participants have to be willing to share. Asked what they regard as sensitive, he said he needed more feedback from operators. That answer puts consent inside the design: the project needs broader visibility, while every contributor still chooses what leaves its network.

The project’s IXP Explorer documentation shows how that bargain becomes a product. A user can inspect route-server and participant feeds, including bilateral sessions, then follow the observations into more detailed route data. The visible-prefix summary updates daily; the API supplies nearer-real-time access. The map grows with contributions, while each new feed adds work for collection, storage and delivery.

Holterbach’s own position is two-sided. He acknowledged that richer routing data could help an attacker infer policies or check whether an attack worked. He argued that defenders gain more because additional observations make hijacks harder to hide from collectors. He offered that as his assessment of the balance.

The public record gives no per-feed volume or processing-cost series and does not establish whether any invited operators declined; a feed-by-feed history would show whether capacity or sharing scope is slowing wider participation.

Sources