Thursday, 30 November, 11:00 - 12:30 (UTC+1)
Chairs: Florence Lavroff, Remco van Mook, Will van Gulik
Scribe: Alun Davies
Status: Draft
View the stenography transcripts
Remco van Mook
The presentation is available at:
https://ripe87.ripe.net/wp-content/uploads/presentations/107-connect-wg-ripe-correct_v02.pdf
The recording is available at:
https://ripe87.ripe.net/archives/video/1226
Will, Florence and Remco opened the session. Remco attended remotely.
Minutes from RIPE 86 were approved.
Will talked about the selection process for the Chair, noting that interested parties can express their interest every three years or as needed. The process involves a call to the mailing list, a two-week period for expressing interest, an announcement of candidates, a call for discussion, member approval, and a final decision by the Chair. He welcomed anyone interested in the role of Connect WG Co-Chair to express their desire on the mailing list or reach out directly.
Mirjam Kühne raised a question about the chair selection process, asking whether the WG is at the point of making a call for chairs. Will clarified that this is indeed a call for people to volunteer to chair.
Marco Paesani, Open-IX
The presentation is available at:
https://ripe87.ripe.net/wp-content/uploads/presentations/94-20230915_OIX_RIPE_Presentation.pdf
The recording is available at:
https://ripe87.ripe.net/archives/video/1229
Arnold Nipper (DE-CIX) asked how Open-IX aligns with the global Internet Exchange Federation (IX-F) and its definition of Internet exchanges. He also sought clarification on how OIX aligns with data center standards and certifications.
Marco acknowledged being on the marketing side and deferred a response to the first question about alignment with IX-F. On the second question, Marco explained that Open-IX standards are specific to the people working within the data centre and Internet Exchange (IX), differing from other standards like Tier 4, with distinct goals and focus.
[No presentation]
Remco flagged the policy proposal to reduce the default assignment for new Internet Exchanges (IXs) from /24 to /26. The proposal was discussed in the Address Policy Working Group and adopted earlier in the year. Remco emphasised that the new policy has been fully implemented, meaning that any new IX established will now have a default assignment size of /26.
Stavros Konstantaras, AMS-IX
The presentation is available at:
https://ripe87.ripe.net/wp-content/uploads/presentations/46-BCOP_IRRDBs_update_v1.pdf
The recording is available at:
https://ripe87.ripe.net/archives/video/1232
Will commented that he has almost resolved the case of the 44/9 case. He thinks he managed to reach them. This is a positive improvement and he'll update soon.
Blake Willis (Zayo) expressed support for the cleanup initiative regarding the policy proposal discussed. He inquired about communication with the Routing Information Database (RIDB) people, particularly in North America, as many ISPs use RIDB as their de facto registration. Stavros Konstantaras responded that while there is substantial usage due to ease, there are inherent problems, with a notable case involving tier 1. Blake further asked if there had been communication with RIDB, to which Stavros mentioned there hasn't been direct communication, but he believes RIDB is aware, possibly prompted by the new document. However, he clarified that RIDB wouldn't delete objects but mark RPKI invalids.
Berislav (Juniper Networks) raised a concern about the usage of information from various data sources, pointing out the reliance on old scripts using IRRd B. He suggested considering how to handle these tools and proposed the idea of creating a central repository that mirrors trusted databases. Stavros explained that tools like BGP Q4 have options to specify sources, and while updating defaults could be beneficial, it's a subsequent step. Regarding mirroring, Stavros mentioned that RIPE mirrors other databases daily, allowing users to obtain mirrored objects from ARIN, APNIC, etc., through RIPE's Whois service. He noted a 24-hour delay in this mirroring process.
Leo Vegoda, PeeringDB
The presentation is available at:
https://ripe87.ripe.net/wp-content/uploads/presentations/42-RIPE-87-Connect-WG-Leo-Vegoda.pptx.pdf
The recording is available at:
https://ripe87.ripe.net/archives/video/1234
Blake Willis expressed appreciation for the talk, particularly noting the value of the KMZ. He highlighted the carrier object's usefulness for carriers like his company and encouraged those with numerous buildings to utilise it. Blake suggested using the carrier object could reduce the need to respond to constant requests from data centre operators looking to add buildings to PeeringDB, creating a misleading impression of peering in numerous locations.
Arnold Nipper (DE-CIX) expressed concerns about unresolved issues on PeeringDB's GitHub, highlighting critical aspects such as data ownership and incomplete implementation of information imports from Internet Exchanges (IXs). He stressed the need for the community to expedite issue resolution, particularly in enhancing data quality. Leo encouraged active communication between the community and the product committee. He emphasised the importance of prioritising and explaining the impact of proposed changes, assuring ongoing progress in issue resolution and urging community members to express their concerns for further improvements.
Bijal Sanghani, Euro-IX
The presentation is available at:
https://ripe87.ripe.net/wp-content/uploads/presentations/110-Euro-IX-Connect-RIPE87.pdf
The recording is available at:
https://ripe87.ripe.net/archives/video/1235
Arnold Nipper noted that not everyone would necessarily know about RFC89350. He added that the RFC explains how to navigate the transition from IPv4 to IPv6 in light of the exhaustion of IPv4 addresses. It particularly focuses on Internet Exchange Points (IXPs), highlighting the reduction of standard assignments from /24 to /26. While acknowledging potential challenges, the RFC aims to provide guidance on the transition process. The speaker encourages input from network operators, especially those involved in IXPs, highlighting the long-term goal of moving exclusively to IPv6 for peering within the next five to ten years.
Bijal then led an interactive session asking the room what kind of entities they represent, what is could make peering better for them, and so on. On the question of what could make peering better, Arnold Nipper asked for clarification about the listed answer 'pricing transparency'. This raised further discussion over whether the issue was pricing or cost transparency.
Arnold Nipper noted the need for standardisation in peering policies, suggesting the implementation of a scheme to automate the availability and evaluation of peering policies beyond the current basic categories found in PeeringDB. Andrei Robachevsky (Internet Society) agreed with Arnold, emphasising the importance of security policies like MANRS. He suggested collaboration with PeeringDB to label and reflect these policies in their database. Bijal added that the IXP database actually gets the API feed from MANRS, so it's possible to see which networks and IXPs are MANRS‑compliant.
Leo Vegoda, speaking as PeeringDB manager, commented that the product committee discussed the possibility of adding certifications to PeeringDB. The decision was that certifications should only be included if they influence peering decisions. Leo encouraged users to inform the product committee if they would only peer with someone based on certifications, as it could influence their review of the decision.
Bijal then asked what strategies IXPs should pursue to respond to industry challenges. Blake Willis suggested that marketplace services should be added. Automation was the top response in the room. Arnold Nipper highlighted the existence of IX API, a software enabling automation of requests towards IXPs, citing support from exchanges like AMS-IX, LINX, DE-CIX, and Netnod. Will commented on the benefits of automation with IXP manager, recommending it for newcomers opening an IXP, as it simplifies processes, automates tasks, and ensures accurate list generation, fostering trust in the connection point.
Bijal asked: what is your main challenge when managing peering? Blake Willis noted she might add the options 'all of the above' and 'cost'. Arnold highlighted the importance of standardised communication for peering policies to facilitate automated setup of new peering sessions. Florence Lavroff commented on the cost comment made previously by Blake. This could be included in scalability because scalability is also a question of cost for most.
There were no further comments from the audience.
The recording is available at:
https://ripe87.ripe.net/archives/video/1238
Remco reminded everyone to rate the talks and the chairs closed the session.