Dear all,
In order to prevent another red-face moment, please find below the draft minutes from the previous meeting. I trust you will read them all carefully so we can sign off on them during our next meeting! Kind regards Remco Co-chair of Connect-WG Connect Working Group RIPE 78 22 May 2019, 11:00-12:30 WG co-Chairs: Remco van Mook, Florence Lavroff, Willem van Gullik Scribe: Rumy Spratley-Kanis 1. Opening (Welcome, scribe appointment, agenda, proposed session format) The presentation is available at: https://ripe78.ripe.net/archives/video/50/ Florence asked attendees what businesses they worked in; this was measured by a show of hands and is as follows in descending order: - IXP - ISP - Content - Enterprise - Educational network 2. The Elusive Internet Flattening: 10 Years of IXP Growth Ignacio Castro, Queen Mary University of London The presentation is available at: https://ripe78.ripe.net/archives/video/51/ Nina Bargisen (Netflix) asked if, with IXP, Ignacio meant public peering. He confirmed that he collected public peerings from the peering DB. Nina said it makes some of the conclusions confusing because when there is a big flow in an IXP, it is moved to private interconnections. These peerings should be included to assess if the Internet is getting flatter because of Internet exchanges. All operators do private interconnections, so it would be useful to adjust the methods and include these. Nina asked Ignacio to study each of the CDNs and how they route their clients because not all the CDNs do it the same way. Ignacio agreed with the comments about private peering but he felt constrained due to having to look at historical data, which doesn’t include changes in redirection strategies. Martin Levy (Cloudflare) pointed out that the graph on slide 27 doesn't tell the full story. The divergence is partly a business model of the different players and is not a reflection of the IXPs in any way. While the graph is correct, it doesn’t tell whether we are better connected today than 15 years ago. He added that the graph by itself wasn’t flattering for Internet exchanges; even if they are the saving grace for how the internet works today. He asked whether Ignacio could share any data that wasn't based on IXP data. Ignacio empathised with Martin's comment, then explained that it was very difficult to find data with the limitations that were in place. He agreed that looking at redundancy multihoming would be an extra metric that would be interesting to review. In the end, he tried to look at two relatively simple metrics that are comparable over time and easy to convey. Martin commended him on his study. Andrew Sullivan (ISOC) mentioned that he was troubled by the last discussion. The numbers and graphs seemed to contradict the work done by IXPs. This may lead to an incorrect conclusion that IXPs are not worth the investment – he did not believe this. He encouraged Ignacio to find additional numbers to show a complete picture. Ignacio mentioned that his original plan for this work was “should I build an IXP?” His intent was not to say IXPs don’t matter, his message was, that in the specific metrics he looked at, the impact was as expected, particularly with regards to path length. The impact of transit dependence was clear. Blake Willis (Zayo / iBrowse / L33) added to Nina's point about private interconnects (PNIs) saying it would be interesting if Ignacio could dig into his data and analyse when a path moved from an IXP to a PNI. This could be a way to analyse where the bigger flows are. 3. RPKI at Route Servers Follow Up Nick Hilliard, INEX The presentation is available at: https://ripe78.ripe.net/archives/video/53/ Marja Jan Matejka (CZ.NIC), a developer of Bird, mentioned that in Bird Version 2, there is a special feature called Custom Route Attribute. This feature allows you to name and use your route attribute instead of these defined contents. He suggested that this would be much faster. He asked why they weren’t doing both RPKI and IRR DB? Nick replied they do both, but they start with RPKI filtering. If it fails the RPKI validation, it will drop the prefix, and if it’s unknown, it will pass through the IRR DB. However, the ASN check has to be evaluated first, so it’s IRR DB AS check, followed by RPKI validation, followed by regular IRR DB validation if it’s RPKI unknown. A participant asked whether they also do comparison evaluations against, for instance, FRR. Nick replied that they hadn’t tried FRR because there hadn’t been a huge amount of code changes for the route server code paths in FRR. Also, there were scaling problems with Quagga. There are other issues with FRR it being more difficult to do atomic config changes and updates, and the FRR will need a little bit more work before they can use it. Aris Lambrianidis from AMSIX asked whether they had a change of heart with regards to implementing RPKI in the EU route servers. Nick said this was a good question – and for them, this was more a policy issue rather than a technical issue. They were previously sceptical about RPKI implementation because when seen from a very high level, it creates a single point of failure. If compromised, for example, at an RIR, a red button could be pressed to disable a particular prefix or set of prefixes. Before, the BGP inter-domain ecosystem was based on a peer-to-peer system with filtering arrangements between organisations, whereas now there is a top-down thing which is controlled by the RIRs. He added there had been an increase in the amount of BGP hijacking that is difficult to deal with unless you implement a tool like RPKI. Like any policy decision, it’s a balance between not implementing something that could potentially cause problems, and implementing something that could fix a problem you already have. In the last few years, RPKI has seen various changes at a policy level. There is now jurisprudence about how courts interact with organisations like the RIPE NCC about deregistering prefixes, and there is much clearer understanding from a legal point of view. So, they looked at all the issues from a technical and a policy angle and concluded that RPKI was a good way to go. Randy Bush (Internet Initiative Japan) mentioned that RPKI is a database and this means RPKI based origin validation. He added that while it will help, it is not a magic bullet. Nick confirmed and agreed with Randy. He added that if hijacks and misconfigurations were easy to solve, they would have been solved years ago. RPKI makes it more difficult to make bigger mistakes. 4. BGP Filtering on AS15169 Using IRR and Other Data Arturo Servin, Google The presentation is available at: https://ripe78.ripe.net/archives/video/56/ Ruediger Volk (Deutsche Telecom) asked why they are not considering to mark the regular RPKI evaluation early on, as marking and reporting what looks invalid would be a good idea and helpful from the beginning. Arturo replied that he and Chris have considered it and will be further discussed. Ruediger asked why they were considering RPKI as a source only for invalidating IRR data. Why not include the RPKI ROA data sets as an additional quality source of route information? Arturo replied that they will when they are ready to use it. Ruediger mentioned that if they don’t have the tools, he has them. Arturo added that RPKI only has the origin, and they need more, but they will not use one signal, they need more signals to make it reliable. Ruediger said that Arturo was only talking about acceptance, it would be nice to have a slide with what they are publishing, as authoritative information from their peers. Arturo said that his presentation was short, but they are fixing all their internal systems to ensure that data in the IRR is correct and that what is in there, is exactly what they want to announce. They are also working on publishing their ROAs. This will happen in the next quarter, along with a lot of other parts that need fixing. Ruediger replied that it would be nice to have a summary at some point. Arturo said that they have also joined MANRS. To show their commitment to fixing this problem and be part of the solution rather than just the problem, they are working with ISOC to make MANRS more successful. Cleaning up and filtering is something Google wants to do and is committed to, and so they are in the process, but it will take some time. Magnus, a remote chat participant, asked if they could open their IRR software. Arturo said they don’t have an IRR software, but they do have some tools that they use to parse the information. Chris Morrow, Arturo’s colleague from Google, replied that he had written some IRR parsing software, available on GitHub, it still needs work, but once finished, it could be used to parse the data and create filters. They will spend more time on that. Randy Bush commented on the slide “How do I peer with AS15169?” He asked if that included the transitive closure. If Randy, a BGP speaker, were not their peer, but a customer of their peer, would they accept his prefix from their peer if his prefix did not have an IRR Object? Arturo replied that they wouldn’t because there wouldn’t be any authorisation in place. Paul Hoogsteder, a remote chat participant, asked if Arturo could explain what is meant with “follow the AS/arrow maintainer”? Arturo replied that in the IRR, you have the maintainer, the AS-SET and the ASN object. They check the ASN object and check if it is an ASN they peer with. But they need to know all the routing information, which is in the AS-SET. So if someone peers with them and doesn’t put the ASN-SET in the ISP.google.com, one of the ways they find the AS-SET that has all the ASNs or all the information related to that ASN is by going to the peering DB to check the ASN-SET. Brian Dickson (GoDaddy) asked if a BGP speaker with their own AS, peering with Google directly and has RPKI but no IRR object or AS path, would Google not accept routes from them? Arturo confirmed that for now, they wouldn’t. He added that NTT has a way to export from RPKI to IRR’s, but they hadn’t decided if they were going to use it. This will be discussed. Brian asked if AS cone were to get formalized and adopted, would they use it? Plus RPKI? Arturo replied that he wasn’t sure you can put AS cone in the RPKI. All they know is that the prefix as an origin. Brian clarified AS cone if it does go into the RPKI. Arturo replied that if that were the case, including AS PA, then maybe they would adopt it. An anonymous remote chat participant asked if they were doing filtering before this, and based on what information? Arturo replied that they didn’t do any filtering, they just had the prefix, the number of prefixes – Chris will answer: Chris Morrow (Google) added that they were doing less filtering, not none. 5. Connect Update Florence Lavroff The presentation is available at: https://ripe78.ripe.net/archives/video/57/ There were no questions or comments. 6. Euro-IX Update Bijal Sanghani, Euro-IX The presentation is available at: https://ripe78.ripe.net/archives/video/58/ There were no questions or comments. 7. IXPDB and Tools Jesse Sowell, The Bush School of Government and Public Service, Texas A&M University The presentation is available at: https://ripe78.ripe.net/archives/video/59/ There were no questions or comments. 8. Offline Discussion There was no discussion 9. Closure
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ connect-wg mailing list [email protected] https://lists.ripe.net/mailman/listinfo/connect-wg
