Main hall, Plenary session
RIPE 92
18 May 2026.
4 pm:
KEVIN MEYNELL: Okay, it's four o'clock, so let's get this Plenary session started.
Welcome to the second Plenary session of the day. We have got two full talks for you, and then followed by three lightning talks. Just to introduce myself, mime Kevin Meynell, I am one of the Programme Committee members, I am joined by my co‑Chair of this session, Anneka Hannig, also on the Programme Committee.
Just a couple of quick announcements. The Programme Committee nominations close tomorrow, which is Tuesday at 3:30, so, if you'd like to become a member of the PC, please have a look at the website and submit your nomination. You can self‑nominate.
Okay. So there is also a BoF on bridging the IETF and RIPE, I think that should be bridging between the IETF and RIPE. So, titled from standards to operations and back, and that will be held straight after this session, and then that will be followed by the welcome reception, so you are not going do miss the reception which is kind of important as well.
Okay, let's guilty into it.
Our first talk is currently a Ph.D. student. He is focusing on inter‑domain routing security, Internet measurement and the scaleability of Internet structure. This talk is on noisy routers, investigating the make‑up of route collector data.
EBRIMA JAW: Thank you. Good afternoon everyone. I am a final year Ph.D. student. This work was a joint effort with folks from this list. My supervisor is from the Univeristy of Twente, Maurice who is in the audience.
So, we have a subset of ASes from the routing table which is the route collectors such as route views and RIPE RIS in the format of MRT file, and looking at this simple topology, we have two ASes as X and Y and then they send the routing information with RIPE RIS and routing information. This data is fundamentally very important for both operational and research activities because it enables operators to do network.monitoring, traffic engineering and also to troubleshoot their networks.
Also, it enables researchers like myself to understand the Internet Committee such as studying the Internet topology, routing security and traffic engineers. This data is very, very important.
So, the expected normal BGP announcement operation is that routers should only trigger announcements to reflect configuration changes such as when there is a newly announced prefix or a withdrawn prefix or there is a link failure from an already announced prefix.
So looking at this simple topology we have ASX and Y and they are announcing their prefix to Z. So they announce two IX prefixes to Z and now in Z's RIB it has two prefixes. Now it says this with the router collector projects like RIPE RIS or route views.
So, what we expect after five minutes what we expect to see in this project is to see one announcement of these two prefixes because the provider they are not withdrawn or there is no link failure in these two announcements.
So, what we observed which leads to this study is that there were some files that were collected in this collector projects that were bigger than other files and we were curious to know why this happens. So potential noisy routers could lead to this kind of behaviour, for instance, looking at the same topology again, let's assume router 6 of ASZ got noisy and it continuously sent whatever it in the RIB. Considering that it has these two prefixes it sends all these two prefixes less the ten times per minute, at the end of the day instead of having one announcement count for those prefixes, we are now having 51 of exactly the same information. And this is not really telling us any new information about these two routes, prefixes, it's literally giving us exactly the same information, 51 times. And this is a problem of course because it will lead to unnecessary inflating files and also put an extra load on routers that are processing this information.
So, our motivation for this study was mainly challenges in. In 2022 wrote an article expressing how important RIPE RIS is also but expressing that they have data management challenges. And in the blog it highlights which strategy on how they can minimise this by doing strategy peering to minimise the amount of data that they are collecting. So last year in NANOG an e‑mail surfaced where they complained that there were a small sets of prefixes in route RIB RIPE RIS that were unnecessarily sending a lot of announcements. And one of the operators from route views acknowledge that had they also observed the same behaviour in their route collector project but just from a few peers that were causing a lot of stress for their route collector projects.
So aside from this as a researcher we also have access in terms of both the storage and the computational stuff that we are collecting. Some folks from Strasbourg asked the researchers to ask them if it's computational expenses to process BGP data and we see that respondents say that yes, they have computational challenges in dealing with this data.
So, our main goal when we see that there are some files that are unnecessarily lighter than other files that were collected at the same time, we wanted to understand what is in this data.
So, to lay the ground work for this noise which is kind of subjective and also could be a bit controversial but in our study what we refer to as noise is that when we have an announcement for a given prefix an it is repeated again with unchanged attributes within a certain period of time, let's say one minute or even a few second, we call this a noise.
We consider this noise because it gives us no new routing information or very little information sometimes based on, as a result of commodities or route flapping but this is really not giving us any additional information on how to get to this prefixes that were already announced.
So like I mentioned earlier this, leads to, you know, it puts more processing load on routers, and also unnecessarily inflates MRT file sizes.
So, to study this, what we did was we produced like 13 years of data where we extracted on a daily basis a collector peer, the object contribution of a collector peer on a daily basis across the whole 13 years because we wanted to understand how the objectives were disputed across the collectors and their peers. So, considering that we cannot also do this for a ‑‑ like, we cannot drill down into the whole data, we just used two amounts of data for 2021 and 2024 for that drill down into the data to look what is exactly in this data.
So, our first goal was to measure the update distribution across the routviews collectors. So routviews has 36 collectors and we were interested to see what is the distribution of the data that they collect across these collectors.
So, to do that, what we did, to summarise our methodology, we complete a daily update counts per collector and then we aggregate this into six month intervals, considering this is a long time span, then we compute the average of each every six months. And we rank the collectors by this average counts that we had.
And we just select the top 11 collectors and aggregate the rest as "Rest."
So, looking at the results here on the Y axis, we have the update counts by collector, and the upper figure and then the bottom figure is just the share per collector, and the X is just the dates.
So out of the 36 collectors that are being run by routviews, only the top five collectors are contributed like 54% of whole routviews data across the 13 years.
So, to put this into context, out of this top five, only two collectors, which is Linx and Perth, alone contributed 30.4% of the whole data across the 13 years. We have looked at this and most of these announcements were repetitive announcements with less withdrawals telling us that this announcement were not due to the fact that these prefixes were not reachable or were withdrawn. So it was just unnecessary announcements that were triggered.
So, in contrast over one third of the collectors just like contributed fewer than 1% of routviews data across the whole 13 years. So that tells us that we have a whole lot of collectors that are operated but either they have, you know, peers that are stable or they are not really collecting a lot of data.
So, we can see one interesting thing during early 2021, late 2021 to 2022. So, Perth alone was a very noisy collector during this time, and it also happens to be the largest routing event ever. So in November 2021, Perth alone contributed like 74 billion updates and then which is like literally 3% of the entire 13 years of data.
So, the key takeaway here is that out of all these 36 collectors there are very few collectors that are contributed a lot of data unnecessarily because it's most of the time it's repeated announcements, and this is somebody might say that maybe it's just simply because these collectors have more peers. Not necessarily, it is also not correlated to the number of peers that are reaching these collectors.
Now, that we know that updates are unevenly distributed over, the update contribution within collectors are highly skewed, we wanted to understand the peer contribution within these collectors. Are the updates less, say Linx and route Perth are noisy, is it because all their peers are noisy? So we wanted to understand this.
So to do that, to simplify our methodology, we constructed a daily update time series for each collector peer in every day. And then we rang these in each every day because we could have a peer that is noisy today and not noise tomorrow. So on each day if we complete the collector peer‑to‑peer we run them by noise on a daily basis and we put them in to let's say the top 5% and then to the lower 50%.
We also complete heavy hitters, heavy collector peer hitters, which means the top contributors, we quantify who are the heavy hitters and then we aggregate the least noisy collector peers.
So, if we look at the results on the Y axis, it's the total number of updates per day and on the X axis is the number of years across the 13 years, so we have the top five collectors on a daily basis so, if we put this into context like we have about over 1 K peers, and then on the top 5% on a daily basis, we have an average of 160 peers, that is what we have often the top 5%. But we can see that they constitute a light amount of data across the 13 years. So out of the 2.6 trillion updates within the 13 years over 55% of them came from this top 5% of collector peers, so what this tells us is that this noise that we observe in these few collectors is not necessarily all their peers but it's just coming from a certain number of a few peers.
.
If you look at the lower 50%, which on a daily basis on average have over 600 peers, they contributed just 5% of the whole 13 years data telling us that we have a heat number of peers that are acting very stable but then very few peers that are sending a lot of updates during the whole 13 years.
If we look at the bottom figure which is just a share of the heavy hitters, so, we observe one interesting thing. There was this peer for Perth collector, which is AS 140627 alone contributed 14% of the whole 13 years data.
So, the key takeaway here is that noise in BGP data is prevalent but is also very unpredictable simply because you can see one peer being noisy maybe a few days, a few weeks or months and then it goes quiet and another peer happens to be noisy again.
So, the next goal we had was to measure ‑‑ now that we also understand, aside from having a few collectors that are contributing a lot of data with a few peers that is the reason for this, we wanted to understand what is inside those peers because a peer can have different BGP sessions so we wanted to evaluate if all the zones are noisy meaning this noise is coming out of the peer is it due to all this session or just to a few sessions and prefixes, that's what we want to quantify here.
So the methodology we, to summarise our methodology, in each BGP session ‑‑ so this is where we used the two months data. So we compete per minute share of each BGP session over the two months and we applied some statistical methods to quantify how updates are concentrated in sessions and also the variability because like, you know, how fluctuating the updates are across the days.
Consultation tried to ‑‑ it helped us to determine the dominant sources whereas the various ones helped us to determine how fluctuating the updates were across threes two months. We applied the same methodology to prefixes and AS paths to be able to quantify the few prefixes and AS paths that are causing this noise.
So, to look at our results here on the X axis we have the share per session and on the Y axis sorry on the Y axis we have the per minute update share per session and on the X axis is just the days across 2021.
So, only 2% of the sessions like we have over 2k sessions but only 2% of them, which is 19, accounted for like 71% of the at that time for one month, whereas the remaining sessions just provided a very negligible amount of data within the months. So ‑‑ and one interesting thing that we also observed here is that the lightest routing event that ever happened between this time, which was like almost at 12 hour event, where during this time we found like we analysed 45 MRT files and in each of these MRT files, we have about 730 unique prefixes and about 32 million updates which were collected within a 15 minutes time stamp, so what we speculate could have been happening here is just like a faulty router that is, that was continuously sending everything that it has in its RIB continuously during this time.
So, the key takeaway here is that we have a subset of sessions across those noisy peers that continuously generate this significant amount of updates during this month. And most of these were redundant because they were a replicate of an existing route that is already in the data.
So, if we look at the prefixes again what we have, on the Y axis is the cumulative share of announcements of prefixes and then on the X axis, we have like the share of updates per prefixes sorted from the most, prefixes with the most updates to the least.
So again only two prefixes account for over two types of the one month data, like if we look at this, which is 74% of one month data comes from 2% of the prefix that is we observed in this data.
So, in contrast, like of 75% of the prefixes just account where appeared in only 5% of the update. Indicating that we have a light fraction of prefixes that were stable across the month but a very few set of prefixes that were unnecessarily generating a lot of updates or announcements.
So, the key takeaway here is that we have a very small fraction of prefixes that were unstable across the month, whereas, you know, we contributed to a lot of announcements during this month.
So, of course, we are researchers, we can't tell operators what to do but we have some consideration that a we think operators should consider. We think, based on our observations, actively monitoring sessions and prefix to say timely identify certain problems will be helpful. We said this because recently we were looking at the same problem in RIPE RIS data and we found a prefix that generated like over 200 million announcements for an IPv6. So when we wrote to the operator, what he told us that he didn't know this was happening, but it could be due to the fact that he had unstable VMs during the month of April, and also he had these sessions like in tunnelling it could be the reasons. This, we believe, if ‑‑ sessions and prefixes are monitored actively, then you will avoid those kind of things.
Also, with we think it would be helpful to audit your router update behaviour after a session research. You don't audit after that, if the router is behaving abnormally, that will continue, if you know. What we also think could be the reason for some of these things is like maybe automation scripts to also look at your automation scripts and also BGP implementations.
So, for route collector operators we think selective retention policy for noisy update data will be helpful, for instance what is currently done with the pack A files, keeping them for one month, where the users or the researchers could decode them and after that you could delete them. I think this could be helpful to manage your storage challenges.
Also, identify a noisy like sessions and isolating them could be helpful because we have identified that not the entire peer is noisy but is just a small set of sessions that are noisy.
So, also what we found for both RIPE RIS and route RIS is out of all these collectors that they had, not all of them are collecting huge amount of data so the data is just like centred around a few collectors so we think maybe increasing the peer contribution in those under utilised collectors could also be helpful.
So the key takeaways and operator feedbacks that we need from our talk is that noise in BGP data is very prevalent and also very predictable meaning that you cannot ‑‑ it's hard to predict when the noise will happen and where it is coming from.
So a few session prefixes and AS paths were the main causes of all this noisy that we also found in BGP data.
So, prefixes are not universally noisy. What we mean by that is that a prefix could be noisy from one vantage point backup stable in another vantage point and we believe this is simply due to the fact that the prefix is taking a route or a path that is just having a router along that path which is unnecessarily noisy.
So, noise is largely due to faulty or misconfigured routers. This is what we think. And also not necessarily from an origin AS. So what we did in the presentation and in our study you can have an origin AS that originates a set of prefixes where some of them will be noisy and some will not. Telling you that the problem is not necessarily originators but maybe just another issue.
So, all these redundant announcements that we have just unnecessarily inflates MRT files without giving us any new routing information.
So, this is where we had a call for feedback. We are researchers and these observations we had is all we could produce, and of course we have also tried to find out what are some of the route causes for this. For instance communities want ‑‑ and also route flapping but aside from that it's hard to tell exactly what is causing this. So we'll be really appreciative if you could give us some feedbacks with regard to some of the route, potential route causes for this.
Thank you.
(Applause)
KEVIN MEYNELL: Thank you. Do we have any questions?
AUDIENCE SPEAKER: Thank you for doing this. So you mentioned there a couple of brief things that are noisy and you reached out to at least one of them and they decided to investigate. Did you reach out to any others and did they fix any of them or do any investigation or haven't had a chance yet?
EBRIMA JAW: This is a joint effort with folks from CAIDA and we were closely also working with RIPE views and there are of course a lot of issues, especially the Perth collector has been fixed according to route views but I am not sure if ‑‑ we didn't reach out to all the prefixes of course, what route views do fix some of the problems from our stud.
AUDIENCE SPEAKER: Maria, developer of BIRD. I'd like to ask you whether the prefixes were noisy consistently or like in time still advertising the same again and again or whether it was for like some, some pieces of time, some bits of time and then nothing? Because if this was the latter, I would expect somebody is running, for example, an older BIRD without an export table and that means you are not getting the extent of how your filter has changed. So if you are changing the export filter and you get it wrong, you simply have to reload all the routes again and again until you have fixed it.
EBRIMA JAW: Thank you. It was both. We observed cases where we have a given prefix that is continuously noisy. But of course there are also instances where you have a prefix noisy for a few days and then it just went quiet again.
JEN LINKOVA: In my operational experience, nothing gets fixed until someone complains and complains loudly enough, right? Thank you for doing this, it's very interesting, but I suspect operators might not be really motivated to fix this because it's not a problem for them, right? So I think maybe one of the directions to consider is do we want to make it painful for them, because if you just have a flapping prefix it is would be dumped right, so you will suffer if you have a problem with your network and you start withdrawing advertising. Here is like, I might be doing this, I don't know if you tell me if I have national to do it might fix it, right, if something more important comes, yeah. Nobody is dying because of this, so, I think we need to find a better motivation for operators, right? And whether the signalling I agree because nobody is going to manually auth BGP sessions after they reset. If you have thousands of them, like, you need either to have some way of exporting information in newer telemetry when you are doing this, have a clear actionable signal, and explain why it's bad.
AUDIENCE SPEAKER: Nina from routviews. I just wanted to point out that over the past year or two years maybe, we have implemented a lot of monitoring on the noisy peers and we are actively reaching out to the worst offenders and most of the time they do try to work with us. There are some people who are not responsive and we will sometimes depeer them if the noise creates problems for our platform, which it did for a while, but now it's more stable so we are not doing that much anymore. Just a comment. And thank you for your work. It's very interesting.
AUDIENCE SPEAKER: Martin, speaking from (inaudible) so I got some answers from the previous questions, but mostly, what's your opinion on how we should monitor an auth such kinds of prefixes because on our side, as a network operator, it's better, it's hard to get the information from the routers and it's better to have an external view. So even on our side we try to make external views and check on them if there is an issue. But if we have an issue with the RIS collector, or any kind of collectors, we have as well issues with the routers. So, my question is: How could we better contribute to each other by having some kind of alerting when some of our prefixes are any kind of session or any RIS is more noisy than it should be?
EBRIMA JAW: I think that's a good point and then you have given me work to do maybe.
AUDIENCE SPEAKER: The point is, I don't know if the work should be done which network operators or by the collectors on this side, and who should auth and on which data, because on our side we are prevailing the network collectors but are not currently use them on our side but a few of them and we notice the problem. And it's difficult for us because the routers sometimes are buggy, you get some random bug, and it's only with an external view that we can just be aware of there is an issue.
EBRIMA JAW: That's a good point and then you have this in mind also, but the problem that I have from the context of a BGP data is let's say I have a path that constitutes ASes, if I see a prefix noise propagating this path could I not explicitly tell which AS is on that path is responsible for this. This is a limitation that people using BGP data have. What I was thinking potentially is just to flag all the ASes that are on the path to say these ASes are in a path that is unnecessarily generating X number of unnecessarily maybe announcements from a given prefix.
AUDIENCE SPEAKER: Thank you. Hi. Silven. You mentioned one sometimes a bit evil word which was tunnel, and as maybe some people know there is quite of few usual suspects on the tunnel operators now. We actively discourage and hinder our downstreams to pass forward their routing table by disallowing AS‑Sets, but if you have a tunnel inside a tunnel you end up with an MTU issues which can cause exactly what you are observing. So the question is if you find a prefix which is flapping and if you see a tunnel operator as an upstream also reach out to us, because we might be able to troubleshoot and stop this. Because I believe it's MTU.
EBRIMA JAW: Thank you.
KEVIN MEYNELL: Thank you for the questions and thank you for your presentation.
(Applause)
.
Now, our next presentation. This is a network security and routing specialist who developed the NTRM contribution to RPKI. I think Sebastian also ‑‑ he was here, he was here. You also know Sebastian who is also the peering manager for AS. This talk is about route filtering in scale. I will hand over to you.
SEBASTIAN BECKER: Hello. So, as the name says, route filtering at scale. I will cover some basics here also because we are not all the very much experienced people but also some newcomers, so, you go some through basic stuff with me.
We had a slide talk before here outside and it is being like much as German as the Internet as possible. So, we try to be that and encourage people to document right.
We were introduced. Going to the next one.
Covering, as said, some basic stuff, peering in transit, route leaks, BGP security, later on then the more technical stuff from Fedor to go deeper how we do things.
For BGP routing actually, the relationship between the two parties is very important. Either an SIP provides transit to someone else, or so we accept all the customer prefixes as the transit provider, or you send all your prefixes to your transit provider, or the peering, the bilateral peering, where you have actually just the interest of the neighbours prefixes and everything that is downstream.
So, it's very important to have that in mind that you know that this is covered later on in the ‑‑ how you document that actually later in your AS‑Set.
This is because of, we want to prevent actually route leaks, seeing that another provider is accidentally or maybe by any means, providing transit to someone that is not ‑‑ well should not provide transit.
To ensure that this is properly documented and you can actually use that as a transit provider or a peer to actually build your filters so ensure that only the prefixes will be accepted that should be accepted and you don't be part of these kinds of route leaks.
So where AS‑Sets are very important. Where you put your security parts in, it's in your routing policies, you try to filter out obviously bogons, you provide community steerings as an ISP, you participate in peer lock to ensure that the prefixes, you as a measure provider maybe, just be available via certain paths.
You implement IRR base route filters because not everyone is now doing full scale RPKI and ASPA, it's just on the way. You are using RPKI ROVs to ensure the validation at least for the origin prefix. And you are looking forward to use ASPA in the future.
So, what is an AS‑Set?
An AS‑Set is the list of your own AS and your downstream ASNs or AS‑Sets. So, only these things should appear in the first place in these AS‑Sets. Otherwise they need to be actually correctly named and they should not mix‑up in the relationships between the usage for the AS‑Set.
So if you want to document your peers, you can do that, but mark your AS‑Set for the peers and that is probably a different one that you use for your AS‑Set you want to present to your upstream.
And why AS‑Sets? To actually give this information to the public, to ensure that someone can use that, someone in the Internet is able to verify this is your customer, this is your peer, this is maybe why you participate at an IXP, to give that information to the public to make clear what is the relationship in the Internet.
And don't put everything in one. You are able to split them, you can do multiple ones, ensure that the documentation fits exactly the need for the AS‑Set you want to build. And do it, give the information, it makes the living for us maybe even SDT much easier to also build the right filters, accept the prefixes you want to provide to the whole Internet.
And ensure that you also make sure to tell people where you actually ear populate your AS‑Set, where do you maintain it. We do see a lot of AS‑Sets even with the same name in different databases, but only one is actually maintained. There are a lot of AS‑Sets around, nobody is actually maintaining anymore and so it makes, for us, much harder to use them, we cannot just import every AS‑Set AS‑Set everywhere because if AS‑Sets are not maintained anymore, that information in another database is not maintained anymore. It's basically useless. It's noise. It will increase the filters without any actually meaning or progress in generating correct route filters and it will be also a security risk bus now the door is open for maybe prefix hijacking, which we won't actually prevent with that.
.
And how you can document this in AS‑Sets, you can multiple ways. This is actually our own. There are the options like obviously you have your own AS‑Sets in that, you put the AS‑Set name of the next ones, further down if you go through our whole AS‑Set, you find also AS numbers only. And we try to provide with that actually additional information which databases we use for filtering.
So, if a customer from us does see okay, there is maybe even a registry missing, this is easy to see. You can see that in our AS‑Set. So this is additional information to help people actually document things and later on, also going for the analysis if something is broken.
We try to be as open as possible in that place, and if there is something missing, this be be added. Hopefully this is additional extra information that is helpful.
You can also document the import and export policies in the aut‑num object. Here is a very good example from ARIN actually where you do see how they do that import/export.
The problem for both of the styles, how to document these things, most of them are not easily parsable by any tool or so. It's mostly like you can check it manually.
You see we have put some numbers here, there can be very big aut‑num objects with around a megabyte, but also a lot of them, 39% of these ought num objects doesn't contain anything actually. So there is improvement in how you want, or actually how you want to document your policies.
And the AS‑Set documentation gives you the option to really tell people who is responsible for the different ASNs and who is the customer cone of that ASN.
If it's done correctly for the usage of you want to provide the information what is your ASN and what are your downstream ASNs connected internally or externally, this is actually the case how it's done correctly. You don't put in your peer. You don't put in your upstream. If you do the standard case like the ISP up or down link documentation for that.
For, I just mentioned that, I'll come later to that for peer IXP, you can have additional AS‑Sets. So it's possible to document that as well.
And you can see what are the expected down streams on that.
If it's done obviously incorrectly, some people put in the upstreams there, or even their peers. The if you mix that all together, that AS‑Set is mostly not usable, it generates cycle references or is just a huge amount of prefixes that should be in the filter but actually you will send maybe 100 prefixes but your generated filter out of that generates lines in the thousands which doesn't make sense.
And here are some examples of the domains where it's very thoroughly documented how the different relationships can be. Will we see we do have that overall customer AS‑Set. We even see an overall peer AS‑Set, and there is a breakdown for all of them for different regions. So, you can be very detailed and the reference can be inside. So normally that customer AS‑Set will reference to these more specific ones.
Same thing on the other side. You see how they document peers even on different IXPs.
Again, very important thing is, document it after the role that your neighbours are. Make sure that you don't mix‑up peers, down streams or your upstreams.
I think that's mostly ‑‑ no, that's still mine.
Some interesting statistics maybe. For that.
Where you do see that 80% of AS‑Sets were changed after 2020. So, there is some change there, so people do think not meaning necessarily that all of them are up to date. So we just can encourage you, please update your AS‑Sets. Make sure that they are up to date, that this will reflect things you want to see.
A lot of these things can be done prior. You already connect someone, so, the documentation can be done before actually you announce the customer routes. If it's clear that the customer orders a port with your network, do it prior. So everyone is prepared and when someone switches on the BGP session, the prefixes will be accepted instantly and you don't need to wait for another day or maybe some days how often whoever is updating their prefix filters.
So, the updates for the AS‑Sets, what we do see is I think a lot of people do it manually, but it can be done obviously in automation. It works fine. After years we also managed that in DT, it takes us a long time but actually works pretty well. So RIPE is offering enough APIs for that to also have that up to date by your data you should anyway have for building your BGP sessions. If you automate your BGP configuration, you maybe even with a little extra step, be able to automate your AS‑Set because that information is already there.
So, what we mostly see here and what we want to solve, obviously it's just we try to, we ‑‑ we are very strict with that on our side, that we encourage our customers to document right. So if the AS‑Set doesn't match, we do a test run before actually a BGP will be enabled or the filter will be accepted. We deliver the information back to the customer, what do we see from your side and what is expected from your side. So if the customer is telling us it will be ‑‑ he will announce 100 prefixes but we see a prefix router of 10,000, there must be something wrong. So we need to check that. And I think I am done now and need to hand over to Fedor so he has enough time.
FEDOR VOMPE: Thank you for the opportunity to talk today. I will talk about quality issues and now the recommendations.
So, talk about the documentation, I assess the incomplete inaccurate. The data is there. I set that has been removed, they are not cleaned from the AS‑Sets where they are referenced. And also, not every ISP explains to other providers how this AS‑Sets are used and what are best practices. Of course for operators managing thousands of sessions, this is completed a complex task to manage these AS‑Sets, so many of them, there are many of them changed and need to be sure that these changes are correct.
So, actually AS‑Sets represent this relationship between BGP peers and we tried somehow to code this in this AS‑Set registry. So, first of all, we have in idea customer downstream AS‑Sets and then something named like IP customers or downstreams and they document customer networks of course they should contain only downstream customers and not any peers or transits or upstream providers. Of course there may be cases there Internet Exchange present and this Internet Exchange are being concluded in AS‑Set documentation. This is not really good. We need to figure out how to manage it but it's simply here. And of course, actually, for big Tier 1 providers for Internet Exchange for route server AS‑Sets, we should actually say like in ASPA, these AS‑Sets that are informational, they shouldn't be used for route filtering.
Then it's really interesting about AS peers, it's hard to see how these can be used because if you document, you document a customer networks of your peers, and then you use it for, by yourself how you filter networks. And that's a hard thing for me to understand how others can use this documentation only informational maybe.
Also the DDoS mitigation cases are also complex and upstream transit, mutual transit, these are cases for upstream providers and it's hard to filter upstream providers with AS‑Sets.
So, currently we have so much AS‑Sets objects like 74 thousand, and from all the references in this AS‑Sets objection, only 10% of AS‑Sets are missing, but it's a gap, it's a big problem for AS‑Sets.
The biggest AS‑Sets are Internet Exchange AS‑Sets and if you get a big AS‑Set, we get, following quality issues. First of all there is a loss between ASN prefix binding. We get prefixes, we don't have this ASN to prefix information. Of course RPKI helps but it's not enough.
Also, AS‑Sets contain a non‑authoritative and auth information. That's clear. Also there are lots of AS‑Set loops. There are 700 loops and the longest is 300 so you can find it but it's informational I would say, it's not included everywhere and there is also one AS‑Set loop with 41 AS‑Sets included in one IXP chain.
Also take a look at this really interesting case of AS‑Set explosive expansion. At some point, we can get some filter gets 100,000 prefixes more and there are actually two situations that can explain this. First of all this is a coming is make. Somebody included false AS‑Set in this AS‑Set hierarchy and that's a problem. You need to see the set. It was included somewhere.
The second thing it was a proper change, it was an ISP provider that was added and it's also maybe RPKI related stuff. So RPKI when a piece gets registered it gets new prefixes added to AS‑Set. Route set simpler.
This is what it looks like. We get customer 5 with more. With the impact of this addition for customer free AS‑Set is that our upstream AS‑Sets they get these additional ASNs and the number of ASNs is different.
So, directly impacted AS‑Sets, let's consider we are a provider so we have some customers and we have links and each of these customers uses its own AS‑Set and if you can follow down this references from this customer 1, 2 to customer 5, they will have all different impacts of this expansion.
And actually, this is how it looks like now. We can manage every single change and see how every change impacted specific AS‑Sets like here it was an example, this was an impact on six AS‑Set we are using from different providers and that's how it looked.
So best practices. So of course, we should know which era and data we use, if we are operator, because transporting of resources is under question so there are the more (inaudible).
Where he should filter bogons, we should filter unassigned ASNs. This is everything here right now in AS‑Sets. This information wasn't cleared for this five or seven years, and we also, we can do a lot of work here together and of course, we should also filter stale and incorrect reference if we detect this. Maybe we should get the filter that was created yesterday and use it.
So, good tools are these. So use them, for maintainers, it's the the same. So use AS‑Sets documented somewhere in peering aut‑num, policies, so how you use AS‑Sets. It's a really good informational source. Also, use AS‑Sets for documentation of your downstream providers. I'm not completely sure that if everyone is using these huge AS‑Sets. Of course there are use case and really hard and not manageable.
So internal we use RQSpec, which is a language that allows to use this kind of expressions. For example if we want to resolve this, we use this expression, we can also use RPKI data and include in this expression. So it was introduced by Rudiger Volk before at NANOG and we still use it and we also have then records resolution and loops prevention cases. We can also combine different type of specs and different expresses all together to include import and export filter.
This is an example. So if we get an AS‑Set, we should now before we deployed during the deployment and after it when we deployed, what happens with this filter and we should categorise everything to see if the quality of the filter is good or not enough. This is a view for ASNs included in AS‑Sets, and here is a view for prefixes. We can also categorise every prefix and now it's RPKI included or maybe some unknown prefix or RPKI invalid prefix. I am sorry I don't have lots of time. I need to scroll further.
And so, we can also see this structure for AS‑Sets but it's not really interesting, so simple understanding, so AS‑Sets included in other AS‑Sets.
RIPE has a very good RIPE historical API. It can be used to see the problems or how AS‑Sets are changed before deployment or when they are changed at some point. So really great service, RIPE historical in Whois or also rest are API for this.
It's really important to use, implement those changes because there are lots of APIs. So they both change. And it's better to precollate filters, also the best solutions, they are simple and fast, that's really important to of, to understand this, and you can manage these tasks really good.
And of course then, further work is of course we need actually to my migrate to ASPA and that is a topic that is really promising. So I believe in ASPA, and we can use, instead of AS‑Sets, ASPA with max prefixes and also there are other solutions how quality of AS‑Sets and ASPA filters can be measured. So it's work, so we need to compare what is being announced and what is allowed, and it's a good things to do further.
I am already over time, so I want to wrap up.
Please document your AS‑Sets very precisely and AS‑Sets are still there. This is like dinosaurs across us but we need to manage and we need to use them and simple and small AS‑Sets are really useful because they don't have route leaks because they allow only that is allowed to be allowed.
Okay. Thank you.
(Applause)
ANNIKA HANNIG: Thank you. So, are there any questions? I think we're a bit over time but we have I think time for at least one or two questions left from the audience. When you are at the microphone, please state your name and affiliation.
GEOFF HUSTON: You point out that AS‑Sets are problematic because they are not well understood, they are not coherently maintained they tend to accumulate bit rod and this gives them huge amount of problems if you try to understand what you need to do today as distinct from the long history of what people did in AS‑Sets and still sit around in registries. Part of this is we don't pay any attention to them collectively. Why do you think digitally signing that information with change behaviour? What good would ASPAs do if the real problems are not intrinsically in what you are trying to achieve in terms of a commentary on routing information? ASPAs, by the look of things and the way we behave, look to have exactly the same operational problems in the future that you have now with AS‑Sets. Digitally signing it does nothing. It just says you said it, great. But it doesn't make it true as an observation of reality here and now. So, why this slide? Why your faith? I'm not with you. I don't believe that as a statement. So I'm kind of pressing back going, it doesn't sound right to me.
FEDOR VOMPE: That's a good idea. In AS‑Sets we know they include other AS‑Sets. This is a direct relationship and with ASPA, this is inverse relationship. We define providers. Of course there will be cases there will be loops at some point in ASPA, there will be stale data, everything will be maybe the same. But it's already better to say and to see if we have this downstream ramp or upstream ramp that be validate it. It's already something and we can provide this fail safe solution when we let's say okay we collect all the ASPAs and we manage this ASPA filter. And ‑‑ but AS‑Sets right now is a problem.
GEOFF HUSTON: I stand in awe of your optimism. Good luck!
ANNIKA HANNIG: We have only time for one last question.
AUDIENCE SPEAKER: My name is Edwin, from Surf. So we won this lab network as well and things happened there obviously, so, we found out that you didn't accept our route, so we all the work, running all the AS‑Sets, everything was provided but we discovered that the aut‑num wasn't right so a stupid thing we fixed it, but I heard the words in this presentation only once, but your policy finds it at least as the same importance as the AS‑Sets, so did you run a research on still aut‑num objects as well? The import export from AS numbers.
FEDOR VOMPE: You mean about quality of filters, how much they accept and how much is actually accepted or...?
AUDIENCE SPEAKER: You present this problem with AS‑Sets that are still, and do you have any observations with customers or peers that also doesn't maintain their aut‑num object?
FEDOR VOMPE: I would say so. Unfortunately this is somehow 20 or 30% maybe ‑‑ so 20% of the prefixes that are accepted are being carried for the big AS‑Set. This is like for ‑‑ and if you get bigger AS‑Set, then we get a lower account of prefixes so this is a thing that needs to be solved.
AUDIENCE SPEAKER: I think the message is that AS‑Sets are also a maintainer that's your experience ‑‑
ANNIKA HANNIG: Unfortunately, I think I have to cut this short now because ‑‑ well thank you again. A big applause for our speakers.
(Applause)
ANNIKA HANNIG: Next up here, we will continue with lightning talks. I am your host, Annika Hannig, I am taking over for Kevin and I want to ‑‑ I want you all to welcome, give a big applause for Matt Jepp. He is going to talk about net UK and without further ado because we are already short ever time. Please let's go.
MATT JEPP: Good afternoon, I would like to introduced you to the UK latest infrastructure community bringing together top industry minds, infrastructure providers and scholars.
I'll do a quick introduction of myself. I am the Chair of the Programme Committee, I am a volunteer like the rest of the UK team. I liaise with the management committee and the organisational committee for operational matters. I do also have day job. I am head of pre‑sales and engineering for a company called STGS that is based in Singapore but I'm not here to talk about that today.
Net UK first came about back in 2023 at EPF in Prague. The existing UKNOG group was having difficulties and there was lots of discussions about what was going to come next. Between my colleague Dave who is the management committee chair, Fergus McKee who we all knew, brought together the three main non‑profits based in the UK, links, Lonap, NomiNet and then also Dave's company PTX to begin putting something together.
The idea was that it was a non‑profit organisation to bring collaboration, to replace that missing NOG environment.
We operate one event in the UK a year and that's to provide, give people a chance to meet, exchange ideas, get discussion, build new connections and elaboration, we focus on four key areas which are knowledge sharing, community development, professional exposure, inclusion and diversity.
So the mission of NetUK is to foster a vibrant community of individuals and organisations which are passionate about United Kingdom's network infrastructure industry. That doesn't mean it's a UK‑only event. It's important with we get input from the rest of the world there is a lot of networks out there that interact with the UK and their input is just as important.
So, why come to NetUK? We have got attendees from a lot of UK's large providers. We have existing contacts, new contacts, especially we also invite students to and Ph.D.s that kind of thing to bring the theory as well as the practical.
We have a set of technical workshops, Plenary Sessions and lightning talks as well. And also the food is really great, which is thanks in no small part to our organisational committee.
NetUK runs back in 2024, we had over 200 attendees. A couple of highlights from the agenda. Was sky as talk about how they are operating MAT T, and some lessons from Rolls Royce who have been bringing their knowledge from the nuclear industry and bringing in security in their IT infrastructure.
In 2025, we had NetUK 2 which grew slightly. We had approximately an extra 20 or 30 attendees at live. And that was presentations on both prospectives on AI data centres and also Steve Jones talking about energy efficiency. We have lots of other talks which are on our Indico and YouTube channel.
Our next event is in July, 6th and 7. We are at the brewery in central London again. It's a fantastic venue. Lots of history A bit of a maze. We have workshops on the first day in the morning, and then the Plenary session starts after lunch. Day two is a Plenary session with lunch and breaks into be able to mix with other members of the attendees.
We do charge for attendance, £120 gets you both days attendance and also gets you access into the social event in the evening. We do have a programme for free tickets for students, job seekers, there is an option for ordering when booking a ticket, to select that.
We do have sponsorship opportunities available still, not a lot. But there are a few gaps left.
And it's open to everybody involved in digital infrastructure, it's not just about network providers.
.
Ways to get involved. We have got a mailing list. We have got a SLAAC work space, we do have a YouTube channel. There is an e‑mail address. We are looking actively for members for the Programme Committee so if you are interested in contributing, if you have got some contacts you'd love to get on the stage, please let us know.
Come and join us at NetUK 3, tickets are available. And there we go. Thank you very much. We hope to see you on the 6th and 7th July.
(Applause)
ANNIKA HANNIG: Thank you. Do we have questions? Yes, one question.
AUDIENCE SPEAKER:
JIM REID: You talked there about a members list. Is there actually a membership fee for joining this organisation? I didn't catch that during your presentation?
MATT JEPP: There isn't a membership fee. You register for the event. There is an open mailing list and there is a link on the website. SLAAC again, there is a link to join that on the website.
JIM REID: How would people participate in this organisation or these events? Have any kind of say in who is going to running it and how office peers are chosen.
MATT JEPP: We have asked this question back at the first one how do people want to run it. There was mixed feedback and people had strong ideas but the majority just said let's see how it goes. We're coming up to event number 3, and one of of those questions will be asking at event number 3 is where do you want to go next? We obviously have the usual surveys that kind of thing at the end of the event as well and within the questions we do ask for feedback is where do you want to see it go next? Do other people want to take over? Do people want to get involved and that's what we ask?
JIM REID: Thanks very much for clarification. I have one or two things to follow‑up, I'll do them offline.
MATT JEPP: Thank you.
(Applause)
ANNIKA HANNIG: So, for our next lightning talk, I want to welcome Remi Hendriks on stage.
REMI HENDRIKS: Thank you. Today I will talk about a work in it progress, this is something we have just started. It's about Anycast in under served regions of the world. We realise that this is a problem that cannot be solved by researchers alone and that's why I am here, because we are actively looking for collaboration with operators that can help us move this further.
So when we looked at the catchments of our Anycast deployment, we notice that had whilst we have a pop in Africa in Nigeria, we noticed that neighbouring countries would still route to our pop in Paris and this is likely because there is limited peering between countries in Africa and it's something that we also discussed with operators at OARC for example, and they have seen similar patterns for their own Anycast deployments.
So what this talk is about how should operators do I Anycast register in underserved regions that experienced problems.
What is Anycast. Anycast is the practice of making an IP address available in multiple points of presence. And how do you do this? You announce this prefix using BGP as you make your servers available in multiple locations when someone connects to your prefix they will be routed to one of of those POPs. Why would you do this? Well, it distributes load amongst these POPs. It improves resilience so if one of your POPs go down they can simply route to a different one. And it also reduces latency because of its geographic distribution.
It's widely used. So, a lot of critical Internet infrastructure is deployed using Anycast. And the main example is the domain name system, and we see the entire hierarchy of the DNS makes use of Anycast. So to give one example, the route letters all deploy their servers using Anycast and combine the route, or nearly 2,000 sites.
But the problem is that there are some regions that are underserved so they have limited IXPs and limited content delivery networks that deploy there. So this map shows the IXPs, so we see that there is a lot in Europe and then in the US, but in other regions like in Africa where, the Pacific, there is limited number of IXPs.
And we see similar patterns for content delivery networks that often do not deploy as much in underserved regions.
We also see this in our Anycast consensus. If you look at the places where Anycast operators replicate their services, we see lots of them have presence in the US, North America, Europe, but other regions are neglected.
And in this talk, I will just focus on Africa because this is an underserved region that also suffers from colonial routing.
What is colonial routing? This is something that's still seen from ‑‑ this is because of limited peering between countries and these countries rely, often rely on summary cables to connect with each other and unfortunately these summary cables follow colonial history so former British colonies, they are connected with a single submarine cable and this goes to London and the former French ones are connected and there are submarine cable goes to Paris for example.
And the Anycast perspective here is if you you have networks in former French colonies you will see them route to your pop in Paris and British ones would go to your pop in London.
And to make this problem more difficult, if you are an Anycast operator and you do invest in infrastructure in Africa and you deploy for example in Nigeria you might still see that former French colonies would not respect this POP and would route to Paris.
So, this was all theory, do we actually see this on the Internet still happening?
.
So how do African networks route to our Anycast path? We looked into this. I want to note that these results are deployment specific and they might be different for different operators, but it does give some insight as to how colonial routing and under be served regions connect with Anycast.
So, our Anycast test bed has two points of presence in Africa. One in Lagos and one in Johannesburg. And first off, looking at the latencies that networks experience we see that the median RTT is almost double in Africa compared to the global RTT. Obviously it's not surprising because we have a low number of POPs in Africa, but then again the majority of operators don't either so they likely experience the same problem.
So, next I will be looking at the catchments, so catchments are the set of addresses that route to a particular POP. Each pie‑chart indicates a set of networks that route to a particular POP and the size indicates the amount of networks.
They are coloured by the POP that they route through so. The first, the brown networks all go through South Africa, the red ones go to Nigeria and we see that these are former British colonies that route to Nigeria, which is also a former British colony. If you look at the original networks that go to Paris we see a lot of former French colonies route to this point of presence in Paris rather than the one we have in Nigeria for example. So that's a big issue.
If we look at the ones that route to the UK, we see that there is very few of them, this is lightly because we do have presence in former British colonies so they do ‑‑ they route to those instead of routing to the UK.
And if we look at the runs that go to Frankfurt we see Namibia which is a former German colony, this also exemplifies that colonial routing is still possible.
To conclude. CDN deployment is sparse in underserved regions. We also see this where Anycast operators place their POPs. Our preliminary results show that there is poor latency for these networks towards Anycast infrastructure. And that colonial routing further harms this. The problem with these results is that it's our test bed and it's maybe not that interesting, and that's why we are here to ask: Any other Anycast operators to look into how these underserved regions route to your network, perhaps you can share data or you can collaborate with us with our Anycast test bed.
Thank you.
(Applause)
ANNIKA HANNIG: Thank you. So, any questions?
AUDIENCE SPEAKER: Hello. This is Lars Liman from from NetNod, operators of Anycast network for route name servers. Thank you for a good presentation. Your observations are quite enlightening with what we see. There are reasons for these problems to deploy mainly in Africa, and we see not only the problems that you describe, but there are political problems that make it difficult to provide the same type of Anycast service that can be provided in other regions. There are monopolies, there are political control of telecommunications, and it's also a problem with maintaining good relationship, business relationships and social relationships with local hands, as an Anycast operator you need local assistance, and there are good people there, absolutely. But they tend to move around a lot. So, suddenly they are not there when you need them and they are somewhere else doing a good job and that makes it also more complicated but thank you for a good presentation.
REMI HENDRIKS: I agree that these are problems and it's nice to document these to make people aware of them.
ANNIKA HANNIG: All right.
AUDIENCE SPEAKER: Benedikt Stockebrand. I spent some time in Africa 25 years ago, and not for doing IT there but there is two things I want to say. First, if you take a look at the map, there is some countries in there, you know, big place like DRC or Botswana who are basically empty, so Botswana for example is right of that the red box. Will these are frequently inland ‑‑ what do you call ‑‑ inland, so, they don't have connection to the sea, no connection to sea cables. The situation should be more difficult there, and then there is one other thing, when you talk about Africa, it makes a lot of sense to consider South Africa as a very, very, very, very special case because everything is different there than anywhere else in Africa.
REMI HENDRIKS: Thank you.
ANNIKA HANNIG: All right. I think we have time for one last question and then I have to cut the queue. Please go ahead.
AUDIENCE SPEAKER: Thanks for some of the things that you pointed out. I just wanted to shine a little light on the commercial aspects so it's not just the colonial side and this is coming from someone who does infrastructure in the area. Sometime you put in infrastructure somewhere, people follow where they get their Internet connection from and they are less likely to try to come back to the neighbouring country if they have got a sub‑sea cable going to Europe. Now, it is the case that nowadays people are figuring out that oh, there are exchange points clear and even though it's more expensive to get a sub‑sea connection between two neighbouring countries, for example, in west Africa, there is a lot more capacity there than whatever it is and better latency connecting. So things are improving. Thanks.
REMI HENDRIKS: Thanks for the back.
ANNIKA HANNIG: Thank you.
.
(Applause)
.
For our last lightning talk today, I want to welcome Niall O'Reilly. So, he will ‑‑ he needs no further introduction from my side I guess. He is our former deputy RIPE Chair and long time contributor to the RIPE community.
NIALL O'REILLY: Thank you Annika. Yes. This is not going to be nearly such a good presentation as the previous one.
We'll skip that one. It just acknowledges property rights because the Programme Committee warned me I needed to know about that. Annika said I need no introduction but I noticed, I was paying attention when Mirjam was speaking in the Opening Plenary, there are 174 people registered on site for whom this is the first meeting. So, hello, I am Niall O'Reilly. If you see me around the coffee place or at the meal times, say hello.
I have been working for the last ten plus years in micro enterprise called Tolerant Networks. We'll say more about them in a little while. I'm also be talking about the NLnet foundation and the EU Commission because I'm talking here about taxpayers' euros being used for something useful like FOSS.
And the use case for cascade funding is this: If the funding agency, that's to say the European Commission has requirements that don't suit your organisation for example the process of prepping a proposal is too heavy or the budget is mismatched to the scale of your project, or the timeline for sending in the proposal for responding to the call for proposals somehow is challenging for to you reach, then the Commission have thought about this and they have let some of these projects through a cascade funding mechanism where instead of calling for a proposal for concrete development projects, they call for a proposal for a coordination project and then the coordinator acts as an umbrella for the subsidiary projects and announces perhaps more frequent calls for proposals so that meeting the timeline is easier to do. And also in the case of the projects ‑‑ or the frameworks I am going to talk about, offers support services to the people doing the development work.
So, for example, what Tolerant Networks does here is we have connections in the RIPE community and in the IETF and people doing the projects who want introductions to those communities, that's the service that we add. There are our kinds of services like code auditing. Localisation, accessibility and so on, each of which have their own niche partner which provide partner which provide optionally support for people doing the work. If your team is really very small and you don't have the scale to have your localisation department or your compliance department or your code auditing department, then you can look for help through NL foundation to get one of the partners to do this for you.
The coordination involves more frequent calls for proposals, the coordinator does the assessment and the disbursement of the funds and is able to match their requirements because they are more flexible than the European Commission to suit the target community and get more engagement. So we're talking here about the horizon Europe programme. The previous one was called new generation internet and the new one is called open Internet stack. The project scale is in the range of a budget from 5 to €50,000. And the projects must have a European dimension and you have to go and read the fine print to find exactly what that is, because this is a lightning talk and I'm not going to attempt to cover all the ‑‑ I'm not sure that I understand all the nuances in the requirements.
So, what I understand by European dimension is that the project, as proposed, should offer something that's of interest to Europe, and the composition of the project teams must also have a European dimension because there should be the lead, a lead or a significant role in the project consortium should be European, and that doesn't necessarily quite mean Member States of the EU, there are other authorised countries. And it's also possible for outside countries of those lists to be part of a consortium for a project.
Again, you need to read the small print yourself and at the end we have the links.
At the moment there are three active funds under the next generation Internet programme. And under the new open Internet stack programme, NLnet foundation, not labs, that's different, sorry, sorry Benno if you are in the room ‑‑ that's going to be called Restack. And the crucial thing, a useful thing here is that the submission deadlines happen every two months. So if you miss one, you are ready for the next one.
I think I have covered most of the rest of that slide already.
So, here are the funds which are currently open. Three of them in the new generation Internet's framework. And OIS Restack should open next month if I understand the plans.
Stephen and I, Stephen is my colleague in Tolerant Networks, he is the person with the IETF connections. We're both here at RIPE 92. You can find out all the small print on the NLnet foundations website, you can see the URL there. The announcement of the OIS Restack, I think if you download this presentation from the meeting side you can actually get a clickable instead of that long horrible thing and you can read more about horizon Europe and all the more political aspect of the, of the envelope around this in the EU's website. I think that's it. I hope I haven't overrun Annika.
ANNIKA HANNIG: No. You haven't.
NIALL O'REILLY: If there are questions, they are welcome. If not, find Stephen or me around the place.
(Applause)
ANNIKA HANNIG: Thank you. I think we have at least time for one question.
AUDIENCE SPEAKER: Benno, NLnet Labs. You already corrected it, but just to make sure, NLnet foundation and NL labs are two different organisations. NL foundation write a code and NLnet foundation write cheques. Remember that. Remember that.
ANNIKA HANNIG: All right. Thank you. And with that, I am wrapping up this lightning talk round and thank you all, thank you all big applause for all our speakers.
I think this was the last session for today here, and I am getting off stage now. I wish you all a great and pleasant RIPE 92 and see you around.
(Coffee break)