RIPE 91
Routing Working Group
21 October 2025
11 a.m.
.
IGNAS BAGDONAS: Hello everyone, Routing Working Group is about to start.
BEN CARTWRIGHT‑COX: Hello everybody. I think we're going to get this session started. Welcome to the Routing Working Group. These are your lovely Chairs. Almost in the correct order. So, what are we doing today? We have a great line‑up. We have five talks today. We have SIDN Labs, assessing feasibility of routing security complying tests. We have Tim Brussels giving us an update about ASPA. Orlando is giving a thing about what happens in the over share? And James from Interlink is giving us a great talk about rewriting BGP original attributes.
.
You will need to log in, so log in now, rate our talks. This fact authentication is great, but it means it's fiddley to log in. Log in now, the session persists for the rest of the event. It would be great. Last time we had about six ratings per talk again. We still is want more, it helps us improve the programme by knowing what you want to go and look at and what you don't, or what you less want to look at. Rate the talks.
I also have been informed that I should read out the following:
.
If you are registered to vote in the NRO NC elections please remember to vote by Friday at 9 a.m. You can chat with your NRO NC representatives from 1:30 to 2 o'clock today, today and tomorrow at the meet‑and‑greet desk.
IGNAS BAGDONAS: Just one small thing, the minutes from the last meeting, they have been officially approved and archived, so that is now an official history.
BEN CARTWRIGHT‑COX: Okay, I think we can move on to our first talk now:
LISA BRUDER: Welcome everyone to our talks called assessing the feasibility of the routing security compliance tests. We both work at SIDN Labs, the research team of the Dutch domain registry. We mostly do DS research of course but we also started doing some more BGP research in the last two years.
Quickly about us, so Moritz has ten years of experience as a research engineer at SIDN Labs. And is also, as some of you might know a co‑chair of the DNS Working Group at RIPE. I only started at SIDN Labs about a year ago and I mostly focus on BGP security. Everything around RPKI, ROA, BGPsec and other things.
So, why compliance tests?
This work or this study is a collaboration with MANRS, they have been working on an elevated tier, called MANRS+, there is a working group for this. If you have any further questions on the Working Group itself, I think Andrei just entered the room, so for more questions on the Working Group, feel free to reach out to Andrei.
In this Working Group they settle on a so‑called control matrix that includes various controls on several different domains that AS should adhere to to be classified as MANRS+, one the domains is called the routing security domain, and within that domain, we have several controls that are classified as ‑‑ they should be measured in some shape or form. So this is kind of the question that we were approached with. These routing security controls, can we measure them with a higher assurance level, meaning that we want to be sure that controls are actually implemented by the AS we're testing and not for example like some neighbouring ASes.
For this, we used it as a starting point to do a feasibility study in the local test bed to get a view of is this possible to measure? How could we measure this? I set this up locally first to get insight into that.
So, MANRS+ routing security controls is where we're talking about there are I think eight controls, four of them are measurable and we chose to measure because they are kind of measurable in a similar way. You probably will be familiar with with how some of these work, I am going to go through them quickly. About origin validation of course, we want to make sure that the AS that we are testing properly filters based on that origin validation, so only forwards announcements that are either based on are they valid or unknown.
Secondly, we want to make sure that the AS does prefix filtering, so any announcement they receive by customers should be based on a wide list of prefix that is could come from authoritative IRR databases but also other means.
Thirdly, we want to make sure that the AS that we're testing does not ‑‑ does it reject all announcements that it gets where the origination AS is not in an AS‑SET. So, we're also looking at AS‑SETs here that are based on some data source like IRR database. And we want to make sure that only announcements are forwarded where the origination AS is an AS‑SET.
And lastly, we also want to make sure that only, that bogons are filtered and not further announced to any other ASes.
So, looking at the prototype. Everything you see here is based on containers, we chose Containerlab because it just makes the orchestration of such a network prototype easier, we can specifically say which links we have, where where we don't want any connections, and we use BIRD as the routing Daemon in these local ASes that we have in the prototype.
So starting off, we have is so‑called CP AS, that stands for connectivity provider. In the MANRS spheres basically describes that AS provides transit services to customers through peer transit relationships. Will so, we set a kind of fake CP AS up as our prototype. And this CP AS then has two BGP peering sessions with a MANRS+ customer, and a MANRS+ peer AS. These two ASes should be treated, and are treated, in our prototype, as a customer or how a peer would be treated.
Lastly, and this is only necessary in our prototype, we have some additional components, one being a local RPKI set up, and a local IRR database just while running the tests and validating makes it easier to manipulate the data without having to change the objects in the global RPKI, for example.
So, this is the prototype step. These are the containers, the connections we have. And I want to walk us through one of our example tests that we scripted for our prototype, in this case being for the second control I mentioned which was prefix filtering, and one much our scripts orchestrates this test. So, by adapting the route object in our local database, so we disallow a certain prefix that we want to later announce. The then we enable the import filter on our tested local AS. We use BGP Q4 for that so we query our local IRR database, adapt our prefix list and use that as an import filter.
Now, we actually announce the prefix that we just disallowed from our MANRS+ customer AS.
And lastly, what we want to look for is we start looking at the RIB of the MANRS+ peer AS and we want to see does the prefix show up or not. In this case if we don't see it in the RIB of the peer AS, we say okay this test was passed.
And this is kind of the intuition for a potential auditing measurement infrastructure that we're going for here. And before we go into more how could this work on the Internet with ASes, I want to recap that the different parts here that are actually relevant for a measurement infrastructure that we would want to use. Of course local RPKI IRR are not necessary because they already exist.
The CP AS would be one AS out there that want to with get tested, wants to get the MANRS+ badge, and then the main measuring infrastructure are these two ASes configured by MANRS+ that would serve as these the infrastructure that would announce prefixes stop announcing prefixes and also monitor hard test actions how they react to these announcements. With that I am going to hand over to Moritz.
MORITZ MULLER: So, from our tests in our test bed we can conclude that testing the implementation of these controls reliable and reproduceable manner works. However, these tests have been performed in a test bed. So we of course also thought a bit about what things do we have to keep in mind when implementing these tests on the Internet?
And on this slide, I want to walk through some of these pit physicals that we have identified.
In our test bed information in RPKI and IRR are propagated immediately, so I adjust information and you can expect it also. The BGP, the control plane is updated quite immediately, but of course we all know that on the Internet propagation of RPKI, and especially IRR information can take sometime for RPKI, I think some papers showed that it might take roughly an hour or so. For IRR it really depends on how often you update your route filters. So this is something that you have to take into account when scheduling these tests for CP on the Internet.
Second, in our test bed we only tested one single CP AS at the same time, but of course we hope that soon many many ASes would like to get this MANRS+ badge, if it will happen. And for this reason we have to make sure that we actually measure the AS that we want to measure while not needing new resources, new ASes, new prefixes for every single CP AS that we want to test.
So here you have to make sure that at the MANRS+ peer AS you observe the incoming updates before best path selection algorithm hits. For example using protocols bike BMP that have been mentioned a few times already this week, so to reassure that the announcement you are seeing is coming from the AS that you want to measure.
Third, it could happen that when a CP AS is not implementing a certain control, that the test prefix could propagate unintentionally to the wider Internet. Of course it's a test prefix, so it's not being used in production so the impact should be quite limited. But we think it's probably good routing practice to withdraw the test prefix as soon as you can say whether a CP AS has passed or failed a test. Also you could make sure that you maybe include some communities if the CP AS supports them, to not propagate the test AS to other peers besides the peer ASes of MANRS. If this test prefix propagates further, then it might also be nice to document that you are using this test prefixes for this MANRS+ test so that researchers and other operators know what's going on and why they see these weird announcements.
Other things that you probably have to keep in mind that these tests are somewhat based on trust. So, you are assuming that a CP AS is implementing the same controls for your peering sessions that you are using for MANRS+, also on all the other peering sessions that they are doing. So, if you do not want to rely on trust only, we recommend that you should still measure the implementation of these controls independently, just like we are doing currently for MANRS already, using third party monitoring tools.
And lastly, in our test bed, we assume that 1 AS has one single router, but of course the reality is more complex than that. If you want to do these tests on the Internet and you also have to think about how to measure this as well reliably.
So, how to continue.
We recommend that we run these tests with ASes on the Internet with public prefixes with public resources, and I guess GCM MANRS is very happy if you would like to collaborate on that, so that we make sure that the assumption that we are having was actually holds when you implement these tests on the Internet.
Also, MANRS+ has this control matrix, and they have even more controls. So I think there are more than 20 different controls and they also include things like DDoS protection services, or routing information hygiene, and we recommend to see how you could monitor the implementation of these controls as well.
This brings us already to the end of our presentation. We would like to hear feedback from the community. So we performed these tests on a test bed, we thought a bit about how could you deploy these things in the wild, but you as operators have probably way more experience and know what would hinder the deployment of these tests on the Internet, and we would like to hear if you come up with these problems as well.
Also we would be interested is if you can come up with other ideas how to measure these controls other than the approach we are proposing.
Second, we have implemented now this test bed, it's OpenSource, it's currently relatively specific to the MANRS+ use case, but we think that it might be useful also for other use cases as well, so for example for testing your own implementation locally, for training purposes, so, if you have any ideas how to use that, we are happy to hear about it as well. And any other feedback is welcome to us, or I guess to Andrei as well.
If you would like to hear even more about this, then you are welcome to join the MANRS community meeting, 12th November, which is an online event, where we will give extensive presentation and if you would like to read more, you can find a public report as well.
With that, thank you for your attention and are there any questions?
.
(Applause) Hi. Shane Kerr. SIDN run its own networks, have you tested this on your own public facing production ASes and stuff?
MORITZ MULLER: Yes, correct we are running it on our own network. We are a sop AS. I guess many of these controls only partially apply to us, so ‑‑ but we haven't tested this approach in this way, but we of course monitor what kind of stuff we are announcing.
SHANE KERR: This is a question, because I am ignorant of MANRS. MANRS applies to all ASes, right? Okay.
MORITZ MULLER: MANRS does, MANRS+ doesn't at the moment.
SHANE KERR: Okay, interesting.
AUDIENCE SPEAKER: Tom Strikes, CloudFlare. I am a bit confused on how you are going to do the measurement side of things from any given ASN, given that you need to have a direct peering adjacency with every single ASN that you are measuring. So at that point, you fairly quickly hit scaling limitations I am assuming.
LISA BRUDER: In the prototype I only talked about direct peering connections. But we also have separate topology for multi‑hop BGP sessions. We did test it like that. You need some connection of course but not a direct peering link.
TOM STRICKX: I mean that point if you have a transit ASN in between the ASN that you are wanting to test and your measurement platform, then you are not realistically viably testing the measurement ASN you are testing either the measurement ASN or the transit ASN. If you have AS1 and AS2 and you have your measurement platform, then if you are only connected to AS2, the only thing that you are testing is either ASN 1 or ASN 2, not ASN 1 on the one side, right, you are always doing the Superset. Do you have like any solution to that or any kind of understanding of how you might be able to mitigate that?
MORITZ MULLER: We do recommend to set up these test ASes at points where you have a lot of connection. So, popular IXs come to mind of course. We did test remote peering with which you could circumvent this to some extent. But this also has limitations.
TOM STRICKX: You should have a chat with that guy.
AUDIENCE SPEAKER: Andrea. First of all, would I would like to thank you SIDN Labs and specifically you two for this work which helped us to progress in our work on MANRS+. Thank you for this this project. And now we are preparing for the, sort of test bed in real life, right, playing with real prefixes and playing with real autonomous systems. So, if people are interested both to play around on the auditing side, on this blue ASes what in the presentation were MANRS+ ASes, and both to sort of test their own infrastructure and monitor their own sort of routing security controls, I'm here the whole week so, please find me and we can discuss this further. Also, if you are interested in learning more about MANRS+, again I am here, please find me in the hallway and we can discuss this. Thank you very much.
(Applause)
IGNAS BAGDONAS: No questions online, let's move to the new talk then. Tim from RIPE NCC will be talking about what's happening with ASPA.
TIM BRUIJNZEELS: Thank you. Hello. I work for the RIPE NCC. I present at these meetings from time to time. So you may have seen me before.
I want to talk about ASPA in the RPKI dashboard. I want to start by explaining what ASPA is. If you attended the last meeting, then you probably heard me talk about this already. I'll try not to bore you and explain it in a slightly different way, but if you haven't seen that talking about ASPA in the RPKI dashboard will not make a whole lot of sense. So, I need to go through this. So, you know, if you know all this stuff, bear with me.
ASPA. I am showing this because you can forget it quickly. An ASPA object, how it's structured is very similar to a ROA object. So, in the sense that it is a signed object in the RPKI, and essentially where ROAs are signed by the prefix and say this prefix may be originated by this AS number, anybody else's AS number. This is signed by the holder of an AS, where they say, my AS can be the customer AS to this specified list of providers.
This is then used in validation, and the easy validation is when you want to validate paths that are received from customers by a provider. So if you are a provider and you have a session to a customer, then the path is analysed by looking at each hop in the path, and each AS to AS hop can then have three outcomes if you look at ASPA. So it can be, the next top had been provider, it cannot be provider or it cannot be no attestation essentially, that means there is no ASPA.
The draft, and I'll have some links later if you really want to know the full validation algorithm, differentiates, but the algorithm differentiates between valid, invalid and announced state. But it's only invalid that we really care about that you say beats something you want to reject.
A path received from a customer would be invalid if there is any occurrence of a not provider in that path sent to you.
That's proven unexpected. You do not say if a path is unknown, you would not reject it because in that case partial adoption would not work, then everybody would need to sign everything at once, which won't work. Also if there is an issue with the RPKI itself and don't have data, ten that would feel closed and resolved unlimited issues, so you don't want to do that. Essentially you want to have a positive message from your system that says this is clearly not good and then you reject it.
So how does this look? Let's first say somebody is being evil, in this case AS5 is path spoofing, that prepends AS4 and they announce a prefix for, you know, in the name of AS4. For which there is a ROA and based on route origin validation this would be okay. AS1 in this case while they know that AS3 is one of their customers, AS3 doesn't have to issue an ASPA object for them to know this, but in any case on that session the expected everything is either provider or no attestation and they say okay, AS4 to AS5 is not provider so this is not good.
A more common case might actually be this, where you know AS5 wasn't being evil but they were leaking. And in this case AS4 and AS5 are lateral peers. AS5 is not supposed to propagate this prefix up to their provider but they do. And in that case AS1 can still catch this. So, as far as the validation algorithm is concerned, it doesn't matter what the intent was if it was malicious if it was a mistake, it flags these things as invalid.
Now, if you want to look at other routes, things can become a bit more complicated because routes that you receive from your provider, well, you know, they are different.
So, in this analysis, the idea of valley free routing is used. So, valley free routing. I tried to describe it as such. You can describe announcements as going up hill from their origin up from customer to provider links until they hit an apex, a single peak, that can either be a peering relationship or a transit provider, for example. And then downhill again through providers to their customers.
Announcements that go up and down and up and down again have a valley in the middle and these are considered harmful because they make ‑‑ they can cause latency, congestion, too much traffic over certain links, it can add costs and there is also come security concerns because your packets might end up going where they are not supposed to pass.
If we draw a topology and have arrows with points and relationships, like we say stop provider Tier 1, then we can kind of reason about this by looking at it. But the challenges of course how do you apply this to a BGP path that you see in your router? It would have to have information about all these rules and it's not trivial. The big spoiler here is that ASPA helps in figuring out what the different roles are.
So, how does ASPA then find valleys? Again, theres a valid/invalid and unknown state for the total outcome of the validation. And in this case also, like I said before, you do not want to reject unknown, because that would result in issues if there is an issue with RPKI itself or if you have partial deployment.
So we're really looking for what is invalid, where do we clearly have a valley. The way this works is that it tries to make the longest possible path looking from the origin of hops that could be a provider. So either a provider or no attestation until it hits a point where there is a statement saying no provider. The same thing is done from the other end and then the algorithm takes figures out if these two paths meet.
So, if they meet at adjacent peers, and this is okay. So peers don't need to declare each other as providers, they can appear next to each other. They can meet in a single point, so a shared provider. Or they can overlap with multiple hops. This may happen in case of partial adoption because if there is no information you can go all the way from one end to the other and back again. But it can also happen in more complicated relationships.
So, say for example, another AS is usually a lateral peer, but in certain circumstances they can also act as a provider n that case they would also be included as a provider on ASPA.
If there is a gap between these paths, then there is a valley, essentially, and it's marked as invalid. So to show this more graphically here, we have something ‑‑ well this would be okay. This is valley free, it goes up and down only once. This would be a leak by a lateral peer. So in this case, we have information given by ASPA that AS3 is not a provider for AS2. So, if you go up from the origin we can say AS5 to AS2 is okay, AS2 to AS3 is not okay. We have this fragment AS5 to AS2.
From the other side, AS4 is validating here, they can okay, okay, AS is my provider, but AS3 is not a provider for AS1. So it stops there. There is gap in the middle, and therefore it decides this is a valley, this isn't valid.
Similarly, you can have this when there is a route received from a transit provider and then leaked to another provider, it works pretty much the same way. Of course you can talk for much longer about the corner cases, I don't want to do that here. There are some links here though, if you want to read more, I recommend reading those. The verification draft talks about everything in detail of course there is also the ASPA examples that talks about specific examples, unsurprisingly.
Formal proof. If you are into that, I'm not, but I am happy it exists, some people look at it. You know, have a look if you are into it.
But with this out of the way I want to look at ‑‑ okay, so we kind of have not hopefully a grasp of what ASPA is, how do we now use it?
In the dashboard. So, first of all, I want to ask you all to help us improve. So, we have this running in our test environment, pilot environment as we also call it. The link is here. It's also on the slide if you download it. You can try it out here. It uses a separate trust anchors, anything you do here does not affect your production network, it's safe.
We really like to know what you think.
In addition, we are actually running user tests today, so, we have at least one booked already, Antonella is sitting there. I will also be there. If you want to do a user testing session with us, then please scan the QR code or click the link, and book yourself in because we would very much value your feedback on how we have ‑‑ how we have done this.
So I'll just show briefly how it looks. When enabled, in this case on the pilot environment, in the overview page you get an additional card. So where we used to have BGP announcements in ROAs, we now also have ASPAs, and it tells you where you are ASPAs or not. If you have and any changes relating to ASPA they also appear.
When you go to your overview page, we could have done something where we say okay you have no ASPA, so empty list. But in this case, most members and end users really only have one ASN, some have two, some have three. Very few have ten. So, what we decided to do is organise in a way where we just show all your AS numbering that you have and then tell you whether you have ASPA for it or not. If you have no ASPA defined, it says no ASPA defined, create one. When you create one you don't get to choose the customer AS number here, because you do it in the context of that AS number. This is also important because the ASPA specification says you should only have one ASPA object per customer AS. This is how we use this flow to also make it more natural to you to keep it all in one place.
Well, once you have this, you can just add numbers. Review it and apply it.
So, if if you are used to the ROA interface, you will know that we give additional information in that interface. So we look at BGP information from RIS, and we tell you what might be valid or invalid or not found when you apply your changes. In this case we don't. We don't tell you who your providers are. There is no suggestions, you really need to figure this out.
I'll get back to that.
So, if you do this, which provider should go on your ASPA objects? Well, all your providers, but not your lateral peers. That would be very difficult to scale and access where you have a large number of changing peers, so you don't need to do that. But if they can act as your provider in certain cases, then they should be included. And also if you use a non‑transparent route server, you should include them because they will appear as a provider in the path.
Why would you create these objects? Well, the sales pitch is protect your network against leaks and easy path spoofing. Also help other networks because more deployment makes validation better. The more information you have available, the better the algorithm can figure out what is right and what is not. Or in particular what is not right.
When should you not do this? Well, if you are not sure who your providers are, they change all the time. If you cannot keep this in sync with your operations, then probably the wider choice is not do this because you might shoot yourself in the foot later. But I guess that applies to everything. But I think it's important to point out because when we ‑‑ well many many moons ago, when we first deployed ROAs at RIPE NCC, we had little guidance and we had many people put in ROAs that didn't actually match or keep up with their operational reality. So this was a real issue then and I am hoping that we can prevent that here.
ASPA in the router! So signing is all nice but then how do you actually use this in routing decisions. For this the tool chain is pretty much the same as what we had for ROAs and ROV. Well with updated components. And it essentially is the RPKI CAs, on the RPKI dashboard that creates the signed objects, they are published, they are then validated and then there is the RTR protocol that then transports this information into your router and the router itself doesn't have to do any Crypto. So it gets the validated content so it can just do an analysis of the origins in the case of ROV, and of the paths, without having to do signature checking or signing or any of that stuff. This is good because it allows this to run, in Inn were, on modest hardware.
What are the next steps? Well, for us we would really like to deploy this through production, most likely after the IETF that's happening two weeks from now, but of course I mean we ask you for feedback. If there are blocking concerns coming up in any testing, then we will address those before we release this.
What else? Is there more signing options besides what we do? Yes, there is, it's already supported in Krill, so if you run a delegated CA you can do this already. I know that ARIN has support for ASPA signing in their test environment. And the Number Resource Organisation, the NRO, so that's the coordinating body between the RIRs, has an RPKI programme where we coordinate on RPKI, unsurprisingly, there we set a goal that each RIR will support ASPA next year. So, this should be coming also in other regions.
A question that I have for you before I ask you to ‑‑ open the floor for your questions to me, is this suggestion or suggesting providers, is that something that is actually useful. It's something that we could look into but it's not trivial, and that's also why we haven't done it. We could try to suggest providers based on BGP paths, but the trick is that unless we really know which way is up and down, or where up and down ends, we end up suggesting that you add your customers as providers. So, we need to avoid that, and there might be ways to do this, like we could assume that a well‑known transit might be provider free so that might be where the apex of the valley free analysis would go to determine where the direction inverts. But it's assumptions. It can also work based on more ASPA information, once that gets deployed because that can also help us figure out where things end. But probably at best this will be incomplete. Probably what we can achieve at best is that we say. Well it looks like you might be forgetting this provider, are you sure you don't want to include that?
That may be valuable, but it's a question to you, because in the end I think you probably know who your providers are. So maybe you don't need that help. Maybe help is actually counterproductive. So, this is really a question that I don't know the answer to, and I'd like feedback from you on how we should go forward with that.
And with that I come to the end and would like to ask for questions and comments.
(Applause)
.
AUDIENCE SPEAKER: Tim, my name is Nathalie Trenaman, AMS‑IX. Used to be in the training team of RIPE NCC, used to be in the RPKI team of RIPE NCC, awesome work, this was long in the making. I also want to thank Antonella for all the UI stuff, it's not easy, but I also learned that in the early days what you said with the ROAs, there was a lot of unreliable, to say it in the best way, in the worst way it would be total crap, that was coming into all the ‑‑ it was getting polluted really quickly because people wanted to do the good thing but didn't have the idea how.
So, your valid question is: Do we need to know more about the providers? I think what is most important is the good UI, the helpful UI, because that helped also with the ROAs. But also a lot of hand holding from the get go, do one or one sessions at RIPE meetings, at MENOGs, etc. Plus include it in the training courses, make a video thingy out of it, all that. It's the combination of, and the UI and the hand holding and providing information about providers, because I think for its hard core RPKI people who run their own repositories, this could be ‑‑ basically they see this coming, but for the rest every help they can get is needed. Good luck.
AUDIENCE SPEAKER: Hello. James Bensley from Interlink. Great talk. Thank you very much. Two items, they are linked, but they are also subtly different. First one is, please don't bother trying to work out who people's upstreams are, it doesn't work, you cannot infer this from the control plane. A hundred percent impossible, you can get quite close, but a hundred percent impossible.
So, what I see is missing; so the ASPA stuff is quite new and we're already making mistakes, it would be great if this could get fixed. For example, it's too black and white. AS1 is the upstream of AS2 in Europe, but in America they are peers. You can't just say that the relationship between these two ASNs is provider downstream. It will vary by region. This already exists today, this is a complexity or a case that's already missing from ASPA. So, I think that's a kind of a flaw, let's say.
TIM BRUIJNZEELS: I think the ‑‑ well yes. I guess so. It depends on how you look at it. My understanding is that the people that design ASPA decided that in that case you just add anybody who could ever appear as your provider. Even if they don't appear as your provider in every case.
JAMES BENSLEY: Then when they may open the door to leaks. The other problem I see is large DDoS providers, so there has to be a record that allows my DDoS provider to announce my prefixes, very large DDoS providers who provider service to lots and lots of customers. You know, eventually announce my ‑‑ as a customer, they announce my prefixes like one percent of the time just when I am under attack, but the record will allow them to announce my prefixes all the time. And for large DDoS providers that would be a large amount of prefixes across a large amount of ASNs, so really we're like authorising those route leaks to happen.
TIM BRUIJNZEELS: So the comment from behind as that's the point of the DDoS providers. It's not. A common problem with DDoS is they announce latency. I don't want to announce my prefixes when they are under attack.
BEN CARTWRIGHT‑COX: Sure, but once again you have a contractual relationship with that party.
JAMES BENSLEY: Yes, we can discuss.
BEN CARTWRIGHT‑COX: Speaking as BGP tools and not the Routing Working Group Chair or co‑chair. So, I would not recommend, my business depends on a wholly piece of code that determines effectively upstreams. I cannot stress enough how much you shouldn't do that. I am not going to say that my code for doing this is bad and the entire process is faulty. However it is fraught with danger and I spent so much of my life in that area of my business. It is just not worth doing. Your idea of suggestions of after they add the numbers you go hey, did you potentially miss this? Is actually a good idea. I like that idea as terms of a failure prevention. But I would not recommend giving people numbers upfront because they will almost certainly say yes, add all and then they'll forget one of their backup providers or whatever or hidden backup providers are surprisingly common. So I would strongly recommend not suggesting to people upfront and making them think what contractual relationships do I have. Inevitably, what I suspect is going to happen is either people will going to forget their DDoS mitigation providers or forget their hidden backup. I have a step that people have vote a phone as a backup for their office Internet connectivity. When it goes away, Vodafone springs into action. Obviously if it's not there and you suggest it's not there, that's a problem.
TIM BRUIJNZEELS: Indeed, initially when there is not a lot of validation being done you wouldn't even notice. But when people start to validate. That's when you'd find out that, you know, stuff breaks.
BEN CARTWRIGHT‑COX: It may be worth ‑‑ one the things that I'd like that RIPE does is they e‑mail you when there is a supposed ROA hijack for the route validation. That's probably something that's quite valuable during a turn‑up period as everybody starts to implement it, be very aggressive in telling people when there are violations because that will help avoid the previous problem of people flooding the database with potential crap and causing a bunch of problems downstream on implementation. But I would like to also point out thank you so much for this effort. It's taken a really long time. But I suspect ASPA will make a huge difference to the global state of affairs. I am happy that RIRs are now actually finally doing this and we have gotten closer to the finish line. We're not there yet, but we are so close.
TOM STRICKX: I am going to basically just copy what Ben said. Thank you very much for doing this. Also, if you are doing the mandatory RPKI talk, so that good.
Two things. One, ASPA is still in draft. How long is that going to take? Because two or three years ago, it was yes, we're final draft and we'll get next IETF meeting and it will be an RFC, and we're two years later and it's still not the case.
TIM BRUIJNZEELS: Yeah...
TOM STRICKX: Second, again, do not, do not do the provider thing. Just do not. This is ‑‑ RIS is great, but RIS has a massive selection bias for Europe, and kind of the US, which means that any international network like the network I operate, you are not going to see any of the impact stuff, and that's the only thing that you are doing is finding a shotgun, loading the shotgun and then handing it over to your customers. Bad idea. Don't do this.
The idea of like, hey, you probably missed this is definitely a hundred percent please do. That is a really good thing. I think it's arguably the best way of going about this. The example to the ROA side of things, it's a lot easier to figure that out because you have the visibility of what the origin ASN is, it's easier to solve. Just no. Other than that, awesome work, thank you very much, I look forward to using this and causing a major outage in the next couple of months. So thank you.
TIM BRUIJNZEELS: Regarding the status of the Internet routes, there is remaining discussion on three drafts. Well, basically on one draft in particular, which is about the updated router protocol, and it's actually about how the ordering should work for ROA information, not even ASPA. But that seems to have quietened down now. There was no more discussion on the other drafts as well so that's also why we feel save that the syntax won't change again or the way that the validation works. And if we look back we actually deployed ROAs before they were RFC as well. So I think we are in a good position to start doing this.
AUDIENCE SPEAKER: AMS‑IX. Compliments to you for your work, I really like to see the progress and also compliment to Antonella for the nice user interface, very nice. I want to go back to ‑‑ I mean similar to what the other people have said and also to Ben about the proposal of you proposing okay this might be your upstreams and you are going to validate. I have spent many many hours troubleshooting what data up RA streams but they seem to be my upstreams, but I know my relationships and these guys are not my upstreams and then I go and say okay, why is that? And then starting mailing people and why it's happening and why you guys are my ‑‑ advertising my prefix. So it turns out to be that it's not that these guys are upstreams of me, it's just advertise everything to collectors and there is an issue with the RIPE RIS because you said I have got the take the information from RIPE RIS. But also with route views and other public collectors, people just advertise everything that they have in the RIB to the collectors but doesn't reflect the reality. So if you go and take this information and you say, I am suggesting you that you have those upstreams and somebody accidentally says yes, put them all in ASPA. Okay, that's not going to work, right. So, there are lots of false positives with the collectors, that's the message I want to say. So maybe also with your BGP tool, so people advertise a lot of stuff on collectors in general, but doesn't reflect the reality what's happening. So I think I will say what Ben said: Do not propose this immediately. But maybe should be like a notification later on, we also see this as being your transit. Maybe you should check because I see this in ASPA and I see this in RIS. So something might be wrong.
TIM BRUIJNZEELS: Thank you.
IGNAS BAGDONAS: Last call for any questions. There are no questions.
GEOFF HUSTON: What happens with ASPA if you are my provider in IPv4 and I am your provider in IPv6?
What if it's mixed?
TIM BRUIJNZEELS: Earlier drafts made a difference between IPv4 and IPv6. That was removed essentially to keep it simple. If you can ‑‑ if I can be your provider and you can be my provider, then we should both include each other essentially. Otherwise, you know, it will only work one direction, or no direction even.
BEN CARTWRIGHT‑COX: There is one other question, sorry one other comment from Antonio that says "If you can't list your providers, ASPA isn't your next step, inventory is.".
TIM BRUIJNZEELS: Yeah, I think I also put it on the slide, if you can't make this statement, then it's better to not say anything.
One thing, maybe to confuse people a bit more, if you really ‑‑ if you don't have any providers, if you are in that business, you can make an ASPA object that says "AS zero is my provider" and that's the only one, but, you know, most of you don't do this. Will
TOM STRICKX: I think it will be very funny when Tier 1s don't start doing this and need to start explaining that the transit free networks aren't actually transit free.
IGNAS BAGDONAS: All right. Thanks Tom.
(Applause)
.
Now our next talk.
ORLANDO MARTINEZ‑DURIVE: Hi everybody. So, this is my first RIPE meeting. I am happy to be here, and what I will do for the next few minutes is talk a bit about this work that I did during the time I was at Cisco ThousandEyes. For this I want to start with this scenario, assuming that we are the Orange robot, it's a router, you are starting this BGP session. You are green in the chaining paths and everything it fine. Somehow kind of a little bit of magic you to set a limit, and that limit is 10. Okay.
So, some time passes by, everything you might get new customer, acquire new IP space, normal things. And then when you go back to your BGP session later, now you are 1 prefix, not 10 path but the limit was ten, so here the router has the choice then can I just accept this new limit and have more or can I just drop the session? Because we made that agreement at the beginning.
So, what happened is that by default I have Cisco routers, that is their behaviour now dropping the session. So, then this has this issue that if you forget to somehow tell your neighbours, your peers, that you are increasing, then that session is going to be dropped.
The fundamental issue here for me is that, as you probably know, is that there is not the right ways or automatic way to share the prefix limit. How much your neighbour should have spent from you. Of course there are approach like using peering DB, but also even sending e‑mails and calls, but this is not a standard. So that is an issue.
And then we have this, because there is not a standard we might have a data configuration, we just grow it organically but then other peers didn't know that, and when we we start sending more prefix numbers, they drop the session. I have basically these two questions the other one that we tried to answer here. First question how often does this happen? How often ASes go beyond the limit? And how critical is it for the connectivity?
so, in order to answer this question first I needed to get a bit of data and getting data about the maximum prefix limit is really hard because as I mentioned before it's not standardised. But this those a network demonstrator, they make an entry and sometimes they also fill this field here about IPv4 and IPv6 prefix. In this case for this AS it's 64, so you should expect 64 prefix from this AS. So you get a snapshot for 6.5 months, the first half of this year, but also I want to know what happened with the number of peers and what happened with the number of prefix that every AS is advertising over time. So for that we use data from RIPE RIS you and we are looking at the RIBs dataset for that. So 6.5 months and we have this three data source.
There is a small issue. Just by looking at PeeringDB, that not everyone makes an entry in PeeringDB. So, when you look at all the ASes that you can configure just by looking at the RIBs from RIPE, there is around 88,000. But then all a small part of that, they have PeeringDB. Then PeeringDB also has this field of the last date. So when was the last time that an a demonstrator made a change here. It is not very often updated here. Only 18 percent make a change in the last two years. So, that might be okay if your network is not too complex, but still, making a change in two years is a little bit weird. So for this analysis, I would like to focus on this 16,000 ASes that they have in PeeringDB so I can know the maximum prefix limit and also I know they are kind of freezing.
Let me put an example of this, combine all this data, how this looks like. So one AS, in this case, the green line should be read from left to right, and the idea here is that this AS starts with around 30 prefix at the beginning of the year and then at some point it decided to increase that amount of prefix a little bit more. Okay. As you can see of course there are some drops, but because this number of prefix it is maintained over time, this looks pretty organic to me. It wasn't a miss configuration, they just have more prefix.
Then we have this orange line here that is the maximum prefix limit that they were announcing in PeeringDB. You can see that yeah, a little bit after the increasing the more prefix, they also update the maximum prefix in PeeringDB, but there is a small gap there now. How do you fill that gap. So just because they were a little bit late and there was a small delay between updating the maximum prefix that they lost more that 100 peers, so now on the right, in that moment of time. Of course as you can see a situation pits not very fast, but it wasn't immediately.
And then how bad this can be? I mean losing peers might have the consequence that you are having some routes, also means that the peers that you are losing, they might be very important to you because they are the only one giving you connectivity to some part of the Internet. So it's kind of critical.
Let me address now this question: How often an AS goes above the limit? So I am making this breakdown between IPv4 and IPv6, and as you can see, in most of the cases, for the 80% of the ASes that we were analysing, they almost never, they never go above their limit. So that is nice, you make your limit and you stuck to that. Then we have all these grey area in the middle that are ASes that they closed the limit for and they will go a little bit over the limit for a few days, and then we have this also weird cases where they are always above the limit. So, I am kind of more interested on the ones that are in the middle, so the ones that go up and close a little bit of the limit.
What happened with these ASes when they do that? How many peers do you lose on average? So, again, the plot is the breakdown before an IPv6 and what I'm showing on the X axis is the percentage of the peers that you lose every time that you were crossing that limit. So, again, it's not a pretty picture because you will lose so many peers but in some cases that can be a long string and you can lose, 60, 50, 80% of your peers, and that might have a meaningful impact in your connectivity, traffic may change and everything else.
.
So, I would like to finish with these few takeaways. On the positive side, we don't see that many ASes did cross the limit. So the Internet is working, everything is fine.
Then on the kind of other side, when they cross the limit, they have this drop, and I don't know how important are the peers that you are losing, maybe a lot, might be not. That's an interesting question that we'd like to check out later.
I would like to leave you with these few questions, is there something that we can do because at the end of day we are just talking about sharing a number.
So, this number can be shared in a standardised way. That is my question. Can we change the limit every time that we do a BGP session? Can we change the limit on the open message, or maybe not, but we can just have a common platform that everybody agrees to use and when we update our limit, just let the peers know, so everybody keeps in sync about the new limit that we have.
Finally, this idea that of course if you are configuring your own AS or somebody's AS, hope for the best but prepare for the worst and then remember to set the maximum prefix limit of your peers just slightly higher.
With this, I would like to finish my talk and I will be more than happy to take any questions. Thank you.
(Applause)
IGNAS BAGDONAS: Any questions? So far we don't have anything... oh, there is something online.
"Is the relationship between the size of a prefix and the max limit defined in PeeringDB?"
ORLANDO MARTINEZ‑DURIVE: No, I think not. It's how many prefix you are advertising, it's not depending on the size of the prefix.
IGNAS BAGDONAS: Well then a round of applause for our first time attendee presenter.
ORLANDO MARTINEZ‑DURIVE: If later you want to talk, you can find me around.
IGNAS BAGDONAS: Right. Then our last talk.
JAMES BENSLEY: My name is James. Thanks for having me and thanks for the time.
So, I work for a company called Interlink and we sell IP transit. And that means that we bring up lots of BGP sessions with our customers and peers and we exchange routing information. And it will be no shock to this audience that the routing information includes an attribute called the origin type, the BGP origin type attribute, and this is defined in the RPKI as a well‑known mandatory attribute. And the origin attribute is generated by the speaker that originates the associated routing information.
So the AS that puts a prefix into BGP in the first place sets the origin attribute to tell everyone how did they learn about this, this route, this prefix. And there are three possible values. IGP, means that the AS that put this information into BGP, the information ‑‑ how did they know about this? Well the information came from internally within their AS.
Another possible value is eBGP, which means the prefix was learned via the EGP protocol. So, not eBGP, but EGP, which is fully deprecated.
And incomplete is the last possible value. Which means they are not really sure how they know about this prefix. So in reality, IGP normally means you put something directly into BGP, like a network. Incomplete means you redistributed a static route or something like that.
EGP, like I said, deprecated those. So you should just see IGP and incomplete as the only two origin types in BGP.
So, last month, about 930% of prefixs have the origin type IGP. 9 or 10% incomplete and there is several routes with the type EGP. And that various, if you look at different networks, somewhere it's about 85 percent IGP. For some it's at as much as 95%, it fluctuates a bit but this is like an average across different networks.
There is about 300 ASNs, about 2 thousand prefixes that have the EGP origin type. I e‑mailed a bunch of them, just looked up their details in peeringDB, send them an e‑mail saying you are sending these prefixes with origin EGP, which is not EBGP, why is this, all the ones that responded said the same thing. Which is this is the Kay they configure their customer announcements, so customer routes are tagged with EGP, but also this is a legacy configuration that they should not be doing anymore, thanks for pointing this out, we'll get this cleaned up so. I am just curious to know that was like five people responded to me from like 300 ASNs, if anyone here is originating prefixes with the type EGP, please let me know why because I would love to know why. Even the people that responded and said this is why we do with customers. That doesn't make sense.
So the only thing you need to know in the concept of this talk then is that the origin type IGP is more preferred than incomplete. When we're talking about the BGP path selection process, AS path length and so on. We work down the algorithm, eventually we get to origin type. IGP more preferred than incomplete.
And the RFC says that the origin type should not be changed by any other speaker. So, you know where this talk is going.
Here is a prefix that we are learning from a peer. So you can see the AS path is one hop long. We get it directly from the peer, and the type is incomplete. The least preferred origin type.
So, how many of the Tier 1s do you think are rewriting all the pricks that they advertise to be origin type IGP? At least one. At least two. ‑‑ this guy says ‑‑ too many. Correct, I'll take that. Too many. I will get you a free drink from the free bar later. The answer is approximately half. So, I took a full BGP table feed from all of the Tier 1 providers, looked at all the prefixes they are advertising, one the ones that say yes they are basically having 99 percent of their prefixes origin type IGP.
And so the one I posted on the previous slide, the prefix I mean, at the back of this slide deck, if you want to play along, at the back of this slide deck, there are screenshots from every single LookingGlass for all the Tier 1 providers showing that they are the ones where it's a yes showing that they are rerouting the prefixes to origin type IGP, because not everyone has access to full table feeds like we do. So I wanted to make sure that you can see is publicly. You can.
These guys rewrite it all. And we asked them, we asked them why are you doing this. One responded that we may normalise the origin type to ICP when processing or aggregating done. This is done to ensure consistency in route propagation and to align with your internal routing policies. Bullshit so far.
They continue "While the RFC states that the origin should not be modified, the use of should not allows for exceptions when operationally justified."
The last sentence, "In our case, this normalisation helps maintain route stability and predictability across our global backbone."
So, what I'm reading from that is either you have some sort of fluctuating origin type or some sort of weird instability in your control plane that I can't quite fathom. Looks like BS, smells like BS.
Another one responded to us as well same useless statement.
So I think the real answer is, they do it to win on the path selection process. So, I send you some routes, I rewrite the origin type to make sure if we get that far down the BGP path selection process, I will win. Back to us, our network has been running a few years now. At the beginning when we built it we had the discussion: Will we modify the origin type? No, we don't do that. We also had the discussion will we use LocalPref? We are strongly against LocalPref. It's unfair for customers. I can explain more on that later. That's not okay, we are a transit provider, we should be transparent, we are not modifying it.
fast forward a few years, we have had more and more customers complain that they aren't sending traffic through us but they want to be sending their traffic through us, so they got us and one of the other provider, usually a tier 1, when they compare the route, they look down and they see the other provider is rewriting the origin type, and it's not in anywhere in their product documentation, peering policies, on their website, nothing. But it seems that there is quite a number of networks, not just Tier1s, tier 2s, that are where he writing their origin type and don't disclose this anywhere. We are going to start rewriting the origin type because we are getting a significant number of complaints now that traffic isn't coming to us, it's affecting our customers it, it's going somewhere else and they have packet loss, congestion, whatever, they don't they want to send it to us. We will also start doing this, this is basically a zero sum game, theres no change in the traffic volume, we're pushing around the same traffic but between different networks. We will provide an opt out feature. Any customer or peer of ours who doesn't want this, you just e‑mail support at Interlink, it's a flag per BGP session, we'll just turn it off. We will roll is out in the next few weeks and months and it will become default.
But the point is, we want to be the first major transit provider to point out this that stuff is happening. People are doing things to manipulate the BGP path algorithm that you may not be aware of. We are going to have to join the boat because we're getting no end of complaints from our customers. But we will provide and update feature, it will go in the product documentation, we will make sure that it's clear. I think that's the way, if you are going to do it that's the way you should go about doing it.
This is basically a form of strategic convergence, if my competitor pulls a lever, I don't, I lose, so I have to pull the same lever. That applies to everyone who has an ASN.
There is a second part to this is that if actually everyone starts doing this, we deprecate the attribute. I think it's fair to say in 2025 the BGP origin type has absolutely no value what every so. In an age where we just inject routes directly into the RIB for an API, what what would the origin type be? It's pointless.
One more little nugget. I said at the back of the slide deck there is a bunch about of screenshots from all the different tier 1 LookingGlasses showing how they are rewriting the origin time. Something that popped up during this exercise was that some networks have got two /8 space as their route IDs, and in the BGP path selection process the lowest router ID wins. These guys have all got space in two /8. No one is announcing space in one /8. So, if you have space for one /8 on sale, see me after.
That's it.
.
(Applause)
AUDIENCE SPEAKER: Thank you for this presentation. I am Wolfgang Tremmel. I actually handed in a similar one which was rejected, but I only asked the question, you provided the answer and thank you for that. My answer was merely about the EGP attribute I see in the routing table. I saw a large number of prefixes as Google as an origin and I also never got an answer why.
SPEAKER: Just to add a bit more to what you said. That small number that are tagged EGP, some of them are quite important prefixes. They are customers coming to us saying we're sending like ‑‑ I said it was like less than one percent of the whole DFC but this in terms of bits and bytes customers are saying we are sending a non‑trivial amount of data to these other guys, it's not a good path. It's not to be ignored.
BEN CARTWRIGHT‑COX: I first have to sort of comment to the room, I love that RFC thinking out loud of the should not is a fantastic use case of creative interpretation. I am truly in love with the logic there, hats off to whoever did that. This has been happening for a very long time. The annoying thing with deprecating the DHCP origin attribute is because it is a mandatory attribute we will never truly get rid of it because if you advertise a route to almost all routing Daemons without it it will shut down the session. Maybe if you have enabled the correct options it won't. But regardless it will be treated as a completely invalid route. We will never truly get rid of it but I do think it's probably great to make it irrelevant.
You are right, it has no use case. There was probably a future where we could have shooed in more the protocols into t there is 255 potential protocols. We could have originated from OSPF. How useful would that have been? Then we could finally settle the score on whether OSPF or IS F is better or babble or something. Super interesting talk, thank you so much for the data. I would love to know who is ‑‑ who gave you that should not response because that's truly legendary and I would love to buy their RFC reader a beer. SPEAKER: I think later on outside I'm going to have a bit of a cough.
PETER HESSLER: In my career I have worked for several small providers and it's always been standard for them to rewrite the attribute because exactly as you pointed out, everyone else does, so, this is a super common behaviour I have seen in the industry from all those not just Tier1s. But one thing I wanted to comment on, your customers complaining about rewriting the origin, are you referring to their prefixes or the prefixes that you announced to the customers?
JAMES BENSLEY: Sorry, they are complaining that the prefixes we are sending to them have the unmodified origin attribute and the other other streamers modified is so they are sending traffic towards that prefix via their other upstream and the other upstream hat lost let's say packet loss or congestion.
PETER HESSLER: Okay, because what I have ‑‑ when I saw this in the past I just rewrote it myself. That's a fairly easy thing to do.
JAMES BENSLEY: I said it in one the slides, when we first set the network up a few years ago we had a solution about shall rewrite the origin, we went through the discussions. On the origin one we said no. And one much our very first customers, who took a default route rather than a full table, said our other upstream sent us a default route origin type IGP, I said that's your problem mate. Just prepend the thing you received from them or rewrite it on your side or increase the MED, you can fully sort it out on your side. Not my problem. But it just, as time has gone buy we get moron more support tickets with people having exactly the same complaint. It's getting to the point now ‑‑ also touched on with Wolfgang, the amount of traffic also is getting quite significant as well as the number of support tickets which is overhead for us. So it's kind of getting to the point where we can't really ignore this anymore.
PETER HESSLER: Standard violation of RFC is customer inter band ‑‑
JAMES BENSLEY: We thought we could tell everyone, document it and provide an opt out feature which I think nobody does.
WILL VAN GULIK: Actually, Peter, like took my comment and so I had exactly the same situation with like an ISP who didn't consider what was the implication of rewriting the origin. And so, I will thank you again and I will actually implement the opt out thing on my network whenever I can, because that's really, really good and clever I think. Thank you very much.
JAMES BENSLEY: So there is two sides. With my day job hat on, obviously we want to rewrite stuff because we are losing revenue, right. But with my private personal hat on, I don't approve, and so, I will make sure there is an opt out feature, yeah, yeah.
AUDIENCE SPEAKER: Blake Willis. Thank you for this great research and really helpful in terms of getting sufficient moved internally in the networks that I work with. In the past I have always tried to take a light touch approach. I have rewritten origin code but only in cases where it was needed. Have you considered giving your customers like either an opt‑in or opt out community so that you will rewrite origin for everybody but here is a community that enables you to not get it rewritten, or vice versa. That's the thing I was considering on the networks I was working on.
JAMES BENSLEY: I refer to my previous comments with the two different hats. With my private hat on I wish this would be an opt‑in feature. With my professional hat on the problem is two things happen. A lot of people just won't opt‑in but just open support tickets. Why isn't this working. So kind of hasn't fixed my support case issue. The second thing is from the business side of things, why do we not make it opt out.
AUDIENCE SPEAKER: I would lean to opts out and here is a community just in case.
TOM STRICKX: Thank you. It's a really good case of showing that transits are in a race to the bottom and this is very much a race to the bottom. I'll point that you don't technically need to open any of the IP space that you set at your router ID. There is also no way of validating this. There is no way of filtering this. You can do whatever the hell you'd like. Just a comment, right.
There is utter shenanigans happening within the routing table, as Ben also does talk occasionally about nonsense he sees.
There is ‑‑ we occasionally get in the Routing Working Group in the mailing list we get reports about shenanigans in the routing table. I would encourage that we may be it would be helpful to get these kind of levels of reports going where it's like well somebody is rewriting origin, some people are doing AS path tidying. I think naming and shaming is arguably the only way we can get anything done in this industry. So, please more naming and shaming. Thank you.
JAMES BENSLEY: Good comment. Thanks. I would just kind of add one thing. It's just that yes, there is a lot more shenanigans going on than this. I am just not quite in a position to comment on the other things yet.
AUDIENCE SPEAKER: James. I think three things. One that 0.0.0.1 is a perfectly valid ID.
JAMES BENSLEY: I have had this discussion privately already about the Router ID things. Again it's the same thing right. Business hat on, this is a brilliant idea. With my private individual hat on of "don't be a dick", then I think that's not okay, and I have to have a sort of ethical discussion with myself about what's acceptable.
AUDIENCE SPEAKER: The second thing is in terms of opt‑in or opt out. I am one of the people who have actually used things like EGP in the past as a more soft way of steering traffic than adding a whole prepend. I think it's probably a valid use case for that.
What I would say is if you default to going reroute to IGP, what you could do with Interlinks BGP communities is just like in the same way you have for different specific peers or regions or so on, add a prepend, you could have just a set BGP, set unknown, set IGP. Then you don't even need to have an opt out. You can just give people the ability to do what they want already.
JAMES BENSLEY: Valid point, I will write that down, thanks.
IGNAS BAGDONAS: Any other questions? We don't have anything online, so last call for the audience here.
If not, then a round of applause.
(Applause)
.
With this, this concludes our meeting. I think we don't have anything else. The messages:
So, there are various elections going on. So, vote for the Programme Committee. That's until Thursday,
5 p.m.
Then there is NRO election, if you are registered to vote for that. And you can chat with NRO representatives from 15:30 to 14:00 today and tomorrow at the meet‑and‑greet desk.
And another important one is, please rate the sessions here for the Routing Working Group. That's important. That's a feedback channel which tells whether the content that was selected was what you liked or you didn't like. Please vote and provide the comments, the more the better. Thanks a lot. And thank you for attending.
(Applause)
.
(Lunch)