RIPE 90
RIPE Community Plenary
Main room
15 May 2025
4 p.m.
MIRJAM KUHNE: We are ready to start. We have a packed agenda. Just to ‑‑ a few announcements at the beginning. The PC elections, the elections for the RIPE Programme Committee will close today at 5 o'clock, which is ‑‑ so you still have an hour. It's after the Community Plenary, so I'm making the announcement before so you still have time to vote. The link is on the main website of the RIPE 90 meeting pages, so you can find it there.
I also want to make more announcements now because otherwise I might forget at the end. We have actually found an Apple watch already earlier this week, if you miss one, it's at the registration desk, You can pick it up there. I think they already found it on Monday. Maybe that person has left by now, I am not sure.
Then I have very sad news that is tomorrow morning there won't be a Barista. I am dreading making this announcement, you are being to rip my head off. Because there was some miscommunication with the supplier, unfortunately they won't be available tomorrow morning. There is a cafe around the corner, I think if you come out of the hotel to the left, workplace cafe, they are open in the morning. And the good news is we are only start at 9:30, so you have a bit of time to try to find a coffee. Of course there will be the coffee break in the hotel coffee will be available as well. It's just ‑‑ so stack up on Barista this evening if you still need them because they are not here tomorrow.
Then for the RIPE dinner tonight, for those of you who have tickets for the RIPE dinner, the buses will be leaving the hotel at the entrance of the hotel at twenty past seven and 7:30. They will return every 30 minutes starting from 10:30 till one o'clock. That's the last bus. So that was all the announcements from my side. I hope to see many of you at the dinner tonight.
Then let's start with the programme, the agenda. We have a packed agenda. So I'll give you a quick update from the RIPE Chair team. Niall is here, I saw him coming in. Then we'll have a report from Herve, the Chair of the NRO numbers Council to wrap up the feedback that they received during the week here on the new RIR governance document.
There will be a short update from the RIPE Nominating Committee, where they are with the nomination process for the next RIPE Chair team. And then there will be actually a technical talk in amongst all this administrative updates, about the next generation of BGP collection platforms, Thomas is going to present that. I think you are here. I hope you are here.
At the end we'll have a presentation by Philip Oldham the RIPE NCC web services manager about the new and exciting new RIPE meeting website that you can expect. Then hopefully, maybe we'll have sometime for AOB and Open Mic at the end. I am going to speed up.
Just a few updates from our side, what we have been doing since the last time.
If you follow our updates on RIPE Labs, we try to keep you up to date of what we are working on and what we're hanging out what kind of event we are attending and what we are focusing on. Since last time, we have published the document, the right document that we have all been working on, and we declare consensus earlier on the relationship between the document that describes the relationship between RIPE and the RIPE NCC, so that's been published as RIPE 838. Then we have also been working, together with the RIPE NCC, mostly the Policy Officer, to review the whole policy portfolio, and if you were at the Address Policy Working Group you heard Angela talk about this. There are so many policy documents, there are some that maybe can be consolidated, there are some low‑hanging fruit where we can start making it easier for people to find the right information in the whole policy forest that we have in this region. And we continue to work with her on this and there might be a little task force formed to help her. Are. We also continue to work at the RIPE document store, that's my project to make things are consistent in there, we have didn't metadata. We know what documents are public and up to date and which ones are obsolete, to make sure that we can find things properly in the document store, because that's really our bread and butter, our production, if you will, our output for this community is our documents.
We have also continue to promote RIPE and specifically to newcomers, we have heard maybe in the diversity session earlier this week, we are reviewing the whole mentorship and fellowship programme, together with the RIPE NCC, and also with the community obviously with a mentor, we want to beef that up, make sure it's easier to find when you register for the website, if you need a mentor, if you want to become a mentor and help newcomers, mentees.
Also, the RIPE NCC this time, we didn't have an online student session, instead the RIPE NCC actually visited some universities here in Portugal before the meeting and promoted the RIPE community and the fact that we're coming to town here and I think it was quite successful, I believe some of those students are actually at the meeting and you see there a picture of some of the fellows and the RACI fellows that are here during this meeting.
Then also in our various meetings to ‑‑ not represent, but to make sure we know what's going on in the IETF and we are at the regional meetings, operators groups meetings, Niall's attend some exchange point meetings, I am going to the ICANN meeting, IEGF just to make sure we know what's going on and to update you about it as well.
I'll be coming back to ongoing policy discussions. There are three policies currently, I want to make sure you are all aware of this, there are currently three policies in the Address Policy Working Group, all of them are still under discussion phase, so you can still participate, provide feedback. What's not on the slide because it's not actually published yet, there is also an initiative in the Routing Working Group, there was a discussion about the non‑functional delegated RPKI CA, so there is an initiative to clean that up, by Job Snijders, that will turn into a policy proposal fairly soon I think. So that's also ongoing.
.
And then also a community activities. Obviously there is a policy discussion also communities, they are not like made by Niall or myself. There was a discussion also in the diversity session helping the RIPE NCC events team to make sure we have all the accessibility, you know, a good view on accessibility issues, and it was decided this time that maybe setting up a team or advisory group was a bit too heavy handed, but we are going to work maybe on a checklist on how the RIPE NCC to make sure we have ‑‑ we are aware of various accessibility issues that people might have, so we can inform you before each meeting, you know, if there are any issues at the venue.
RIPE NomCom will have their own presentation, so that's still ongoing. The same for ICP‑2 and the RIR draft document available they are going to present about that.
Then one thing I want to mention, I want to mention this because the BoF today is kind of a follow‑up of the BoF of the task force did produce a recommendations document for DNS resolver operators and this one is going to look at authority any of name servers and possibly having a BCP about that as well.
That's about it, just a pointer here to the updates, monthly updates that Niall and I provide you on the RIPE Labs platform, if you want to follow what we are up to so you can of course provide us feedback and add comments and questions.
That was that. Are there any questions, comments?
.
Is there anything online? No, NOG. All right, well then in that case, I would like to ask the next speaker, Herve, to give us an update or wrap up all the feedback that you have heard during the week about this document.
HERVE CLEMENT: Thank you Mirjam. Good afternoon everyone. So, one more time, us, one more time this week me about this ICP‑2. So be sure it won't be another presentation of the ICP‑2, what it is etc., etc., so we know.
But we will report the different outputs we heard from you about the community during the BoF and during the policy Working Group as well as and to collect that in an efficient way and very quickly we had the support from the RIPE NCC staff and specifically Ulka was there to help to prepare this presentation.
Quick recap of what happened in terms of presentations on information we shared about ICP‑2.
It's an ongoing consultation for the communities of the region and for the ICANN on the consultation of this draft, which is called now but it's not a definitive name, "RIR Governance Document" opened 14 April and will close on Tuesday 27 May, not this Tuesday, next Tuesday. There was a RIPE NCC Open House on 29 April, probably few or some of you have attended that. There were also a BoF this week, on Monday, and it was organised to air your feedback and it was very interesting feedback. We also, as I said, presented a document during the policy Working Group as, because there is OS EC report generally during the policy Working Group, it was yesterday, and so what are we doing there? Again so to present the outputs of what you said.
What we heard during this meeting, RIPE 90.
There was feedback on the language and the tone of the document that was produced. There were concerns about the level of detail and preliminaries as well. And larger philosophical approach to this topic. Many remarks and many to be honest very interesting remarks, and I will go in further detail about that.
.
About the document structure and language. So you had some ideas and remarks.
The document we have produced so far needs to have goals. And if you see the frame of the document, it reads more like a contract. And it's not very apparently very imagine news, because it various between high level principles and mechanics at a more operational level. So it's a thing probably to balance about. The language in the document could be inconsistent. You have musts, you have shoulds, and could be perhaps softened and some parts should be more precise, for example the term of "Geographic" area which seems to be vague.
The prescriptive tone contradict the community driven nature of the RIRs. When you see the document it's like to see as we say very prescriptive apparently, which is not finally the nature of the the community.
But for this aspect.
Decision‑making concerns, because in the document there is a decision to do regarding recognition or de‑recognition. The opinions on anonymity are not unanimous, so we have to take that into account.
Several of you suggested using majority based models. So instead of anonymity.
The current model assumes good faith by all parties, and this assumption of acting in good faith is being questioned currently.
And there needs to be better clarity on decision making criteria, for example which criteria should apply to each decision point on that something more that is not very clear.
There are different regions, so there is a question about the applicability of the document across the region also. They are currently, and there will be of course, regional differences or the regional are not the same, and we need to consider basic set of documents to all registry, but only a basic set, ought to be recognised as a registry. And there was recently discussion for example of whether a natural person can be a member, apparently, I say apparently, but it's a fact, that there are differences.
One more time, prescriptive language could lead to a casual reader to assume that there are new obligations being imposed from outside the regional bottom up community driven process. Okay, if you read the document, because we have not all the same culture, the same business, the same profession, and if this impression is given, there is something to do to smooth that.
Be challenging to reconcile the historic view of the community grounding with the language of the document.
It's ‑‑ it could be a simple ‑‑ perhaps the document is too legal form or something.
The implementation.
With all the decision that I dealt with the document, business continuity plans are important, and details like escrow are less so.
Also, in case of the recognition and modification, how would an handover one RIR to another from one RIR to another work? For example, whose policies will apply? How will policy differences be addressed? Who will actually take charge of that? So there are some elements which were requested. What are the decision‑making thresholds? How will we gauge support? How is impact measured? There are a lot of aspects, details, but not details that are to be considered also.
Finally, where specific points on specific familiar points dealt with you. The big picture regarding the comment.
Will finally the document need to reflect on safeguard the values of the RIR communities, the stability, the stewardship, the fairness, community, bottom up aspect, they must be inclusive and representative, and we think it's important as well.
The role and relationship between the RIRs, the NRO and the ICANN needs to be clarified also.
And we have to be clear about what it is that we want from this document.
One more time: Thank you for all your remarks. We are particularly impressed by the, by all these remarks, the interesting remarks, the useful ones, and the fact that it's a document that is most interesting for you and you have read it very carefully. So one more time thank you.
What next?
.
We will take your feedback to the NRO NC, because here we are only concerned for the RIPE NCC Services region, and Nick for the APNIC, also, that we are twelve currently. We will, as we did for the last consultation, summarise, cluster and categorise the feedback. And the NRO NC will meet during the next ICANN 83 will take place in Prague between 9 and 12 June, which is next month. We will discuss the feedback, we will discuss your concern and we will work on the second draft from that.
And the aim is to share the second draft ahead of the RIR meetings in the latter half of the year.
It was now timeline you perfectly know, Hans Petter shared it also. We are still on the stage of the public event of the draft. You have still the link to the specific draft. If by chance a few of you have not read it.
And guidance for the feedback. So, if you give feedback, please share feedback that is specific to this draft. And not for anything else. And we are particularly interested in hearing your views on the new requirements in the draft, because there are new things of course.
Whether the draft provides sufficient clarity regarding the ongoing applications of an RIR and the remediation steps if the obligations are not met. So we want your view about this.
This document does not address the implementation of the RIR criteria: Comments on implementation will be considered out of scope. So it give one of the goals. And of course, we appreciate constructive comments.
The consultation will close next Thursday, 27th then that's a summary on what I said regarding the next steps afterwards.
Just to say before ‑‑ yeah, in Q4, 2025, there will be a final review and revision of the updated document, and it will be the start of the NRO and the ICANN approval and the adoption process. And with that, one more time, I thank you too.
(Applause)
MIRJAM KUHNE: Thank you Herve, are there any questions? We have a few minutes.
AUDIENCE SPEAKER: Remco, speaking on a very personal title. Thank you to, first of all, to you and the NRO NC for embarking on this large and thankless project. It is a huge body of work and you are giving it your all and it's very highly appreciated. I have one concern which is, you are writing a lovely new document, we have a lot of new important things in there, which all should be in there. But we're not doing a greenfield. This is ‑‑ we have an existing environment where this document will have to end up in, and with my personal hat very firmly pulled over my ears, and I think called fiduciary duty comes in, and that particularly relates to topics of consensus between RIRs, and, you know, things like that, and it is very important for the community and the work ‑‑ and the further documentation that we need to end up with a document that the boards of the RIRs, which is where this will end up, will be able to sign off on in line with their fiduciary duties as Board members of those organisations. And that's what I'd like to comment. Thank you.
MIRJAM KUHNE: I don't see any other questions, comments, anything ‑‑ oh there is one there.
AUDIENCE SPEAKER: Obviously I'd like to make a comment and to be noted the comments of number probability as well as the recognition of the members, which is very, very important to the continuing existing of the RIR system. As my not to ‑‑ not talk as Alex noted, the law firm has noted the potential antitrust investigation into the RIPE's behaviour and abuse of member rights, that is not a situation to be in and that is not a situation to need to be in, because RIPE can simply get out of it by recognising the member rights officially, the rights of the members mostly already recognise are, various policy documents as well as a corporate document of the RIPE anyway. And we just need to make them contractual and it would be great that such enforcement of member rights such as IP ownership or rights to the registration or number probability being recognised in ICP‑2 for next 20 years of the system stability, because the current model which the IRR holds absolute power and ownership to the database while the databases already have over 200 billion dollars in market value is just dangerous and unprepared for when it was first designed 20 years ago.
So, I urge the ASO AC to take a serious consideration and a look at all perspective, not just from the perspective of, you know, there is accreditation, and decreditation problem because ones I happen to support, but take it from a much serious point of view and adopt the governance change for the next 25 years ahead. And the problem is highlighted in writing in the RIPE list and that antitrust matter should be taken seriously into this ICP‑2 revision, that is my feedback. And I'm specifically stating the inaudible bit. It is related specifically to RIPE NCC because that's the RIR operated in this region and under the European law, but this is also a feedback to the ICP‑2 and please take a note of it. Thank you very much.
HERVE CLEMENT: Thank you. The I don't meant possibility because it was not mentioned during the BoF and during the policy Working Group but I know it was mentioned in another forum. It's not problematic. And we do take it seriously every topic. Thank you.
MIRJAM KUHNE: I just want to clarify, I just want to close the mics, thank you for your infinity. We had a feedback session, we had a BoF session and there is still feedback till 27th May, we don't really have a lot of time to engage and discuss this again you and I accept those two questions of course.
AUDIENCE SPEAKER: Tobias. I would like to remind the room that this discussion we have about value placed on databases stems from an artificial shortage of IPv4 resources. This whole discussion could be alleviated just migrating to IPv6 already, so please... everyone do that and keep in mind that anyone in good faith wanting to make this world a better place in this context will ask for an IPv6 flag day and not for any other approach to solving this problem. Thank you.
HERVE CLEMENT: Thank you for your remark.
AUDIENCE SPEAKER: Pedro. I have a question on chat from Nurani. My question is not directly that ASO AC but to the RIPE NCC and the other RIRs. So right now AFRINIC is under receivership and they have put all their IP allocation on hold which means that no new members can get IP resources in Africa, it's a rather grave situation. Are the RIRs doing anything to try to solve this blockage and finding other ways of providing our services to African networks? There a work around in motion or can anything be done to provide African networks with addresses during this time?
HERVE CLEMENT: I will perhaps leave the answer.
MIRJAM KUHNE: I don't think we can answer this right now. We will note that and pass it onto the RIPE NCC to consider. Thank you.
Right, next up on stage ‑‑ thanks for the update, this really gave a good summary of what, you know, people raised during the BoF and during the week, so thanks for preparing that summary. Next up is Jan Zorz the Chair of the RIPE Nominating Committee 2025. Is it not nominating committee? Anyway...
JAN ZORZ: Hello. I am Jan Zorz, the Chair of the NomCom, and would like to give you a brief update about how things are going.
So, as you may be aware of, the RIPE community will choose its next Chair and Vice‑Chair by the way of a Nominating Committee, that is a group of people that is basically randomly selected from a pool and here at this point I would like to mention that there were, there was feedback from the community about the diversity of the NomCom, of the voting members. I would like to remind you that we asked for volunteers, we got 52 volunteers in the list that was not very diverse from the start, and then there is random selection mechanism that the randomness is actually selected by three different lotteries on a specific date that we put in and re‑ordered the list of the volunteers. So, it's completely, completely random. So, we got this feedback and I would like to remind that you this is completely random process, and by random, it was selected non‑very diversely.
Going forward, there is ten people that are voting members, and we have some non‑voting liaisons and advisers that forms the NomCom, so, the liaisons are from the Working Group collective, from the Programme Committee, then we have liaison from the Board that is actually observer of the validity if we follow the process correctly, and the adviser that is actually the previous NomCom Chair.
So, these are the nominees for the RIPE Chair. This is Fergus and Mirjam.
Then we have for the Vice‑Chair, we have three nominees, Olena Kushnir, Anna Wilson and Rob Evans. The order is by the timeline when they were nominated. So it's how they were nominated in time.
Hall ways: This is the important place for the discussion. All the NomCom members are in Lisbon here. You are welcome to chat to us in the hallways. We we didn't have the special badge so we just wrote NomCom on our badge, so if you have any feedback or suggestion and you see the NomCom person going around, please talk to us. And we are around the majority of the time. We have office hours on the first floor, we have a room, this is next to the children day care. And we have the open office hours from 1:15 to to 2 p.m. everyday, so today is already gone but tomorrow we will still be there and if you have any feedback, suggestion, please stop by, come in and have a chat with us.
Confidentiality:
If you come to our office, we usually close the door and whatever is said in that room is confidential, we treat it confidentially, and it is ‑‑ it needs to be confidential from both parts, from us and from you if you want. This is how our office looks at from the hot Chair perspective. We are trying to make it assay accommodating as possible. And we have coffee.
So far we got a lot of feedback directly during the open office hours, there were people coming in and also the nominees came to talk to the NomCom. Thank you all for providing feedback. It is very, very useful for the whole process. Because we need to understand what the community thinks. Due to my demand during open office hours, we limited the time per visitor to ten minutes, and again, please talk to us. Tomorrow we'll be there during the lunch time, and if you want to read moron there are already published minutes from the first and second official meeting of the NomCom, the RIPE NomCom.org or you can send us an e‑mail.
And with that, are there any possible questions in that's the template. It is what it is. I tried to fix it.
AUDIENCE SPEAKER: Brian Nisbet. So, I think half blaming the community for the lack of diversity of the NomCom is similar to blaming users for clicking the wrong analytic on ISPs we badly designed. I think that what we didn't do the last time I understand why not, we didn't really kind of review and look at the process and I think what we need to do as a community, and whomever the right people to commit and I am happy to volunteer to work on this, is to make sure we don't get to five years down the road when we say: Oh we have started this process again and we haven't changed it and I think there are absolutely ways in which a process can be designed which can support a diverse NomCom which I think is absolutely vital. So, I am willing to volunteer to help work on that as well, but I think we just need to commit as a community that we will do that.
JAN ZORZ: One way of doing this is there will be a NomCom report with the suggestions, and advice for the next NomCom, and this can create a community discussion because fundamentally this needs to be changed in a policy, in a process, but yeah, I think we need to work on that. Thank you.
AUDIENCE SPEAKER: Leo. Someone approached me earlier on and asked about voting in the NomCom elections, and I explained the situation. I think there's been a gap in communication about how the process works and that might also feed into the lack of diversity in the people who put themselves forward for the NomCom. And so, I think for the rest of the process, you might want to read up all communications so that you are getting as much feedback as you can from people who can't be here. And you might want to think more carefully about the communication process for when we do this again next time.
JAN ZORZ: Okay. Well we had the extensive explanation last time in Prague and at the Opening Plenary, but yeah, thank you.
AUDIENCE SPEAKER: Daniel: I am not in the blame game. But I got that feedback also. Like why this undiverse NomCom? And also, like, where do I put myself forward? So I think there is some truth to what Leo says. On the other hand, if ‑‑ I cannot let that stand as it is, because as Jan has said there has been extensive communication over the last few meetings on how this works. There is a blog. We communicated ourselves silly, and we also canvassed for volunteers, especially when we saw the first 30 or so come in very undiverse, I personally went out and asked many people to increase the diversity of the FR Group, and frankly, the willingness of people to come forward for this work was less than stellar, and then afterwards, being blamed for this I take very personally. Thank you.
NIALL O'REILLY: Not quite outgoing right Vice‑Chair, so, not in the sense of this is not my problem but following up on what Brian had to say, I think it would probably be an early item on the agenda of the new RIPE Chair team. That's what I expect as a member of the community, and what I would also expect if I were in a position to be selected as the Vice‑Chair again, which I'm not.
JAN ZORZ: Thank you very much, that's a good suggestion. Don't get me wrong, the RIPE NomCom process is ‑‑ it's a lot of work, not just for me and Daniel but from all the members of the NomCom, so before I go, whoever from the NomCom is here, can you please stand up so that people can see you. If you have suggestions, talk to these people that are standing right now. And if there are no more questions, this is all from me. Thank you very much.
(Applause)
MIRJAM KUHNE: Thank you Jan. Thanks for running this process. Next up we have Thomas from the University of Strasbourg talking about the next generation of BGP data collection platforms and they actually have a call to action from the community and want the community to participate. That's why we felt it was appropriate to have it in the Community Plenary.
THOMAS HOLTERBACH: This is going to be a tech will presentation. I am going to talk about BGP data collection.
So, I am sure many of you know RIPE RIS, PCH, BGP data collection platforms and they are extremely useful for the community. So they collect BGP data and they share it with the community so we can do monitoring tools by CAIDA, like BGPlay and there are even many commercial tools that rely on this data.
So, the routers that share the data of threes platforms they are like satellites, each of them which we call something point has a partial view of Internet routing it's when we combine all these routers together that we can have a large view of our Internet routing.
.
So, today I am here to introduce to you a new BGP data collection platform that is called bgproutes.ie. It's a new platform because we actually just launched our new website three days ago, I cross my fingers that everything is going to be okay. And we are also say it's a next generation platform because we don't just try to improve the collection of the data but we try to improve the entire pipeline from collecting the data to storing it and distributing it to the users, that is what I am going to show you today.
But before I start, you may wonder why did we decide to implement and build a new BGP data collection platform if there are already RIPE RIS, RIPEs that exist and they seem to work fine.
So, this is why I would like to start with this presentation today. 1.2 percent, what is this percentage? This is actually the percentage of ASes that share the BGP data with RIS and routviews. We also say this is the coverage, and we were surprised to see that this is a rather low number. Especially given that RIS and routviews, they always try to deploy new vantage points. So we also measure, you know, how this number evolved over time, and we found that actually it did not increase. So, it's now like two decades that we have only about 1% of the autonomous system that share their data. This is a bit worrisome because as I said those routers, they are like satellite, okay, so we need as many of them to be able to see everything in the Internet routing.
So, now what can we expect in the future here? Can you expect a better coverage? Well, unfortunately not any time soon, because, you know, recent routviews they are extremely useful platforms, they are fantastic because they take data and they keep is forever and it's extremely useful for the community. The problem though is they have to deal with a lot, lot of data. So there is this trade‑off between coverage and data management costs, and basically recently RIPE RIS and routviews they switch from an open ring policy to a set ring policy, means that they are sacrificing coverage to reduce the data management cost. And this is fine at some point they have to take a decision like that. But that might be also an issue regarding coverage.
So of course, you may wonder perhaps well maybe 1.2% coverage is fine because after all a BGP router, there is the X paths, there are the community values. So we can see things a bit remotely right, we can see path changes for instance. So perhaps this is actually enough. And that's a good question, which we cannot answer precisely today. Why? Because we just don't have the truth. We don't know what you would see if you had 10%, 20% coverage. What we can say, though, is that it likely depends on the use case. There are some use cases for which just a few vantage points, maybe just one is enough. There are some other use cases for which you need as many vantage points as possible.
So, what we decided to do at the university of Strasbourg is we wanted to understand more what we are actually missing. So, we did simulations. We simulated a mini Internet in our server with 6,000 autonomous systems, we configured the standard BGP policies. And then we took several use cases and tried to see what we were missing with the 1.2 coverage. So today I don't have the time to go through all the use case that is we did, I am only going to focus on two of them, two that are very common is detecting peer‑to‑peer links and also detecting forgeries and hijacks.
So, our simulations, they say that with the 1.2% coverage, we actually miss 84% of the peer‑to‑peer links today. If this is true in the reality as well, it's a bit worrisome because it means that all topology that we are building, they are likely inaccurate. And for forgeries and hijacks, we observed that we are missing 24% of them, so it looks better than peer‑to‑peer Linx, but a hijack is something that can be bad, it can be malicious, it can impact connectivity so you don't want to miss a hijack, so it's the not so good either.
So for more information here are more details about the simulation. For more use cases I just invite you to read our paper from last year, it has been published at SIGCOMM. I have to move to the next slides because I don't have a lot of time.
.
Now is the time I am going to introduce you our new platform, and I will explain to you how we improved coverage, how we improve storage and how we better distributed the data to the users. So I'm going to start with the collection.
So first of all, bgproutes.io simplifies, automates and opens BGP data contribution to every autonomous system. So, everyone in this room, if you operate a network, you can authenticate using PeeringDB, then you fill out a very simple form, it takes two minutes, and you can start peering with us and sharing the data. We will share the data with the entire community, so it's going to be beneficial for everyone of us.
However just doing this, it's not going to be enough to reach like a high coverage obviously. Besides, we also realise that all the existing platforms, the public ones, so RIPE RIS, routviews, PCH, we even found a small platform in Asia, CGTF, which shares data. Each of these platforms, they have strengths and weaknesses. So, for instance, in terms of peering, some of them, they allow physical peering, some others they allow remote peering and they have different peering policies as well, so they have all strengths and weaknesses.
Regarding how we share the data, again some of them, they have IPIs, some of them have realtime streams. So now this this table we could add bgproutes.io, it's a new column here, again we have strengths and weaknesses. One of our strengths is we don't allow physical appearing, we just do remote peering. But it's when we are actually realised all of this, that we decided that we should not try to compete against those platforms, they are all good. Instead we need to embrace all of these platforms, so what we do is we take all the data they collect, and we put it into one single repository. So today, bgproute.io released the data for more than 5,000 vantage points. So this is hopefully how we hope to achieve high coverage more quickly.
Now I am going to explain to you how we achieve low data management cost because we are collecting a lot of data. So we also need to deal with data management costs.
So, for this, we actually worked hard during the last two years to develop a new BGP data compression algorithms. I don't have the time to go into the details because this is like research work but in a nutshell, basically we found that there is a lot of data, so we could really optimise things when we stored the data.
We have two types of algorithms. We have the one that are loss less and the one that comprise the data in a lossless fashion. If you are interested, for instance, by our lossless compression algorithm, you can read the paper from last year, a paper that actually was possible, thanks to the RIPE community fund, so thanks a lot RIPE for this funding.
And what I want to say is that we're only using the lossless BGP data compression algorithm because we don't have a lot of data yet, we just started the platform. But eventually at some point we will use lossless compression algorithms.
So finally, I will explain to you how we try to better distribute the data to the users. And for this, we have implemented a fast API which enables users to retrieve the data with my granularity. This matters because collecting more data is great, but it's not very useful when users, they are not equipped with the tools to effectively process this data. Okay, so perhaps amongst you, there are already people that try to analyse BGP data, so they want into the routviews MRT archives and they found all those files, they are like thousands of files for updates, those files they are pressed and everything in those files is mixed up so there are things for multiple vantage points, multiple prefixes, so this can be like quite time‑consuming and it can take a lot of resources to process all these files. And that be be quite painful when you want to analyse something. So just to illustrate. Imagine you are a network operator and just want to get the BGP updates for which your ASN appear in the AS path today. And imagine that this yellow space here is all the routviews MRT archive, it's tense of terabytes of data. If you want to answer this query, you probably just need this green slice of the data, it's just a few kilobytes. The problem though is that if you just want to analyse the small slice of the data, you are left to download and compress and analyse a large slice of the data here in red, and that's gigabits of data.
So, we actually asked researchers that works on BGP if that was an issue for them, and they said yes, it's actually an issue, they don't have often the time and the resources to process all this data, so what they do usually is they resort to sampling. So they just downloading data but less. And what does it mean? It means that basically they will in fact analyse some of the slices that here matter for them, so the blue slice here, but it also means that they will not analyse some of the data that is useful for them because of the sampling, so they will miss important things. And this is exactly what we want to avoid.
So this is why bgproutes.io also comes with a symbol, which provides a very high granular large access to the BGP data. So we have three end point. Vantage point, updates and RIB. And then each of these end point comes with many parameters, so you can really breed very flexible queries and get the data you need. The goal you never download irrelevant data anymore. That's the goal. If you are interested you can try it out. There is a full documentation on the website, and yeah, you can just try it.
So just to conclude. I just want to show you how you can use it in practice, so for instance, if we take the query that I was using before as an example, you want to get all the updates with a particular ASN in the AS paths, you can use a Python client, so you import it, it's BGP routes API, then you first get the vantage point you want using the vantage points function, so here, for instance, we just take all the vantage points from bgproutes.io and RIS, and then you just iterate he whoever this vantage point and for each of them you get the data within the specific time frame that you want and you can only get ‑‑ you can only also get the updates which include the AS and the AS paths for that you can use AS pats regular expression, then you will get just that slice of the data very quickly.
Okay, so that concludes my presentation. So, thank you very much. So if you want to peer with us again, you can just go on the website, it's super easy and we will share the data with the community. Now if you have questions I am happy to take them.
(Applause)
AUDIENCE SPEAKER: Hi, hello, Sander from Vantage. I have a question about one of your first it key points, the collection are and high coverage. I am curious if you want to end up with the same and comparable VPs that other tools already have? I am curious about the fact if you won't end up with the same V Bs that the other tools already have.
THOMAS HOLTERBACH: That is possible, definitely its hotel. RIPE RIS and routviews they also ASNs that peer with both of them, so, it's possible. It might not be completely useless though because you can have routers in one ASN that sees different things. Actually most of the time for us in 9 the percent of the time two routers in the same AS will see the same things, but here we still care about the one person that is different, so this is why we really tell people to come and peer even if they think they might be relevant with some other existing VPs. We have algorithms that will automatic find that and will eliminate them if using our algorithm for instance, so you are right, but even if you think that there is like a lot of redundancy, it might still be work peering with us or any other platform actually.
AUDIENCE SPEAKER: Thank you. That was a second point I had, good job and good luck on the research that you are doing.
AUDIENCE SPEAKER: Antonio Prado. Thanks for your work, for your research. I like it very much. Just a little curiosity from my side. This is a project with a long term scope, okay, in order to get ‑‑ to have data available for a long time for research etc. I went to your website but I didn't get what kind of funds you use to ‑‑ in the business model of this kind of project.
THOMAS HOLTERBACH: Yeah. So for now this is like a research project so it's research funding to manage it. Of course, we would like to make this platform a sustainable over the long term, so at some point we will need to find funding in one an or another so that it can say alive for years hopefully. We're working on this, this is why we are here in this conference I I could talk with some people and thanks for that it was amazing so we could gather some feedback and see how we could in a way in order to make this platform sustainable are over the long term. One thing I want to say also is that we are also working hard to reduce also the cost of everything, so hopefully, you know, we try to limit the cost, so it can survive over the long term, even maybe with through research funding or something like this. We are still investigating all of this. That's a good question. I don't have a precise answer but equally try to do the best we can, but yeah, for now, that's where we are at this point.
AUDIENCE SPEAKER: Tobias: I was wondering you identified the difficulty of looking out for for example data from routviews because it's just so vast of a database and you then want to search through it. Have you thought about ingesting all of that data into your system as well because that should be doable given that it's more space efficient?
THOMAS HOLTERBACH: You mean taking the past data as well? So we could do this. The problem is that ‑‑ so there is a lot of data that is coming already now in realtime. So, we are ingesting roughly 1 gigabits of data everyday. If you want to take aside from that the past data at some point in terms of the writing speeds, it's going to be tough to populate the database in realtime plus taking the past data from routviews is going to be tough system wise.
AUDIENCE SPEAKER: Wait wait. So, you are currently hitting performance issues if you would start to ingest for example routviews at some reasonable speed like say factor 20 of realtime.
THOMAS HOLTERBACH: 20 times more than what you get now?
AUDIENCE SPEAKER: Well 20 times more than the realtime ingestion speed of routviews was. So that you would basically need like a year, two years to ingest the whole routers, that would already not be possible?
THOMAS HOLTERBACH: The thing is perhaps it would be, and in fact we have an algorithm that optimised this. For now you just need to keep in mind we are running these things on two community servers with very tiny funding and for instance we have a server that just have a 2 terabytes hard drive. For now we would not be able to to this. We don't have the hardware capacity to do this. Now if one day we can buy more servers, perhaps in fact we could go in that direction as well and take all the historical data and put it in our database. But for now we will have too many constraints on the hardware.
AUDIENCE SPEAKER: Would it also not be possible to have a large influx of peers right now?
THOMAS HOLTERBACH: No, no the realtime peers, this is fine because its problem is once you get the historical data it's a lot of data, right, a lot of more than just getting the realtime data so for now, I don't think we have the capacity to take realtime data plus all historical data, we wouldn't be able to do this now with the hardware we have.
AUDIENCE SPEAKER: Emile. I was kind of involved in making the peering policy for RIS a bit more selective, so, the asked me for that. We did this because, not because of the volume but because we kept getting the same types of peers all of the time. So, they were very similar. So it's not ‑‑ that was not the ‑‑ the volume was not necessarily ‑‑ well it was also a problem but not the main problem. But the question is: Your simulation, would it actually be able to help us with finding the peers that add diversity to the platform?
THOMAS HOLTERBACH: Well that's a good question, but there is ‑‑ so, that's actually was one of our challenges when we wrote the paper paper, is that you are saying that peers are similar but what is your definition of similarity? And what do you think people will be interested in when they will look at the data? Perhaps they are actually interested by measuring similarity between the vantage points, and that is the challenge, is that there is not today institutes on what is similar, what is not similar, what is relevant and what is not relevant. And this is why when you say well two vantage points seem to be similar so we just take one of the two. We don't take the same approach because first of all, even if there is just one person that is different, we still think that it can be, it can matter for some people. And even if it they are relevant, you could still be interested by measuring these. So for instance, perhaps you want to see whether your prefix is visible from everywhere or things like this. If you see relevant things it can be useful this that sense. So, yeah, that's a tough question. What was the rest of your question?
EMILE ABEN: Can you give us a very practical recommendations on how for all route collection platforms on how they can add to their own diversity and maybe the collaborative diversity.
THOMAS HOLTERBACH: Yeah, so the SIGCOMM paper that we did, the approach we tried to use was not to take some use cases and to check whether this vantage would be better or not. What we did decided to do is to do like a sort of a compression like when you compression, like when you compress images, so you won't remove pixels that are not important when you want to reconstruct the original image and that's what we are doing in our case, so we try to remove the data from the BGP archive which are not important when you want to reconstruct the original archive. So we are not taking any definition, I don't know if you want to take hijacks or whatever, we are really take the simple definition which is also used for instance in image compression so we are doing the same thing but for the BGP data. Our algorithms by the way that we publish in our paper, they are on lean, they are OpenSource, so you could use them, and you could check which piece of the data matters or not and maybe that could help you to decide if you are interested. That's the way we did it.
MIRJAM KUHNE: Thank you again Thomas for this presentation.
(Applause)
Last up is Philip Oldham from the RIPE NCC, he is going to talk to you about TTL new RIPE meeting website which is relevant to you all for the meeting, registering for the meeting and finding stuff.
PHILIP OLDHAM: This is going to be a brief brief on some multiple changes we're making to the RIPE meeting website. And what that means for you as attendees.
The good news is that there is no action required on your part, not even a routing update. I'll start off with a quick introduction. For those of who don't know me, I am Phil, I am manager of the web services team. Web services looks after the tech behind the NCC's public facing websites. So, that includes the main ripe.net website, the labs blog and every RIPE meeting website to date. All 90 of them. Although the oldest ones live on our shiny new ripe.net platform.
The past few years the team has been working on consolidating all of the systems we manage into a single tech stack. And for the last nine months, our focus has been on developing a single platform to host all future RIPE meeting sites. We're also replacing the well loved but hard to maintain tool that we used to manage the call for presentation work flow, with something called pre‑talks, which you may be surprised is not to learn is not a nat_traversal technique, it's actually a robust, OpenSource tool used by many NOGs and tech communities similar to our own.
The goal of these changes is to simplify the development process, making it easier for my team to response to issues, manage changes more effectively, introduce new features, and importantly reduce the attack surface. Up until this meeting, each meeting has had its own WordPress instance which required a lot of manual work and once deployed, tracked a lot of attention from malicious architects. So, we're pretty happy to be moving away from that platform especially since the new setup makes it easier for us to follow accessibility guidelines which is something we're keen to do, and alliance with the NCC's goal of being more open and inclusive.
What this means for you.
Hopefully, most attendees won't notice too much changes. We have migrated the existing layouts and menu structure, so everything should continue to feel familiar. The move to pre‑talks, however, will affect those submitting talks for future meetings. Web services has been testing pre‑talks in parallel for the last two meetings, and we have already seen it working pretty well. We're currently wrapping up the final integration pieces, and that's behind the scenes, but as we all know the real feedback loop only starts when people actually begin to use the system in production. That said, we hope that the track record of pre‑talks with other NOGs means fewer surprises for everyone involved.
So, when is this happening? Right now. The RIPE 91 website is live on the new platform with many usability and accessibility improvement already in place. And the call for presentations using pre‑talks will open in a few weeks, once the wrap up of RIPE 90 is complete.
In the meantime, we have already had some useful input from the Programme Committee at this meeting which will add to our list of updates to be implemented in time for RIPE 91 in October, But we'd still love to he hear from you, the attendees. These systems are built for you, and your feedback is invaluable to me and my team. If you notice any problems, especially during the talk submission process, please do get in touch using the usual channels, we're happy to help.
And that's the brief brief. Any questions?
.
(Applause)
MIRJAM KUHNE: No questions? We have time. We are looking forward to submitting your talks in the new system. All right, well thanks again, Philip, that's it.
That actually leaves us with a bit of time. Are there any other topics you'd like to bring up, any questions you have, any maybe topics for next time
DANIEL KARRENBERG: My personal inbox is overflowing I'd like to clarify something about what I said about the diversity on the NomCom thing. My comment was not to what Brian and Leo said, and I am absolutely in favour of reviewing the way this is done. I was more reacting to the reactions I got from some community members where I felt I was being personally blamed for, say, the lack of diversity.
And again, I personally approached, and I know other people approached eligible persons to serve on the NomCom, and we were turned down a lot of the time. So it's not like they didn't know. It's not like communications problem. It's a problem of the community not willing to take or ‑‑ good parts of the community not willing to take the work, and we actually increased diversity of the pool, but the randomness just was random and didn't reflect fully the diversity of the pool.
AUDIENCE SPEAKER: Tobias: I think the most important point to take away is that we hear that there is an issue and that we as a community will revise or approach to the NomCom process, and that will likely also be a top agenda item for the incoming Chairs for the next NomCom process in five years from now and we will strife to do better then and we have to have a more diverse and representative of this community NomCom selector next years.
MIRJAM KUHNE: Just to clarify what Jan said earlier also what the previous NomCom did is after this whole process is over there will be a report with a number of recommendations probably, that's how I expect it, that's what happened last time, and then after that the community can go through the recommendations and can address them and improve the process for next time. So, just to clarify the process there.
Are there any other topics, anything else you would like to bring up?
If not, I can have a longer coffee break. There is still two BoFs after this session. And after that, again, there will be buses, for those of you who would like to attend the dinner, to bring you to the venue then downhill, so to speak. Enjoy the dinner and the evening and tomorrow we will start half an hour later at 9:30.
Coffee break.
LIVE CAPTIONING BY
MARY McKEON, RMR, CRR, CBC
DUBLIN, IRELAND.
