Skip to main content

You're viewing an archived page. It is no longer being updated.

Connect Working Group Minutes RIPE 79

16 October 2019, 11 a.m.
WG co-Chairs: Remco van Mook, Will van Gulik, Florence Lavroff
Scribe: Alex Semenyaka

1. Opening

Welcome, Chairs, Scribe, Chat, Agenda, Minutes, Talks Rating
Remco van Mook, RIPE NCC EB opened the meeting.

2. Raci #1 - Dismantling Operational Practices of BGP Blackholing at IXPs

Marcin Nawrocki, Freie Universitaet Berlin
Presentation available at: https://ripe79.ripe.net/archives/video/212

Wolfgang Tremmel, DEC-IX asked the audience if someone used the BGP blackholing to filter the unused address space. Remco noticed that the silence of the audience is ambiguous.

Marcin noted that the designated for this purpose BGP community already exists.

3. Raci #2 - Keeping State Election Infrastructure Safe: How Cloudflare and Local IXP Connectivity Helped a Small Country in Europe

Vladislav Bidikov, Faculty of Computer Science and Engineering / IXP.mk
Presentation available at: https://ripe79.ripe.net/archives/video/213

Friso Feenstra, Rabobank asked how this initiative was accepted in the country. Vladislav said that it was well-received, so the other actors started to seek advice from the authors.

Michael Richardson, Sandelman Software Works asked if traffic with the users’ requests has gone through Vladislav’s IXP and then passed to CloudFlare. Vladislav explained that traffic went directly to CloudFlare. Michael noted that it meant that the traffic has left the country. Vladislav agreed and refined that it went to Sofia or Belgrade as the closest points of presence of CloudFlare.

Florence reminded the importance to rate the talks

4. IX-API: An Application Programming Interface for Interconnection Services

Florence Lavroff, Google for Thomas King, DECIX
Presentation available at: https://ripe79.ripe.net/archives/video/215

Gergana Petrova, RIPE NCC, read an anonymous question from the chat: what was the source for the IXP definition? Florence said that DECIX was a very big IXP and, being such, they were confident in their understanding of what IXP is; however, she said that they were open to new proposals.

Michael Richardson noted that the most labor-intensive part of IXP's work was cabling, not the configuration changes that were proposed to be automated. Florence agreed and noticed that there are no robots yet to exclude manual work, but this was one of the steps in the direction of full automation

Niels Bakker, Akamai Technologies requested to add to API the information about maintenance windows. Florence agreed that it would be a useful feature and asked to send them this feedback. Also she mentioned that all data they had in the customers portal should be available via API.

Gergana read a comment from the chat: remote participation converts IXP into ISP, diluting the benefits from the traffic locality. Florence did not agree, and answered that the traffic exchange is still the core business, although augmented with some new features: cloud connectivity, private VLANs, etc.

Michael Richardson said that if DEC-IX could finally provide a single API for ISPs and datacenters, it would be a big step forward. He suggested starting with creating a web interface as a transition mechanism to using this API. Florence agreed and gave an example of how such transition mechanisms work for Cloud providers API.

Remco van Mook noted that DEC-IX solved problems in ways that were too specific to this organisation. He asked why DEC-IX did that without interaction with other large IXP. Florence mentioned that she cannot answer this question in full, but it basically it was done to have an easy start. Remco expressed the opinion that the open standard development should be open from the very beginning. Florence suggested that Remco join the work. Remco said that DEC-IX already had his API documentation.

5. IPv6 Adoption on Internet Exchanges

Susan Forney, Hurricane Electric
Presentation available at: https://ripe79.ripe.net/archives/video/216

Jen Linkova, IPv6 Working Group Chair said that the IPv6 ratio on IXPs was not relevant due to the major part of IPv6 traffic went past the IXPs. Susan disagreed, pointing out that if IPv6 was deployed, the traffic should be there.

Jen also mentioned that the low percentage could be caused by the old equipment on IXP links, and ask if Susan has checked the situation when a peer advertised IPv6 to the world but did not show it on IXP. Susan said that she did not and it would be a good next step to do.

Gergana read a question from chat: how could NL-IX have more reachable addresses than assigned? Susan answered that the numbers were close, and the difference was probably due to the fact that reports may lag behind the live data that Hurricane Electric uses to measure reachability.

Gergana read a comment from chat: it was strange that there was neither Netnod nor Sweden. An attendee added that the measurements might see also the peering LAN where the addresses were used although they were never assigned publicly. Also, he said that from his experience one of the best IPv6 performers pushed using private peerings, and this could be another reason for low IPv6 percentage on IXPs. Susan agreed.

Blake Willis, Zayo and iBrowse, said that in Zayo (Tier-1 operator), they stopped establishing IPv4-only sessions, so new downstream should at least establish a IPv6 session. Also he admitted that in iBrowse they did not deploy IPv6 internally yet, but but at the external links, they were always establishing both IPv4 and IPv6 sessions - as a reserve for the future.

8. BEREC Consultation on Last Mile

Marco Hogewoning, RIPE NCC
Presentation available at: https://ripe79.ripe.net/archives/video/219

Remco asked the audience to continue the discussion in the mailing list.

6. Connect update

Florence Lavroff for Bijal Sanghani, Euro-IX
Presentation available at: https://ripe79.ripe.net/archives/video/220
No questions.

Will van Gulik informed the audience that a policy proposal to increase the size of the IXP pool from a /16 to a /15 had been accepted

Then he proposed to drop the further offline discussion.