Summary

  • Stefan Wahl said the exchange directories he discussed still reduce an IXP to a peering LAN and a member ASN/port relationship, although operators now run several services across the same site or network.
  • That missing service identity affects more than the map: filters, accepted prefixes and trust inputs need to follow the service they govern.

An Internet exchange can look tidy on a directory page and messy in the rack. Stefan Wahl’s RIPE 92 talk put those two pictures side by side. The model still starts with one peering LAN, one exchange ASN and a member port. The operating network may contain remote peering, cloud on-ramps, hosted caches, several ASNs and services that cross Layer 2 and Layer 3.

Wahl, Route128’s CTO and a Euro-IX board member, used a San Francisco example to make the mismatch physical. An exchange there carried Layer 3 services alongside its Layer 2 fabric. Two VRFs let the services cross into the peering mesh, a “Layer 2.5” arrangement in his shorthand. The directory model had no clean place to describe that service. This was not a speculative architecture slide; Wahl said the example was already carrying traffic.

Once an IXP has several services, a single exchange-wide label stops answering the operator’s real questions. Which service accepts which prefixes? Which route server and attachment point belong to it? What IRR sources or RPKI trust settings apply? A record that says only “member connected to exchange” leaves automation to infer boundaries that the directory never named.

Wahl’s proposed direction was a service-level vocabulary and locator that could be shared across directory and API views. Filters and trust should follow the service boundary. He also listed IPv6-only fabrics, link-local addressing and per-VLAN prefix limits as details that do not fit neatly into today’s common fields.

He did not call for merging directories, replacing the existing operational practices or building a real-time validator. Local provisioning state and member intent still belong in the tools that operate them. The working group was left with a narrower choice: give each service a stable public description, or let every downstream tool keep guessing where one service ends and the next begins. RIPE 92 records the proposal and questions, not an adopted schema or delivery date.

Sources