Connect Working Group Minutes RIPE 92
Date: Wednesday, 20 May 2026, 09:00 - 10:30 (UTC+1)
Chairs: Will van Gulik, Stavros Konstantaras, Paul Hoogsteder
Scribe: Alun Davies
Status: Draft
View the stenography transcript
1. Opening & Housekeeping
WG Chairs
The session began with a quick welcome from Will and his co-chairs before moving on to the packed agenda ahead.
2. Engaging with the Product Committee
Leo Vegoda (PeeringDB)
Leo Vegoda explained the role of PeeringDB’s Product Committee and how it supports the development of the platform. He outlined the committee’s decision-making process, the factors it considers when evaluating proposals, and the challenges involved in balancing the needs of different stakeholders. The presentation also described how users can engage with the Product Committee and contribute to the ongoing development of PeeringDB through its community-driven processes.
Alarig Le Lay (Breizh-IX/LillIX/ER-IX, speaking for small IXPs in France) asked about the possibilities for clearing up data for peering LAN prefixes in PeeringDB. Leo responded that IXs can't remove their last prefix, but if a prefix grows from a /24 to /23, for example, there's a tool that support people can use to renumber. This might involve help from support at Peering DB. He noted that this doesn't happen often, but if it's a problem the community would like to see fixed, they would like to make the process as smooth as possible.
There were no further questions.
3. Creating a peering portal with Peering Manager
Guillaume Mazoyer
Guillaume presented new peering portal functionality being developed for Peering Manager, an open source tool for managing and automating peering relationships. The portal is intended to provide a self-service interface for requesting and managing peering sessions, reducing reliance on email-based workflows and enabling greater automation. He also discussed future enhancements, including support for private interconnections, standardised APIs, and fully automated peering workflows between participating networks.
Marco Schmidt (RIPE NCC) read out a question from remote attendant Rinse Kloek (Kindes) who asked whether a basic version of the peering portal would be published, similar to PeeringDB, in order to encourage wider adoption. Guillaume replied that there were plans to release the software, although no specific timeline had been set.
Mike Blanche (Stratus Novem Ltd, speaking as independent peering enthusiast) welcomed the project saying it provides an additional layer on top of PeeringDB, making it easier for operators to use PeeringDB data to manage their networks and interconnections. He noted that community support would be valuable in progressing the related IETF draft and encouraged additional implementations of the associated API.
Mike also highlighted the importance of supporting the project, particularly in light of concerns about some large networks reducing their use of Internet exchanges. He suggested that tools which reduce the administrative burden of managing peering relationships can help encourage continued participation in Internet exchanges, and that IXPs may wish to support this work for that reason.
4. Persistent unknown unicast - A peering-LAN case study
James Rice (Jump Networks Ltd)
James presented a case study of persistent unknown unicast flooding on a large European Internet Exchange, describing how stale neighbour entries and mechanisms defined in RFC 4861 can cause traffic to continue being flooded and forwarded long after a MAC address change. He outlined the technical mechanisms involved, the operational and security implications, and a five-year timeline of reports and remediation efforts. The presentation highlighted potential impacts on confidentiality, integrity and availability, including the exposure of customer traffic and the risk of service disruption, and concluded with recommendations for both Internet Exchange operators and members on detecting and mitigating similar issues.
Jen Linkova (Google) noted that the IPv6 behaviour described in the presentation appeared to depend on an optional implementation choice in RFC 4861, relating to the handling of source link-layer addresses in neighbour advertisements. She suggested that the specification may not have adequately considered scenarios where traffic is addressed to a device at Layer 3 but not at Layer 2, and said she would investigate the rationale behind the current specification and whether changes might be appropriate.
James agreed that the behaviour was worth examining, but suggested that Internet Exchange operators should not rely on protocol changes that could take many years to be implemented when operational mitigations are already available.
Lutz Donnerhacke (IKS Service GmbH) commented that the underlying issue had been well known for many years and asked how this operational knowledge had been lost. They suggested that new engineers should be given opportunities to learn from past operational mistakes in controlled environments so that similar problems can be avoided in future.
Will van Gulik agreed, noting the importance of knowledge transfer within the community and encouraging experienced operators to share lessons learned with newer participants in order to help build a more resilient Internet.
There were no further questions.
5. Beyond Peering LANs: Representing IXP Services in a World That No Longer Fits the Schema
Stefan Wahl, Route128 GmbH (CTO) and Euro-IX (Board Member)
Stefan examined how the traditional directory model used by PeeringDB, IXPDB and related tools is increasingly unable to represent the range of services offered by modern Internet Exchanges. Drawing on recent work around authoritative IRR data and discussions within the Connect Working Group and Euro-IX, he highlighted challenges including multi-ASN services, cloud on-ramps, remote peering, hosted caches and non-LAN service offerings. He outlined possible extensions to existing directory schemas and APIs, discussed the implications for automation and operational tooling, and invited the community to consider how directory data models should evolve to better reflect current operational realities.
Arnold Nipper (DE-CIX) noted that, in addition to PeeringDB and IXPDB, the Packet Clearing House (PCH) directory is also widely used. He suggested that better correlation between identifiers used by different directory services would make it easier to unambiguously identify Internet Exchanges across platforms, particularly where naming conventions differ. He added further that he didn't see a need for closer coordination between IXPDB and PeeringDB and suggested that maintaining multiple directories may not be necessary. Stefan didn't comment on that point.
Svetoslav Naydenov (BIX.BG) questioned whether all additional services offered by IXPs should be represented in public directories, citing private network interconnections (PNIs) as an example. They noted, however, that multicast services are an important offering provided by some IXPs and could benefit from better visibility in directory data.
Stavros Konstantaras asked how the community should approach evolving existing schemas to meet current operational requirements. Stefan suggested that progress would be best achieved through a small group of contributors working iteratively on new API versions, rather than attempting to reach consensus in a much larger group. He proposed greater collaboration between PeeringDB, IXPDB, IX-API and operators of automation tools such as Peering Manager, and suggested that a hackathon could help develop and test new ideas.
Lorenzo Moro (TOP-IX) observed that Layer 3 services are becoming increasingly common at IXPs and suggested that the community should first survey and document the services currently being offered before attempting to standardise how they are represented. Stefan agreed and noted that one such service discussed during the presentation was already carrying significant traffic volumes.
There were no further questions.
6. The Value of a Full Route Peer for a Route Collector Project
Nina Bargisen (RouteViews)
Nina presented an analysis of the value different BGP peers provide to the RouteViews route collector project. Using metrics based on unique prefixes, origins, AS paths and AS-path edges, she compared the information contributed by different types of networks. The results suggested that networks providing full routing tables, particularly content and edge networks with a broad peering footprint, contribute significantly more unique topology information than traditional transit or customer-cone-only peers. The analysis is being used to inform RouteViews' peering strategy as the project continues to expand its global collector platform.
Sebastian Becker thanked Nina Bargisen for the work of the RouteViews project and encouraged the team to continue its efforts.
Martin (AS9075) said that his network provides full routing tables to RouteViews and asked whether contributors could gain access to the type of analysis presented during the talk in order to better understand the value of their own contributions.
Nina replied that RouteViews is considering how to provide contributors with additional analysis and metrics about the data they supply. However, she noted that the project relies heavily on community goodwill and participation, and that any such offering would need to be balanced against RouteViews' role as an open community resource. She added that all of the underlying data is publicly available and can be analysed independently by anyone wishing to perform similar studies.
There were no further questions.
7. Closing
Will thanked the speakers and participants and bid everyone farewell till next time in Sofia.