- connect-wg - mailman.ripe.net

FW: [address-policy-wg] 2019-07 New Policy Proposal (Default assignment size for IXPs)
by Erik Bais 17 Oct '19

17 Oct '19

Dear Connect WG, As co-chair of the Address Policy WG, I would like to inform you at the following AP-WG proposal by Remco van Mook to adjust the default allocation size for IXP space. The discussion will be on a AP-WG mailing list and I would suggest to the Connect WG to provide your experience and input on this idea. This will have an impact on your business/operation .. we need to receive your view and insight. Regards Erik Bais On behalf of the AP-WG Chair collective On 15/10/2019, 14:43, "address-policy-wg on behalf of Marco Schmidt" <address-policy-wg-bounces(a)ripe.net on behalf of mschmidt(a)ripe.net> wrote: Dear colleagues, A new RIPE Policy proposal, 2019-07, "Default assignment size for IXPs" is now available for discussion. This proposal aims to change the default IXP assignment size from a /24 to a needs-based model, with a /27 as a minimum. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2019-07 As per the RIPE Policy Development Process (PDP), the purpose of this four week Discussion Phase is to discuss the proposal and provide feedback to the proposer. At the end of the Discussion Phase, the proposer, with the agreement of the WG Chairs, will decide how to proceed with the proposal. We encourage you to review this proposal and send your comments to <address-policy-wg(a)ripe.net> before 13 November 2019. Regards, Marco Schmidt Policy Officer RIPE NCC

1 0

BEREC consultation: Identification of the network termination point
by Marco Hogewoning 16 Oct '19

16 Oct '19

Dear colleagues, Earlier this week, BEREC (Body of European Regulators for Electronic Communications) announced a public consultation on their draft guidelines for interpreting the “network termination point (NTP)”. These guidelines have been designed in accordance with Article 61(7) of the European Electronic Communications Code to provide national regulatory authorities (NRAs) with guidance on how to interpret the EU directives and implement them in their national legislation. This consultation is open to the public. While the RIPE NCC has no particular position on this topic, we think it is important for the community to consider the impact of these guidelines. They could impact not only our members’ operations, but the RIPE NCC’s engagement strategy on a number of topics such as IPv6 and IoT security. We invite the Connect Working Group to discuss the proposed guidelines and, should it reach a rough consensus as determined by the chairs, the RIPE NCC is willing to submit that opinion as a response on behalf of the RIPE community. As we see pros and cons to either alternative, failure to reach consensus will mean we will not respond to this consultation on behalf of the RIPE community, but would instead encourage individual members to provide their own responses. I’ll provide a brief description of the problem space and the potential impact below, but I recommend reading the draft guidelines as they are posted on the BEREC website: https://berec.europa.eu/eng/document_register/subject_matter/berec/regulato… Please note that while BEREC’s deadline is 21 November, we would need a few days to process and file the formal response and we kindly request the working group to respect close of business on 15 November as its internal deadline to reach consensus. Key Issues One of the key questions laid out in the document is whether or not the CPE or modem is part of the NTP. EU Regulation 2015/2120 states with regard to Internet access services in article 3(1): > “End-users shall have the right to access and distribute information and content, use and provide applications and services, and use terminal equipment of their choice […]” The 2016 BEREC Guidelines on net neutrality rules (paragraphs 26 and 27) provide further guidance on the implementation and state: > “In considering whether end-users may use the terminal equipment of their choice, NRAs should assess whether an ISP provides equipment for its subscribers and restricts the end-users’ ability to replace that equipment with their own equipment, i.e. whether it provides ‘obligatory equipment’. > > Moreover, NRAs should consider whether there is an objective technological necessity for the obligatory equipment to be considered as part of the ISP network. If there is not, and if the choice of terminal equipment is limited, the practice would be in conflict with the Regulation.” Not only is this subject to national definitions and implementations, it also allows for exceptions under “objective technological necessity”. Among other things, the draft guidelines go into a lot of detail with regards to the consequence of the different options that exist. As explained above, the RIPE NCC has no immediate position on which option is the better alternative. However, it could impact our engagement strategy in the longer term. There are roughly two alternative options: the modem or CPE is “obligatory” and as such will be supplied and maintained by the access provider as part of their network, or the end-user is allowed or even required to source their own equipment, which needs to be compatible with the network. The two different options would impact, for example, the RIPE NCC’s focus when it comes to IPv6 adoption. Although we have seen successful deployments under both scenarios, it is either the ISP that is in control and has to make the choice (which of course often means our members are deciding), or we need to somehow create awareness among end-users and engage more with manufacturers, importers and retailers to adopt equipment that supports IPv6. We also imagine that such a choice would impact the scale and, more importantly, the speed of IPv6 adoption. We also expect that if the prevailing choice would be to allow the end-user to select their own equipment, there will be an increased demand for strict standards and profiles to ensure interoperability. While the draft guidelines recognise that the CPE market is both competitive and innovative, we expect these discussions to lean towards additional certification requirements to ensure interoperability. In light of the current discussions about IoT security, especially in household appliances, we also see a big focus on the CPE as providing some security-related services. Several of these systems, such as SPIN and MUD/FUD, have been presented to the community. Again, a more scattered landscape where users select their own devices might make it challenging for these technologies to reach a sustainable level of adoption. More generally, we can expect that greater freedom of choice in selecting devices would come with some additional security challenges, where the increased variety could also lead to an increase in the variety of attack vectors and vulnerabilities. Also, as the CPE would no longer be in the ISP’s domain, we would lose the ability to quickly roll out patches and would instead have to trust the end-user or manufacturer to install updates in a timely fashion. Again, this is something where we would expect further discussion with regards to regulatory measures and (mandatory) certification to ensure minimum requirements are met and to protect the consumer. In either case, we trust the NRAs and the market to make an informed decision on the most appropriate approach and are happy to bring the RIPE community’s opinion forward to this consultation. Regardless of the outcome, we will continue to monitor these discussions and adjust our engagement strategy accordingly, both towards policymakers as well as the various market participants and, where necessary, the end-users. Regards, Marco Hogewoning External Relations, RIPE NCC

3 2

Minutes from RIPE 78
by remco van mook 10 Oct '19

10 Oct '19

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

1 0

Working Group agenda, RIPE 79
by Florence Lavroff 02 Oct '19

02 Oct '19

Dear friends of the Connect WG, RIPE 79 is around the corner. Here is the agenda for our next Working Group session on Wednesday, October 16th from 11:00 to 12:30 : 1 Opening (Welcome, scribe appointment, agenda, proposed session format) 2 Raci #1 - Dismantling Operational Practices of BGP Blackholing at IXPs, Marcin Nawrocki, Freie Universitaet Berlin - 10 min 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 - 10 min 4 IX-API: An API for Automating Interconnection, Thomas King, DECIX - 15 min 5 IPv6 adoption on Internet Exchanges, Susan Forney, Hurricane Electric - 15 min 6 Euro-IX update - Bijal Sanghani, Euro-IX - 3 min 7 Connect update - Florence Lavroff - 3 min 8 Offline discussion 9 Closure See you in Rotterdam ! Best regards, Florence, Remco and Will Connect-WG co-chairs -- Florence Lavroff / lavroff(a)google.com / +31 6 11 01 55 80 Infrastructure Acquisition and Interconnect / Google EMEA

1 0

Call for presentations at RIPE 79
by Will van Gulik 11 Sep '19

11 Sep '19

Dear friends of the Connect WG, We are a bit more than a month away from RIPE 79, that will take place in Rotterdam, the Netherlands, from October 14th to 18th 2019. Our next Connect-WG session is scheduled for Wednesday, October 16th from 11 AMto 12.30 in the main room. If there is any topic you are interested to present during the session, please let us know ! Thanks, Kind regards, Florence, Remco and Will Connect-WG co-chairs

1 0

New on RIPE Labs: History and Impact of IXP Growth
by Mirjam Kuehne 23 Jul '19

23 Jul '19

Dear colleagues, Ignacio Castro, a fellow under the RIPE Academic Coordination Initiative at RIPE 78, wrote this interesting article on RIPE Labs: https://labs.ripe.net/Members/ignacio_castro/shaping-the-internet-history-a… Kind regards, Mirjam Kühne RIPE NCC

1 0

Agenda for Connect-WG @ RIPE 78
by Will van Gulik 01 May '19

01 May '19

Dear friends of the Connect-WG, In a few weeks, we will be in Reykjavik for RIPE 78, and we are looking forward to seeing you all there. The Connect-WG will take place Wednesday, May 22nd from 11am to 12.30am in the Main room. We will keep the same format we used during the last meeting in Amsterdam and have a small non-recorded nor live-streamed open discussion at the end of our session. Here is the agenda for the session : 1 Opening (Welcome, scribe appointment, agenda, proposed session format) 2 The Elusive Internet Flattening: 10 Years of IXP Growth by Ignacio Castro - 15 min 3 RPKI at route servers followup by Nick Hilliard (INEX) - 15 min 4 Google's peer lock implementation by Arturo Servin (Google) - 15 min 5 Connect update by Florence Lavroff - 3 min 6 Euro-IX update by Bijal Sanghani - 3 min 7 Discussion about tools for interconnect professionals - 10 min 8 Offline discussion - 10 min 9 Closure. See you all soon, Best regards, Florence Remco and Will Connect-WG co-chairs

1 0

Call for Presentations European Peering Forum 14 (EPF14)
by Siri Brenden 24 Apr '19

24 Apr '19

Call for Presentations European Peering Forum 14 (EPF14) AMS-IX, DE-CIX, LINX and Netnod are happy to host the 14th European Peering Forum (EPF) in Tallinn, Estonia from the 16th - 18th September 2019. The event will welcome up to 300 peering managers and coordinators from networks connected to the host Internet exchanges.Besides an interesting topical agenda, the three-day event accommodates room for attendees to meet on a one-to-one basis to discuss bilateral peering business opportunities. The programme committee will be looking for presentations and lightning talks related to peering and technical topics of interconnection. Your presentation should address: * Interconnection Automation * Regional Peering * Interconnection / Peering Internet Governance and Regulatory Topics * Economic and Product Trends * Peering / Interconnection strategies * Interesting findings about Peering / Interconnection * 400GE and beyond Submissions =========== Presentations must be of a non-commercial nature. Product or marketing heavy talks are strongly discouraged. Submissions of presentations should be made to the programme committee <epf-pc(a)peering-forum.eu <mailto:epf-pc@peering-forum.eu>>. Please include: * Author's name and e-mail address * Presentation title * Abstract * Slides (if available) * Time requested (max. 30 minutes incl. Q&A) Deadlines ========= Presentation Abstract Deadline 15/07/2019 12:00 UTC Final Selection of Speakers 26/07/2019 Presentation Slides Submission Deadline 02/09/2019 12:00 UTC More information about the event and other activities around EPF14 may be found at: * https://peering-forum.eu/ <https://peering-forum.eu/> * https://www.facebook.com/groups/1486607564933665/ <https://www.facebook.com/groups/1486607564933665/> Warm regards, AMS-IX, DE-CIX, LINX and Netnod

1 0

Connect update + Euro-IX update @ RIPE 78
by Florence Lavroff 23 Apr '19

23 Apr '19

Dear friends of the Connect-WG, As per the previous Connect-WG session, we'll present a Connect update and a Euro-IX update during the Connect WG at RIPE 78. The aim of the Connect update is to list on a single slide connect-relevant news, announcements, interesting publications and videos while the Euro-IX update, presented by Bijal, in copy of this mail, is focused on IXP-relevant updates. Anything you'd like us to mention ? Feel free to let us / Bijal know. Thanks, Best regards, Florence, Remco and Will Connect-WG co-chairs -- Florence Lavroff / lavroff(a)google.com / +31 6 11 01 55 80 Infrastructure Acquisition and Interconnect / Google EMEA

1 0

Input request in regards of IPv4 dust for IXP Pool usage
by Erik Bais 18 Mar '19

18 Mar '19

Dear Connect-WG, As we have been missing some of you during the RIPE77 Address Policy WG discussion, I would like to invite you to have a look in the archive of the Agenda topic of Andrea Cima of the RIPE NCC. https://ripe77.ripe.net/archives/video/2232/ ( Andrea Cima - D. IPv4 End-Game and Afterlife ) As the collective of AP-WG Chairs and the RIPE NCC, we would like some more insight from the Connect community what to do with the IPv4 dust that the RIPE NCC has in the current IPv4 pool (at the bottom.) We received some conflicting views in AP-WG during the meeting and it would be nice to get more voices than just the two in the room. There are 3 options what we might be able to do with the last scraps of IPv4 space .. ( mostly smaller than a /24 prefixes ) that are regarded as left-overs or dust as we call them. Option 1 : hand them to the last one who might come along .. The LIR that will receive them, will not be happy or get any usable routable space .. ( So this might not be a good option .. ) Option 2 : put it in the temp. pool. That is used for temporary events or research options. Option 3 : Put it in the IXP pool .. in case someone doesn't want their IXP lan to be routable on the DFZ anyway .. they might also have enough if they receive a /27 for their 10 member IXP LAN. Especially the Option 3 is what we like to hear some more discussion on .. especially from the Connect WG members.. There might be 2 views, if an IXP lan should be routable or not ??? And what is the view of the Connect community on the topics .. so that we can take that as input moving along .. It would be nice if we can some discussion on this either here ( the Connect WG ML) or on the AP-WG ML. but as all the IXP experts should be here .. both Gert and myself are happy to take the input from here to the AP-WG ML. As long as we receive your input and views. Kind regards, Erik Bais & Gert Döring Address Policy WG Chairs

2 1

Presentation for RIPE 78
by Ignacio Castro 14 Mar '19

14 Mar '19

Dear Connect Working Group, I am a RACI attendee to RIPE 78 and was wondering whether my talk would be a good fit for the WG, as suggested by the PC. The original slides that I submitted can be found here: https://www.dropbox.com/s/fimwp4e1wilb5t2/2019-02_RACI_IXP-history.pptx?dl=0 A draft of the ongoing work is also available here: https://arxiv.org/abs/1810.10963 Thank you! Ignacio Castro -----Original Message----- From: php-fpm <php-fpm(a)ripe.net> On Behalf Of RIPE 78 Programme Committee Sent: 14 March 2019 15:59 To: Ignacio Castro <i.castro(a)qmul.ac.uk> Cc: pc(a)ripe.net Subject: Presentation rejected for RIPE 78 Dear Ignacio Castro, We regret to inform you that your talk submission for RIPE 78 titled '10 Years of IXP Growth and its impact on end-to-end paths (RACI)' has not been accepted into the Plenary session. We had a tough competition for the few remaining slots and in the end another proposal won the PC's preference. The PC would suggest you reach out to the Connect-WG. The WG Chairs can be reached at connect-wg(a)ripe.net. Looking forward to your submissions for future meetings. Thank you, Maria Isabel Gandia Carriedo on behalf of the RIPE Programme Committee

1 0

[connect-wg] Call for presentations at RIPE 78
by Florence Lavroff 06 Mar '19

06 Mar '19

Dear friends of the Connect WG, RIPE 78 will take place in Reykjavík, Iceland, from May 20th to 24th 2019. Our next Connect-WG session is scheduled for Wednesday, May 22nd from 11 AM to 12.30 in the main room. If there is any topic you are interested to present during the session, please let us know ! Thanks, Kind regards, Florence, Remco and Will Connect-WG co-chairs -- Florence Lavroff / lavroff(a)google.com / +31 6 11 01 55 80 Peering and Content Distribution / Google EMEA

1 0

Call for Presentations GPF 14.0
by Nina Bargisen 02 Jan '19

02 Jan '19

Happy New Year! We are pleased to announce that Call for Presentations for GPF 14.0 is open today. On behalf of the GPF board, we are honored to present the following GPF 14.0 Program Committee members: Yan Berthier <https://www.facebook.com/ynbrt?fref=gs&__tn__=%2CdK-R-R&eid=ARATTWHxGqAuj6t…> - Chair, Nina Bargisen <https://www.facebook.com/nihbster?fref=gs&__tn__=%2CdK-R-R&eid=ARBLrj2xl2LV…> - Vice Chair, Darwin Santinho Da Costa <https://www.facebook.com/darwin.dacosta?fref=gs&__tn__=%2CdK-R-R&eid=ARCME_…> , Viliyana Ivanova <https://www.facebook.com/viliyana.ivanova.3?fref=gs&__tn__=%2CdK-R-R&eid=AR…> , Nicole Kangas <https://www.facebook.com/nicole.kangas.5?fref=gs&__tn__=%2CdK-R-R&eid=ARAfx…> , Gaurab Raj Upadhaya <https://www.facebook.com/gaurabu?fref=gs&__tn__=%2CdK-R-R&eid=ARARvyIULkpQd…> and Joe Wooller <https://www.facebook.com/joe.wooller.5?fref=gs&__tn__=%2CdK-R-R&eid=ARDgF4N…> . For more information about presenting a topic, creating or participating in a panel or any other suggestion related to interconnection, please refer to https://www.peeringforum.com/call-for-presentations/ <https://www.peeringforum.com/call-for-presentations/?fbclid=IwAR2rxBXBsLb1R…> and send your proposals (title and abstract) to pc(a)peeringforum.com. For the GPF 14.0 Program Committee Nina

1 0

New on RIPE Labs: Uncovering Remote Peering at IXPs
by Mirjam Kuehne 12 Dec '18

12 Dec '18

Dear colleagues, Ever-increasing traffic volumes create pressure for denser and more diverse peering that challenges the traditional IXP model. A fundamental shift in peering practices is Remote Peering (RP). The authors developed and tested a methodology based on RIPE Atlas to accurately identify RP, aiming to enable a more transparent peering ecosystem.: https://labs.ripe.net/Members/vgiotsas/uncovering-remote-peering-at-interne… Kind regards, Mirjam Kühne RIPE NCC

1 0

Re: [connect-wg] Connect update @ RIPE 77
by Walter Marshall 03 Dec '18

03 Dec '18

Maximize success in SMS marketing can be achieved using the necessary applications and software. Personally, I would recommend this service Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

1 0

New on RIPE Labs: OpenBGPD - Adding Diversity to the Route Server Landscape
by Mirjam Kuehne 28 Nov '18

28 Nov '18

Dear colleagues, In this new RIPE Labs article Claudio Jeker and Job Snijders describe how they revived the OpenBGPD daemon to bring more diversity to the Route Server landscape. https://labs.ripe.net/Members/claudio_jeker/openbgpd-adding-diversity-to-ro… This project was funded by the RIPE NCC Community Project Fund. Kind regards, Mirjam Kühne RIPE NCC

1 0

Topic in AP-WG today: IXP Pool
by Erik Bais 17 Oct '18

17 Oct '18

Dear WG, As a heads up, in the first AP session today Andrea Cima from the RIPE NCC will bring up the topic what to do with the IXP Pool size. Please be present if you like to hear or discuss about it in the side room. Regards, Erik & Gert AP-WG chairs

1 0

Agenda for Connect-WG @ RIPE 77
by Will van Gulik 17 Oct '18

17 Oct '18

Dear friends of the Connect-WG, RIPE 77 is coming and are looking forward to seeing you all in Amsterdam. The Connect-WG will take place Wednesday, October 17th from 11am to 12.30am in the Main room. Following up on feedback from last meeting, we are bringing about a change in the usual format of the session : we have scheduled some open discussion time (25 min) at the end of the session. This open discussion time won't be recorded / live-streamed to foster participation : we want to ensure we won't miss meaningful comments withheld due to the fear of being recorded. We also encourage you to use our dedicated chat channels to ask questions remotely / anonymously. Here is the agenda for the session : 1 Opening (Welcome, scribe appointment, agenda, proposed session format) 2 Uncovering Remote Peering Interconnections at IXPs - George Nomikos - 20 min 3 MANRS IXP Programme - follow up - Andy Davidson - 15 min 4 Tbc (still in discussion) - 10 min 5 Connect update - Florence Lavroff - 5 min 6 Open discussion time - 25 min (not recorded) 7 Closure See you all soon, Kind regards, Florence, Remco and Will Connect-WG co-chairs

2 1

Connect update @ RIPE 77
by Florence Lavroff 04 Oct '18

04 Oct '18

Dear friends of the Connect-WG, As per the previous Connect-WG sessions, we'll present a Connect update during the Connect WG at RIPE 77. The aim of the Connect update is to list on a single slide connect-relevant news, announcements as well as interesting publications and videos. If there is anything you would like to share, feel free to let us know. Thanks, Best regards, Florence, Remco and Will Connect-WG co-chairs -- Florence Lavroff / lavroff(a)google.com / +31 6 11 01 55 80 Peering and Content Distribution / Google EMEA

1 0

Call for presentations at Ripe 77
by Will van Gulik 11 Sep '18

11 Sep '18

Dear friends of the Connect-WG, In a bit more than a month, we will be at Ripe 77. Our next Connect-WG session will take place on the Wednesday, October 17th in Amsterdam. If there is a topic you would like to present during the session, please contact us at connect-wg-chairs(a)ripe.net , we still have a few slots free in the agenda. Looking forward to hearing from you ! Kind regards, Florence, Remco and Will Connect-WG co-chairs

1 0

Connect update @ RIPE 76
by Florence Lavroff 10 May '18

10 May '18

Dear friends of the Connect-WG, RIPE 76 is almost there ! As per RIPE 75 <https://ripe75.ripe.net/presentations/51-Connect-update.pdf>, we'll prepare a Connect update slide listing connect-relevant news, interesting reads + videos ... Here is what we have so far : - Netflix Content distribution and how ISP can control traffic flows from Netflix <https://www.peeringforum.com/pastEvents/gpf13.0/Thu_6_NinaBargisen_GPF-Netf…> Nina Bargisen, Netflix - Pivo: LinkedIn Peering Tool <https://www.peeringforum.com/gpf-13-pivo-linkedin-peering-tool/> Marijana Novakovic, LinkedIn - Route Server Security and the Role of IXPs <https://www.peeringforum.com/gpf-13-route-server-security/> Job Snijders, NTT Communications - Does The Internet Route Around Damage in 2018? <https://labs.ripe.net/Members/emileaben/does-the-internet-route-around-dama…> Emile Aben, Contributors: Stephen Strowes - DE-CIX Frankfurt's announcement : peering LAN netmask change from /22 to /21 If there is anything else you would like to see on this slide, feel free to let us know. Thanks, Best regards, Florence -- Florence Lavroff / lavroff(a)google.com / +31 6 11 01 55 80 Peering and Content Distribution / Google EMEA

1 0

Agenda for Connect-WG @ RIPE 76
by Florence Lavroff 01 May '18

01 May '18

Dear friends of the Connect-WG, RIPE 76 is around the corner and we are looking forward to seeing you all in Marseilles ! The Connect-WG will take place on Wednesday, May 16th from 11 AM to 12.30 in the main room. Here is the agenda for the session : 1 Welcome + Scribe appointment 2 WG group chairs selection process - Remco van Mook 3 Managing customer insights on a Distributed Exchange - Jerry Grondel, NL-IX (15 min) 4 MANRS IXP Programme - making the Internet more secure - Andrei Robachevsky (10 min) 5 IXPDB - Bijal Sanghani, Euro-IX (10 min) 6 Dynam-IX: a Dynamic Interconnection eXchange - Marco Chiesa (15 min) 7 Connect update - Florence Lavroff 8 Feedback about the session - Remco van Mook 9 Closure See you all soon, Kind regards, Florence and Remco Connect-WG co-chairs -- Florence Lavroff / lavroff(a)google.com / +31 6 11 01 55 80 Peering and Content Distribution / Google EMEA

1 0

RIPE Labs: Does the Internet route around damage (2018 edition)
by Emile Aben 11 Apr '18

11 Apr '18

Dear colleagues, we looked into the measurement data about the outage that DE-CIX Frankfurt experienced on the night of 9 April 2018. As this is one of the largest Internet Exchange Points, this is an interesting case to study in more depth to see what we can learn about Internet robustness: https://labs.ripe.net/Members/emileaben/does-the-internet-route-around-dama… Please let us know if you have any feedback. Regards, Emile Aben RIPE NCC

1 0

DMARC Solution Applied to this Mailing List
by Adam Castle 18 Dec '17

18 Dec '17

Dear Working Group, As more email providers enable Domain Message Authentication Reporting & Conformance (DMARC), some people find they can no longer receive emails from the mailing lists they are subscribed to. We have deployed a Mailman setting change to address this problem. After consultation with the RIPE Working Group Chairs, we have enabled the DMARC "Munge From" setting on all RIPE mailing lists. This means that if your email service provider has DMARC enabled, you will continue to receive all emails sent to this mailing list, but the "From" part of the header will change. If you don't have DMARC enabled, you won't see any change to the emails you receive from this mailing list. You can find more information about how we have been handling DMARC in the following RIPE Labs articles: https://labs.ripe.net/Members/adam_castle/dmarc-and-the-ripe-ncc https://labs.ripe.net/Members/adam_castle/ripe-mailing-lists-and-dmarc To ensure all working group participants are aware of the changes, I am sending this mail to all working groups. If you have any questions or encounter any issues on this mailing list, please let me know. Many thanks. Adam Castle Web Services Manager RIPE NCC

1 0

Call for nominations
by remco van mook 26 Oct '17

26 Oct '17

Dear friends of connect-wg, as promised during the session earlier this week, we’ve now reached the point where we need to look at who runs this working group again. If you’re interested, please express your interest on this list before November 8, either on this list or to the chairs at connect-wg-chairs(a)ripe.net <mailto:connect-wg-chairs@ripe.net> Here is the timeline: • October 25 - Call for nominations • November 8 - Announcing the list of candidates • November 8-21 - Discussion phase • November 22 - Decision by current WG chairs As already mentioned during the session, both Florence and me are happy to continue in our roles as co-chairs, if the working group agrees. Kind regards. Remco (and Florence)

1 0