RIPE 93
Main hall
28 October 2026
9 a.m.
Connect Working Group session
WILL VAN GULIK: Hello everyone and welcome, please have a seat. Welcome to your second favourite Working Group. If you are looking for OpenSource, that's unfortunately not us, we are connect. So, I was a bit lazy this time, sorry about the basic agenda slides. That's actually a screenshot of my screen, so, I am just saying.
So, we have quite a packed session today, as you see, we have got also a panel at the end that will try to make some room for that so we can have a good exchange also with the room.
We think that you all have read the meeting notes of the last session at RIPE 92, I would like to know if any of you have any comments. I am looking at the room. I don't see anything happening. Okay, then I think those are accepted.
What I was going to say... yeah, our terms are coming to an end on the next session. So, we will issue a call for a new Chair, if anyone wants to be part of the Chair connect collective, we will give some more details on the mailing list about that, so don't hesitate to come to us if you have any questions about that.
STAVROS KONSTANTARAS: Just to say that we didn't have yet specified exact details, but we will write a big e‑mail with all the details, the procedures and you can be informed in the mailing list, so keep an eye and maybe consider joining.
WILL VAN GULIK: Exactly. We are available if you have any questions. Just before we start our session, Marco had something to say.
MARCO SCHMIDT: Good morning, I just want to make a bit of cross promotion for the Address Policy Working Group session tomorrow at eleven o'clock, I have a regular slot about updates from Registration Services, and actually one update concerns the IXP policies that we have out there. And if you are interested, the slide is already uploaded, have a look at it and I would look forward to get your feedback tomorrow at my presentation. If you have any questions, you'll find me in the hallway. Thank you.
WILL VAN GULIK: Thank you, and with that, I think we're ready to start. The first talk is from our friend, who did some interesting work. Welcome the stage is yours.
ALAIRG LE LAY: Thank you, good morning everybody, and thank you for the slot. So, today we begin with some presentation of RS‑API, it's a software we use to auto configure the root servers on the IXPs we manage.
So, a bit of context on the French IXP ecosystem. The biggest one is France‑IX, as you know. It's mainly in Paris and in the bigger city of France and we are in the smaller. So, there is a west network at Nantes, which is one I founded in Rennes, because I come from here ‑‑ at Strasbourg on the east and at the north is where the story comes from.
So, at Lille we have a peer which has some customers. These customers has a customer which put level 3 into its AS‑Set. The issue we have is that level 3 doesn't feel its PeeringDB records so we don't have the never RS in the configuration because it's not there and I don't want to have a specific thing for anybody. This peer we have does the maintenance on its router. The router is off loaded as it's... but when the router comes back to prediction, the operator forgot some filters and sends us the full view of the Internet. Sadly, as the max‑pref was too high we accepted it not fully, but enough to have some issues is, but it shouldn't be the case.
So, in this case, as we accepted some late announcement, everybody, or almost everybody ended up shutting their sessions because our own max‑pref was exited, which was not so good, I don't like t and for the figures, here is the actual data we had. When you expand the AS‑Set, you have 200 thousand routes, the PeeringDB is at 50,000 and the actual imported on the route servers there is 400. There is way too many max‑pref configured compared to what the it actually should be.
In this case we looked at what we can do and we don't want our root servers to leak anything because we are supposed to be the state of the art of the rooting security and we can do it because we use, we can script everything. And we use this to avoid the situation to reproduce again.
We have some out of the box RFC stuff which we can use to make it work, but it's not sufficient and we have to make the configuration the same on four cities and on two route servers per cities. The out of box tools we are are RPKI with ROA and ASPA. ASPA is very important, I will come back to it later, but as it's not yet deployed we still have to rely on IRR and it's where the issue comes from. And if you looked at the new RFCs, the OTC also known as BGP rolls is very important, it's by default dropping the liquidity announcement, if you learn some route from the peer and announce it to another peer it will be dropped, it has to come from upstream and it's very important. And if you are using some generous boxes, you will have to implement the OTC to have ASPA filtering working on your site. So, begin with that.
Just to be extra sure, our errors accept an announcement if the OTC is not invalid, it's done by the root server by BIRD and open BGP, it's not our code, it's in the BGP D code directly. We also look at the Bogon list, the one from everything of. We drop the two specific months as everybody does on transit, and we, of course, looked at the RPKI status.
When we have to rely on the IR we generate the prefix list from the announce the prefix list from PeeringDB, we also looked at the AS‑Set by itself to accept Openflow the ASNs in the past. And we set up the max‑pref using the PeeringDB but it's not available because everybody can put anything into PeeringDB, for example, my ASN can pretend to be O T I and put in a previous, but we don't want that.
We want to look at the actual BGP data to have the IS cone size and to configure the IS cone size based on that. We use some co‑efficient to have some margin before that position which came from the M 6 configuration documentation, so thanks for that, it was useful.
And how do we get the max‑pref from BGP? We don't want to query the wrong BGP from our site because we can't tell if one of our peers has some customers or something to have a bias, so as we already have some connections with known guys in the community ‑‑ (thanks for that) ‑‑ we actioned for that some VMs on our fab I can so he can have some measurement, some listening packet, everything, so the features you know. And we also have BGP routes, thanks for that a as well, and we send them some BMP data in exchange for that, so it's just a friendship on BGP. Of course we don't want to be dependant on anybody so we have a something else.
At the beginning, it was only a basic Bash script running directly because it was only at Rennes and not everywhere else but it's expensive because we do API and we don't want to hammer the people that helps us, so we had to move to something else.
EVANN DREUMONT: Why our API? So, first, as was said we don't want to hammer the people that have helping us and the APIs are costly so we want to have a cost mechanism to reduce the load on their side. Also, because it's a lot of time the same data the cache could be helping us to generate way faster the configuration. And a Bash is critical, but, yeah, not that much maintainable, so going for Python could be a good move.
So, it's two part. One client and one API. There is a client will take a template, goes two things and generates the configuration. In the template, you can call the API and we have a layer of abstraction letting you call the service name earlier, and ‑‑ you could for example count the concern of As an the, even if you query BGP tool or BGP route, you will get the same response because of this abstraction and it's way easier. The response will be a session with all the data and we use the cache to cache things and not query the upstream if it's not needed.
So, we have a cache of 24 hours because we will generate a configuration twice a day at 12 for one RFC and at midnight for the other one. And it can be a bit ugly but you can directly call the API from the template, but it's convenient because we will generate some configuration from many implementations such as BIRD, open BGPd etc., and we want to have a way to call what we need in the configuration, because we will not have the same needs in function of the implementation and the generated configuration.
So, if you want to try, you can basically do a curl and invite the G Q and you will get this in return.
We have documentation available. You can take a look, but because we obviously don't want you to use auto caine, you will not be able to do the curl but let's take a look, you can see what you can do with the API and if you have any feedback, don't hesitate.
ALAIRG LE LAY: And to conclude, You want to automate the RS configuration because you can't be behind the keyboard for each one you have to do. The Internet is way too fast for that. We urge you to publish the RPKI and use OTC, it's what makes the routing a very secure thing. Without that we can't have anything that secure. You want to recompute the max‑pref because you can't trust PeeringDB, it's not ‑‑ it's just an information from the operators.
And we would like, as I know that some of you are also some RS operators, how on your side you do it because we are IXP and it's our solution but I think I am not the only one having that kind of issue. So
If we can also have some community standards for the security, it could be I think very nice.
Thank you.
(Applause)
STAVROS KONSTANTARAS: Do we have questions from the audience? I see someone.
AUDIENCE SPEAKER: Hi, Silvan from free transit in this case. We have had a similar incident to you except it was CloudFlare in our AS‑Set and yeah I screwed up the expert filter on my end and for me personally the solution was that we stopped accepting AS‑Set from our down streams only and we are potentially going to change the down streams can only bring their AS‑Set if they are ASPA valid.
STAVROS KONSTANTARAS: Any other questions? If no. I have one for you guys. So you said you want to deploy OTC or you didn't?
ALAIRG LE LAY: We checked OTC already and open BGPd because it's already.published as a public Curl and actually we already had some operators sending us routes which came from the France‑IX servers and they are also checking OTC so we dropped this thing. It was a static prefix list instead of community‑based.
STAVROS KONSTANTARAS: You managed to blog some prefixes that are being leaked from France‑IX on the way to you. That's fantastic. We have some similar experience as well. I have seen prefixes being leaked from other IXPs coming all the way to our route servers. Not so many of course, but the good thing that you can see the AS number of the IXP. Then you can ping people around and they can ‑‑ sometimes it's misconfiguration, so they can fix those things. Fantastic.
All right, do we have anything in the chat? Nothing. Then we can ‑‑ if you guys don't have anything else. Thank you.
(Applause)
STAVROS KONSTANTARAS: Now, our next talk. Would I like to introduce from Interlink for the next talk, a fascinating talk, which is going to talk about the end of prefix filtering. That's super interesting.
JAMES BENSLEY: Just one second. Hello. My name is James. I work for a company called Interlink. I want to talk about the end of prefix filtering. So, we use IRR based data to do AS path filtering and IRR based data to do Olympics filtering, and the question we think about recently is can we where he move increase prefix filters from our edge BGP policy. Where this question is is ROA coverage high enough now that we can stop using IRR a data for the prefix filtering just for the AS path bit just until ASPAs catch up. One the reasons we have been looking into this is because the RoI on the operational overhead on automatically generating and deploying prefix filters I believe is very, very low. So, we generate, we have to maintain an amount of infrastructure and process to automatically generate and deploy prefixes across the network continuously and it can go wrong and it generates support tickets. It's a huge amount of effort. Is it worth it?
.
The second thing is if we did take it away, would there actually be any degradation to us in terms of routing security?
.
I have put a little caveat there. I am talking about the 90% of cases, so this is not the special stuff like RTBH or FlowSpec or private ASNs, this is a bog standard 90% of prefixes and customers and peers going backwards and forwards.
So, I have done a three‑way comparison between what's in the DFZ and what's in the IRR and what's in the ROAs and the RPKI. There is no really nice way to do that because the same prefix will be in all three of those data sources in different ways, you'll have four /24s in the DFZ that will be documented at 2/23s in IRR and they will be a /20 with a max length of /24 as a ROA. So trying to compare these things is disaster, because people use the three systems differently. We have to take the numbers that I am going to show as nothing more as a guide, just a rough guide, this is roughly where we are, and also this whole presentation is a snapshot of a day in the life of a network so other time the numbers would change slightly but roughly they shouldn't change too much.
I am really sorry to the stenographers, I am going towing through these first few slides really quickly because this the baseline stuff that we all know already, just being the baseline for the later slides so sorry stenographers. Take all the prefixes in the DFZ, try to match them to IRR objects. For the prefixes that we do find, in the IRR, about 95% of them have a matching prefix origin tuple, so, 4 ‑ish per cent don't. Which is fine, there is always a number of prefixes without route objects or conflicting route objects. On the last two columns on the right, about 4 and a half percent of the prefixes in the DFZ we just couldn't match to a route object, also, pretty normal, lots of people don't implement prefix filtering so there is a bunch of prefixes floating around when there is no route object. Flip it around, try to take what's in the IRR, match that in the DFZ. There is one thing to note on the very far right. There is over a million v4 and v6 route objects that we can't match to anything in the DFZ because there are just millions of prefixes in the IRR, loads of historical data, etc. Decades old, so, that's something to kind of keep in mind for later. For the prefixes in the IRR that we can match to the DFZ, we have got 80% v4, 90% v6, of like tuple origin prefix matches. There is like 20 and 10 per cent that don't match. Which is also quite, would I say, I don't know if acceptable is the right word. Expected is the word. You have to have prefixes, you have to the route objects ahead of time before you need them. So I want my ‑‑ I want to announce something via nigh DDOS provider when I am under attack. The route object has to exist ahead of time but I am not currently announcing that prefix, so there is a bunch of route objects in the IRR where there is no current DFZ, or it's a different origin because I am not using that origin right now. So far nothing unusual.
If we now look at the DFZ to ROAs. It we go two slides back. Matching DFZ to IRR, there is a 95% correlation between them. It's pretty good. If we now look at the DFZ to ROAs, for the prefixes in the DFZ that we can find in ROAs, because if you look at the last two columns, 30% of v4, 20% of v6, theres no ROA. For the ones we can find, there is a 99% match between the prefix origin tuple in DFZ, if you look at the NIS dashboard, this is what you will see this. The only thing to point out is that we went from 95% alignment to 99 per cent alignment. It will basically never get better than this. It will only ever go down because as more people create ROAs, we will have the problem that people will forget to update them time to time. You'll never reach a hundred percent coverage. That's impossible, so this is as good as it can possibly get and the key point in this presentation is that it's higher than IRR.
If you flip it around and try to match what's in the ROAs in the RPKI to what's in the DFZ, the coverage comes down a bit, we kind of have the same as we have with ROAs. There is a whole ‑‑ with IRR. Theres a whole bunch of ROAs for prefixes that are not currently being announced. So the middle pair of columns, the prefix origin tuple in the DFZ do not match the prefix are origin tuple in the ROA. This has gone up because if we look at the DFZ we see prefix 1, 2, 3. It's coming from AS1 right now, there is a ROA for AS1 but there is also a ROA for AS 2, business your DDOS provider. It goes up in an expected way. It's just the inverse of the previous slide. There is nothing so far nothing so interesting, this is baseline stuff. The DFZ is closely matched to IRR data but there is a lot of old crud in the IRR. The DFZ is much more closely aligned to ROAs but ROA.coverage is lower than the IRR. There is also a little bit of cruft building up in the ROAs but not as much as in the IRR. The main thing to take away from those slides is basically where we find a prefix in the DFZ that we can match to a ROA, it's much more closely aligned than we find with IRRs. That's the kind of main thing, which I hope is kind of everyone knows that already. If you look at the NIS dashboard from time to time, that's what you see. So nothing too new so far. Flip it around.
Let's compare IRR to ROA data. If all the prefixes we find in the IRRs try to match them to prefixes in the RPKI and check the prefix origin tuples, and we have really good ‑‑ there is a 99, 96, 97% match theres with which is very good, it suggests to me that people who have ROAs are keeping their route objects up to date as well and keeping the two things in line. The middle pair of columns, the not matches is very low. The only thing is the last columns at the end, right. There is a number of prefixes in IRR that we can't match to anything in the ROA, because ROA coverage isn't as high as IRR coverage.
Flip it around, what if we take all the stuff that we see in ROAs in the RPKI, try to match that into IRR. The matches have could down quite a bit and the not matches have gone up. And the reason for this is what I said back near the start of the talk. The way people document this stuff in the different systems is different. So, there is a blue column, purple column in the middle, so IPv4, 83 thousand ROA prefix origin tuples couldn't be matched to anything in the IRR. Two prefixes account for basically half of those not matches. So comcast have 78 /8 ‑‑ they have 73/8, they have a route object for this /8 and they have about 22 more specific route objects under the /8. So an entire /8 is documented with 23 route objects. They have 16,000 ROAs under the same route object. Akamai have a /11 with basically the same thing. They have got 20,000 ROAs under a single/11 that's covered by about 10 or 20 route objects. They cannot be matched to each other in a nice way. So I think the graph is basically showing us the difference between the way people document the prefixes. And what a disaster it is trying to do this analysis.
.
I am going quickly because so far this is nothing too amazing. There were two graphs that basically give me the confirmation bias that I want that I could probably get rid of prefix filtering. The first was the one at the start. So matching DFZ prefixes to ROAs. The prefix where there is a matching ROA the prefix origin tuple has a 99 match rate which is up from 95% with IRR. The second thing is trying to match IRR data so ROAs on the right‑hand side, again is very high, so, what that says to me is, if I get rid of IRR data, everything I need is still there in ROAs, it's not a hundred percent, but it's very, very high. So the question I had earlier about would there be any degradation in routing security, it kind of suggests probably not. But we can't really guess, we have to do a bit more work than this, so we can now get onto the main core of the presentation as it were, not that I am hungry. Is ROA coverage high enough for me? If you operate a truly global network there are parts of the world where ROA coverage is not as high as it is here in Europe. We are very lucky that we have very high ROA coverage here and very good routing hygiene here, it's a a personal thing, your network, is it high enough for me?
.
The way we do prefix filtering, edge filtering is first we look at IRR based AS path filters, is this origin AS somewhere in the AS‑Set of my neighbour or customer? So is this an origin that is allowed to come via this neighbour or customer? Of course if no, we reject it, if yes, we move on.
Is it ROA valid? Obviously if it's no, we reject it and if it's yes we accept it. The question is what about if it's unknown, there is no ROA? We have to fall back to prefix the IRR based prefix filters. This is where the question of this talk comes in. Of course if it's yes, we accept. And if it's no, we reject. Of course, are we rejecting anything and why are we rejecting it? Why don't I just switch unknown to be accept, right? If I go back a slide, IRR prefixes, the bit where they reject something, that is potentially the value that they are giving to me. Like, rejecting a prefix that looks like a hijack. Otherwise I would just accept. So, the question is like how many prefixes are we rejecting and why because all the effort that we have to do to continuously generate and deploy prefix filters, that reject bit is basically the ROI in comparison to just unknown, accept.
Again, this is a snapshot of one moment in time across the whole network. So, earlier on in our edge filtering policy, we reject stuff for non‑IRR reasons. More specific prefixes, Bogon prefixes, Bogon ASNs, people trying to advertise our own space back to us, blah blah blah blah blah. So that's kind of a non‑IRR stuff that comes first. Then we get onto the IRR stuff. So the middle column we reject 2100 prefixes because the origin is not in the AS‑SET of our peer or neighbour, so it looks like a route leak, we have got a signal that this looks like a route leak. If it's in the AS path, we go to the ROA check, there is no ROA so then we go to the IRR based prefix list and so from two and a half thousand BGP sessions, excluding a handful of tier 1 upstreams, because on your tier 1 upstreams you accept a full transit table, no need to any prefix filtering there, that would be insane. So from 2,500 BGP sessions across all of our peers, customers, IXPs, we are rejecting 601 prefixes. That is an insanely low number of prefixes for the amount of effort it takes to generate and deploy prefix filters constantly across all of our BGP sessions. If we dig into the 601 prefixes, so the first two columns, 523 of those routes have no route object. And for me, it would be fine to accept those prefixes, because if they have no ROA and no route object, we actually have no signal that there is to reject this. There is nothing wrong. If there is a problem, all you have to do is create a ROA, you know, if this is a hijack, create a ROA and we'll reject it. But if you have no ROA and no route object, I think there is some amount of ‑‑ some onus really lies on the resource holder, there is no signal to us that there is anything wrong with this announcement, so why are we rejecting it? That leaves us with 78 prefixes from the 601, where we maybe have a signal then that there is genuinely something wrong here. A route leak or a hijack. If we breakdown the 71 prefixes, that's then the next two columns, 3 and 4, 74 of them have a route object but the route object ASN is not in our neighbour's AS‑Set so. What that means is someone has announced the route in BGP from ASN.1. AS1 is somewhere in nigh neighbour's AS‑Set so is passed the AS path filter, but the origin of the route object in the IRR is AS2. So, it hasn't landed in the prefix filter. So that is ‑‑ there is 74 prefixes but we actually have a signal, there is something wrong here, even if it's a route object or they haven't updated their route object or something like this or they are announcing for the DDOS provider they haven't create the route object for the DDOS provider. So from hundreds of thousands of prefixes we now have 74 prefixes giving me a signal that maybe we should reject them. The last four prefixes on the end, they are perfectly valid prefixes that have been added in between our prefix deployment interval. So on the next interval they'll just be accepted so I'm not interested in those, they are perfectly valid prefixes.
So 74 prefixes we are rejecting from, like I said, two and a half thousand BGP sessions and hundreds of thousands of prefixes. There is something I said earlier, which is of course nobody applies prefix filters to your tier 1 transit sessions, because you should be receiving the full table through your transits. So, the question is of course, of all the prefixes we reject how many do we receive via our tier 1 transits anyway?
So of the 601, we accept 513, and of those 513, 69 of them are that group of 74 where there was actually a signal that there is something wrong with this and we should be maybe be rejecting it. That just leaves five prefix that is we are rejecting then, that we have a signal that we should be rejecting because we we are just accepting them via tier 1 anyway. So everything we do to generate and deploy prefixes everyday and all that kind of stuff, remember rejecting five prefixes that the ROI on our network for automatically generating and deploying prefixes which to me is absolutely terrible. So where I want to go with this talk, the reason I am giving it, is, so we have done this exercise, we look to start rolling this out very slowly. The approach that I'm thinking of is add a kind of flag to all of our BGP sessions, we will start with peer that is we know are very good with their routing hijack and slowly tick it off and remove the IRR prefix filters and kind of slowly roll it out across all of our customers and peers. But the question is really like, at least for us, because I said this is very personal, it depends on where your peers are in the world and how seriously they take their routing hygiene. At least for us it looks like we are at this stage for us. I want to get the discussion going in the community. ROA coverage looks like it's getting to the point where we can start to remove prefix filters. So,s us as a community, I think we need to start having the discussion of like how do people recognise ‑‑ how do I recognise when my network is at this point where I can just switch to ROAs and don't need prefix filters anymore? What are the signals I am looking for? How do I go about it? Long term we want to move to ASPAs and ROAs and deprecate the IRR stuff but we're not really talking about when are we there, how do we make the transition, is my network at the point? That's kind of the point of this talk basically. Which I hope was useful, we did the analysis, it looks like we are there, if we are there other networks must also be there. How do we as a community move forward? Thanks very much, thanks for your time and your attention.
Applause)
STAVROS KONSTANTARAS: James, thank you very much. It was a fantastic presentation. Before I give the microphone to the people to ask questions, I would like to commend on the topic that you had on the topic regarding the ROA coverage, if there is any degradation in the security. We have done similar analysis with Daniel, who is sitting over there, and we examined, but from the route server perspective, we noticed that when we were using RPKI objects and not IRR object, mostly for configuring filters, we even gained new prefixes because the IRR data and RPKI data are not always aligned as you correctly have spotted in your analysis. So, in some cases, we got extra prefixs from our emulation. I would say, I don't think there is much degradation actually. You might benefit out of that. Let's give the microphone to the people.
JAMES BENSLEY: I want to respond. I fully agree. I think one thing is actually, the thing about ROAs is because we typically reject ROA invalids, there is more pressure on people to keep their ROAs up to date. Lots of people don't implement prefix filters, so lots of people have out of date route objects or no route objects and there is no ramifications. So, yeah, I think kind of the switch to ROAs is actually hugely beneficial.
STAVROS KONSTANTARAS: Or they are very outdated? Some are forgotten in a third party database created ten years ago, but they created ROA objects like two months ago so they are very fresh. Okay. We have questions.
AUDIENCE SPEAKER: Jen Linkova. Very obvious questions, on your slide 19 when you have ‑‑ basically final data of prefixes you reject. Do you actually seeing any traffic to them? How much it contributes in terms of traffic? Because I guess it's what really matters, right?
JAMES BENSLEY: Yes and no. Because okay, there's two ways I could answer the question. How much traffic do we see to them? You could say on the one side we are transit providers so the amount of traffic is important because that's revenue. On the flip side, if I would say it like this, if they were really important destinations, like massive content providers, we would be flood with support tickets. So I have to assume that they are not very important destinations. So, I haven't done the analysis. It's a really good point, I will make a note and go away and do it but I have to assume that we don't get any support tickets about missing prefix that is they are somehow not very interesting prefixes.
AUDIENCE SPEAKER: Gert Döring. Thanks for bringing this. It's important. It's actually why I am in this room and not in OpenSource. So credit.
I disagree with two of your assumptions. One is that if you have no signal, it means you can take it. I would say if you have no signal, you have no authority to take it. But that's just a minor side thing.
The bigger thing is using the number of rejected prefixes as an ROI indicator. Because that is not really the point. The point is network hygiene and that is more towards your customers like us. We are stupid, we make mistakes all the time. And I think on the transit ISP side it is still important to have prefix filters towards the customers. Peers are different, but as long as we have like 300,000 prefixes in the DFZ that have no ROA, if you just open up your customer filtering and say everything that's unknown goes. The customers are free to do whatever stupid thing they feel like doing. Then how much that thing is there. So, if you have a peer and you have on good authority that they're filtering their customers properly, you don't need to. But, on the clue level, the more clueful networks should do a good job in filtering, the lest clueful networks which are their customers and everything. So the answer is yes and no. Lateral yes, downwards no.
JAMES BENSLEY: It's a valid point because not all networks are the same. So that's why I said the way we are thinking about doing this is slowly rolling out. Start with the most trusted and see how it goes, don't forget we always keeping the AS path filter, so we don't just let ‑‑ there is still some protection there, we don't let people announce anything to us. It will have to be a learning exercise to see how we go and kind of...
STAVROS KONSTANTARAS: I don't want to cut people on the microphone but try to be a bit faster.
AUDIENCE SPEAKER: Sebastian Becker. I mostly second what Gert just mentioned. And I am very on the point if you don't have anything signal, don't accept it. Just because to get people actually doing the ROAs for that. I want to have that hygience. And for us, it's even important, we do filter our peers just because we did see such a lot of stuff that should not be there and actually lately, some of the bigger ones even removed the AS‑Sets which don't give us any good option to build something which, from my perspective, is a bad sign. We should do better, not worse.
JAMES BENSLEY: So, definitely a valid point. You and Gert both said about the you err on the side you should reject something if you think there is no signal. I am on the other side, I think you should accept it, why am I blocking someone's prefixes when I have no indication that there is a problem here? Like, do you want to err on the side of defaulting to having an open Internet or a closed Internet and all that person, the prefixes, if the prefix is being hijacked all they have to do is create a ROA and we'll reject it.
AUDIENCE SPEAKER: Assume that everyone knows what they do actually I want to. Is that bit of education necessary and it has nothing to do with wanting to have a closed Internet.
JAMES BENSLEY: That's a kind of a different point because also there is a question about responsibility. Who has responsibility to say if this prefix is valid or not and to act on that and to kind of, we don't want to be floating out loads of route leaks, that's very bad for business, so we don't want. The flip side, resource owners have to take some amount of responsibility for their resources. So having no route object and no ROA kind of at some point you have to draw the line and say where was this route leak our fault?
AUDIENCE SPEAKER: Tom Strikes. One question. Which IRR databases have you used for your analysis?
JAMES BENSLEY: Because we internally only used the five RIRs and the NIRs and this is on our network, so it's those.
AUDIENCE SPEAKER: I can imagine that if you started adding the delightful third parties you get interesting results. The second thing, even if you only start filtering your customers, if you look at the AS‑Set that would allow to import 2 million prefixes, kind of at that point your colander is a giant gaping hole, so at that point I agree with you like that defeats the purpose you are so then why implement them in the first place?
JAMES BENSLEY: Exactly. And I will be completely open, RAS is also a disaster, it expands to nearly the full table.
AUDIENCE SPEAKER: We exist in every single ASN, it's delightful.
JAMES BENSLEY: I have a second talk tomorrow about this exact subject and when I look four our AS‑Set trying to find those naughty customers who make the problem, the most included incorrect AS‑Set is CloudFlare.
AUDIENCE SPEAKER: Randy Bush, IIJ and Arrcus, thank you very much for this presentation. I have waited 25 years for it. One minor point. I learned last week filter your transit AS. The some newbee at a tier 1 upstream, some newbee in there decided that there was my peering from them was missing them sending me default and I did not filter default. And I had alarms went off. So that one quibble with that one slide. Do filter your transits.
JAMES BENSLEY: Yes, it's a two sided coin because if we wanted to apply filtering on the transit sessions, we would have to be pushing, generating enormous prefix filters and pushing them out significantly more regularly. It would really make the whole operating this stuff even more difficult.
There was a slide I had earlier, this section that comes earlier in our eBGP policy where we do non‑IRR filtering. We filter defaults, we filter bogons, we filter people trying to send us our own space. This is stuff that we should never, ever accept. Then we move on to IRR and ROA based filtering.
AUDIENCE SPEAKER: Silvan. My remark regards to go to ROAs do not forget the amber space that is unresolved with RPKI as to my knowledge ‑‑ 44 space amber is still unresolved if RPKI is to my knowledge so we still need to solve this before we go there.
JAMES BENSLEY: Valid comment.
STAVROS KONSTANTARAS: I think we are done. Give an applause to James.
(Applause)
.
Now our next talk.
ANDREI DINU: Good morning, first I'd like to thank you the people before me, interesting talks. And insightful for what we're going to build.
I'll present how we did our documentation, and why we started it.
So, we wanted self‑service portal, that was the goal. So our customers can do like self‑service because we love it, just click and order something, like I don't know, maybe a VLAN. We wanted our customers to see exactly what services we have available, how the network behaves, how the route server sessions looks like and because we have like a change, we wanted them to see the status of the TV channels and we wanted to allow them to request anything from the catalogue or change settings and trust that if they hit the apply, nothing breaks for us or of course for them.
So, we built a few systems. We did a BIRD control plane. It has a LookingGlass and templates for BIRD route servers. We did a No Signal live TV app that does monitoring, MUX, transcoding, live TV delivery and telemetry. And Lighthouse, which is the talk for today, which handles Nokia SR OS, Arista EOS and does automatic transactions.
So a few words about BirdNest is it's a template engine, we can render, preview, push, configs, it handles IRR and RPKI. It has its own validator and RTR. It also queries BIRD, it's a LookingGlass. There is an example of one of our customers which allowed us to show the name. And no signal, a fun name, because if a TV channel doesn't work, that's what you see, no signal. It started as a monitoring tool, it ended up doing all the work that behind delivering live TV from collecting everything to pushing it down the network. So it processes and delivers it and it's controlled via an API.
And again, the talk for today, it's Lighthouse. We started the IX like something years ago with some Linksys switches and then we converted to Cisco and then to Arista, which we still have a bunch of them, we use them as downstream switches and we do some Layer3 also on them. And then we said okay, it's time to modernise and go to EVPN and MPLS, so after a peer with Nokia they convinced us. You can work with us.
We needed the control of SR OS and EOS in the same place. We did this Lighthouse thing and it provisions both platforms and of course it does telemetry backups and all the things you would expect.
How it connects. So it reads from Nokia config state and telemetry over gNMI. Over Arista EOS, the boxes are like quite old and we still use SNMP with them, they work fine. And the eAPI for config and state. We collect flows using sFLow and from Arista and IP configs from Nokia, we store them in ClickHouse and then we can carry them. We collect logs and metrics, we store them in VictoriaMetrics and VictoriaLogs. The Lighthouse, it's based on Laravel. We use Redis and Horizon to do queueing locks and everything they did for provisions, so writing the configuration to devices which we use gNMI and NETCONF for Nokia and the eAPI sessions for Arista.
So, it has to do from connecting customers, so, connect one group, you have to set up ports, you need lags, you need Internet segments and of course you have to attach all the ports to different services for different customers. So, we have to handle Nokia service access ports and Arista VLANs and on top of them of course, we have to apply some filters and quality of service.
So, we use version templates every service that we provision is version template. We can go through versions by just simply changing some variables. We define different services like for example, the IX service which is our core service. Generate the configuration, they are validated by the devices before being applied, and then we go to applying them.
.
On top of the services you need filters, QoS multicast, you can apply any number of filters, there is an example of common IX filter which you drop the RT BH and you only allow v4 and v6. We have to handle multicast because also in one of our core service it is TV delivery in Romania at least.
So, to apply everything we built a system that supports atomic multidevice transactions because it's all or nothing. If any of the devices fails, either validation or I don't know becomes offline during trust anchors or if anything breaks, we first rely on the device roll back timers and then if any of them breaks, we just allow them to naturally roll back to the previous configuration.
Everything that's, that we apply, is logged and it can be audited after that.
After you apply something you want to see what happens. So, we have a telemetry and topology map where you can watch life MoU the network behaves, or from traffic packets, opt will levels, device performance, you can look back at how it behaved before, and you can follow the service through the network. Will
.
We also implemented flows, as mentioned before, we call it IPFix and the sFLow. We store them in ClickHouse, it looks similar to what are others are doing. Will we store from sources to hand over AS, its service, its transit and then the hop AS and finally the destination AS. It also has, we are trying to do an attack detection using flows, so this is something in trial but it showed us some issues in the past days. So, it works.
And it stores config backups automatically, you can do this, it stores them on a schedule, so it's nightly backup and after every change. You can at any time compare any two configurations, and trace the changes and of course roll back to any of the selected config.
Because we had multiple issues when migrating through vendors we thought we needed a way to see deviations and the integrity of the network so deviations also means maybe I log in a router, and I change something manually because we don't block that, and whatever the Lighthouse controller handles I want to see it that deviated from our intended configuration. So, this allows us to do it and also we do integrity like for example, why would you have VPLS that only has one service access port? That's something that maybe you don't need or you allow a VLAN somewhere where it shouldn't be available.
Troubleshooting. After.you configure everything. If you see any issues or if you want to do manual changes maybe you don't want to log lock the devices, we added some troubleshooting tools like device log search, you can run diagnose and of course you can also open a terminal with the same privileges as the Lighthouse portal.
Because people from Nokia built a very nice tool, Containerlab, we thought why not try the changes in a twin network. This is not currently working with AIS afore us at least, so, we build a tool that allows you to clone your current production using Containerlab and S R similar into a Linux virtual machine, test your configurations, see how it behaves (SIM) if you are fine with it apply it in prefix. This is also something to allow us further automation in the future and rely less on people maybe.
Lighthouse is also features and external API which is how the customer portal actually connects to it. Of course it's 2026, everybody is using AI I guess, we thought why not make it AI available for like not only all it XCloud or any anything you might use.
We did that and we thought to try it in production. For example, here we asked for a customer report on services and usage. I also asked for a graph. It just didn't make it to the slide because it's too big, but it gave us a accurate description of what the customer was doing. Also, we thought to test how it can understand the network based on what we built. And we asked codex to plan a migration for a switch which was connected over two independent links. We want to connect it a ethernet segment. So we asked codex to plan a change and it spawned ‑‑ it delivered like a 16 page migration plan in 16 minutes and yeah, it worked actually. We tried it, step by step, and yeah, it works.
So, the Lighthouse now is in use at InterLAN IX. We have 10 Nokia routers, a bunch of Arista switches, about 100 services and customers, and it handles it quite correctly.
We do have some limits with it because we are a small company, we are, we don't like really need to do zero provisions, we don't always change routers, router switches, it happens rarely, but before you start using it, it expects you to have be configured devices. So management should be ready, IS, IS segment routing should be ready. For a twin you need a host pre‑installed. And we are planning to move further into AI assisted changes and to allow it to propose the changes and the human could review it and then if proved, just apply it. And add more tools in the lab like support, Arista, and BIRD containers to assimilate customers.
That's it from me and I would also be interested in what others are using because I am sure most of us do some kind of automation and I am hoping to start a discussion on that. Maybe we're not the most efficient ones but, you know...
Thank you.
(Applause)
WILL VAN GULIK: Thank you very much for that. That was really good. I loved the talk last time and that also worked really well. So, do we have any questions from the room? I mean it's a cool tool.
FRANZISKA LICHTBLAU: One question. You mentioned something that most people don't do. You said you were pushing rights with gNMI. What's your experience especially on Nokia?
ANDREI DINU: So we started with NETCONF, because I think until the SRS released 24.7, they did not support rolling back, so, they didn't have any sessions. We are not currently using it in production, I think you felt that. But in the twin where we run the new software, it works fine. So for us it's fine. I am glad to share it with you.
FRANZISKA LICHTBLAU: Let's have a chat later. Thank you.
WILL VAN GULIK: Okay, no other question. Then, thank you very much.
(Applause)
.
Then I'll open the floor to Remco who is going to present us a nice thing he did. Do you want this mic or the one there.
REMCO VAN MOOK: Thanks. Good morning everyone. I got a question from the chairs yesterday saying hey, we have sometime left on the schedule, can you do something? I said okay. Well here I am.
This is about building a global PeeringDB mirroring. This is a project I did earlier this year, and this is about cheap‑ass distributed systems. And what is the cheapest ass distributed system you can find, someone else's edge. This started with another project I did that feels like minimising package lists for Debian and Ubuntu releases. Then I had a conversation while I was in building that, that was came to PeeringDB and having to make your own mirror to make that do anything, and that was painful. I was like what if I can actually use this stuff for this thing for the other thing. The dataset of PeeringDB is certainly small enough and slow moving enough to do some fun things with.
So, what I end up with? The whole thing is built on CloudFlare workers and plus the DS database did a first version about a week ago. The one problem, if you will, with building anything in CloudFlare workers is you need to polish up your JavaScript, which I didn't think I'd be writing in 2026, and I initially just built the API, then added an automated pipeline because PeeringDB is a moving target and the schema and database changes every now and TCP then you want whatever you doing to follow that. Will after that I added a lightweight front‑end, I added some the OAuth integration with PeeringDB, since I already had the automated schema building, I thought I could just build a back‑end for this. So you can use these.
.
The whole thing has a Delta sync every 15 minutes, it's using the same mechanism PeeringDB pie. Stillness is bounded to 2 minutes plus. What does that cost? Well, CloudFlare workers is costing me 5 dollars a month right now, that has all of my projects in it. I did a simulation of how much it would actually cost me if I were to run the entire PeeringDB workload on it, and I guesstimated that at 1.7 billion requests per month. That would cost about $500 a month. Optimise to one a CPU run time, the number of rows read from the database because those are the two CloudFlare actually prices you on. It works from every CloudFlare edge. The database itself is as reads replication across the world automatically, if you use the right incantations, and it does. The platform wasn't actually really the hard part. So, JavaScript, raw JavaScript isn't exactly my dream language.
But I did end up with of course the hardest problems in IT. Off by one errors. I found an interesting one in synchronizing PeeringDB, issue 2057 resolved last week. That was giving me synchronisations that were not complete. The cache invalidation. PeeringDB is slow moving so you can cache requests until they are not, and then you get propagation delay, gating staleness and naming things. I mean what do you name this thing? So, initially, until very recently, that working title was PDBFE. You can try to imagine what FE part of that stands for.
How to work through PeeringDB? Of course it's their data and their acceptable use. I asked for approval in April. That was a bit unfortunate timing, it was a middle of the Board elections. I got confirmation late September. Pulled the access. I offered to integrate and collaborate with PeeringDB. It's currently an independent service, and I have 47 seconds left so just a couple of quick pictures of what that looks like. This is when you log in. You actually get visibility for your own stuff, you can click through immediately. Every page you look up you can star and it will be added to a favourite list so you can have a quick references. And there is the configuration and how you can set your own API case to use this. The API itself is completely compatible with PeeringDB Version 2, as it is. It's here, I would, here is the GitHub, and I would very much appreciate your PA feedback and that's 5 seconds left. Thank you.
WILL VAN GULIK: That was amazing.
AUDIENCE SPEAKER: I feel trapped and caught and this is very unfortunate. Cool to hear that you are using workers, you don't have to use JavaScript. I use typescript because I am not insane. You can use, you can also use Rust or Python or a couple of the other things because we have the Wassee run time on top of that.
REMCO VAN MOOK: When I built this, it was, yes, you could JavaScript and therefore also typescript. I looked at the overhead of adding typescript and since CloudFlare workers are basically built on millisecond of CPU you use, less is better. So, I mean, I ended up basically writing C in JavaScript to do the workers. Have a look at the code. I think the API of workers code is pretty lean.
WILL VAN GULIK: So, I think with that, thank you very much for putting these slides up so fast and thank you for that show of things. Thank you very much.
(Applause)
.
Now, I will introduce like really briefly the panel that's coming up. Leo asked if we could have a panel about the API for PeeringDB, and I asked Matt Parker if he wanted to moderate that and he kindly accepted, and so I got also ARIN here as a panelist and then I'll give you have the floor and microphones and I am gone.
MATT PARKER: James is joining us and we have Andy online. Okay, if you guys take a seat and I'll just quickly introduce it. So, as Will has already mentioned the topic for the panel discussion is the new API for the peering database. PeeringDB API v3 is a public read only API designed to be served multiple locations. It launches alongside the current API v2 and PeeringDB are keen to receive feedback from both users and tool developers on the new API. On the panel today, we have Andy joining us remotely, Andy is from the the Internet Society, and their IXP tracker makes extensive use of the PeeringDB. We also have Aaron Hughes from HillCo Global, who operates provision, which provides a network source of truth used by many networks. And last but not least, we have James Bensley from Inter.Link who makes extensive use of the PeeringDB, and James and his colleagues have been very be active in providing feedback and suggestions for improvements that are currently being implemented. So, thank you for joining us today, gentlemen.
Do we also have slides? Yes, we do.
Without further ado, let's make a start. The first question that we want to address today is, the fact that the new API is query only and is it okay to have updates using a different API?
JAMES BENSLEY: I think this is kind of pushing PeeringDBs problems a bit onto the users. I get that that he want to have a second API, stand it up along the first one and have a migration process. But me, as a user, we implement our own PeeringDB client, we use Peering DB like many many times, we are constantly poling them all throughout the day and stuff and local cache. I don't want to implement a second client and fan my queries out to two different APIs. I think this could probably be resolved on Peering DB's side by them having having an API proxy. I just send everything to one API, internally they can route my queries to two different place ifs they need to because if you think about it, from the client side, thousands of people query Peering DB, everyone of them would have to make this change to support two different APIs or we could do it in one place which is on the Peering DB side. I am selfish about this because I am a client. I don't want to have to could the work. I get that Peering DB is resource constraint. But I am not sure why we would put the effort on the client side and make everyone implement the same change when it could be done on the server side in one place.
AARON HUGHES: I tend to agree with that. I mean, the cachability improvements with v3 is certainly much better for us in that we don't have to cache a response from Peering DB, which we currently do for 48 hours, certainly in that IX LAN or a peer IP can change within 48 hours, an dit's nice to have a freshness, understanding and a version control for each version of the dataset, so we can simply ask v3, did this change, we can get back a 304 instead of downloading the entire member list. That's really nice. I also agree that we end up having to set up two different caches of everything from v2 and v3, v2 are going to have our APIs for the private data, because we don't get contact data and one the things that our platform does for for example is send out a peer request where we need an e‑mail address, we can't get that from the v3 dataset because it's only the public data. So...
MATT PARKER: Okay, thanks. Andy, any thoughts on this.
ANDY CLYDE: From our point of view we are read only anyway, so the split wouldn't affect us, but I'd echo the other panelists comments from a client point of view it's a lot of extra work to have two APIs. But also from Peering DB's internal point of view as a maintainer of APIs myself, maintaining APIs is a lot of extra maintenance work for them and only sort to medium term combining them into one would be a good idea.
MATT PARKER: Okay, thanks for that. Then, let's move onto the next question that we wanted to address, which is the fact that the new API is going to be served from multiple locations. Do you have any opinions on the number of locations that may be required for this? Let's start with Andy this time.
ANDY CLYDE: Yeah, a bit of a million dollar question really. I guess it depends on the reasoning for serving from multiple locations. I think if it's purely for redundancy, two or three locations, geographically dispersed would probably be sufficient. If it's for service type performance, because of the amount of queries, then I think I'd want to look at, you know, where those queries are coming from geographically and try and figure something out from that respect. If it's kind of the latency clients, high performance, I'd say, you know, maybe one with a constant minimum, again looking at demand and where the clients are, and predicted growth in that demand would be the way to go.
MATT PARKER: Okay, Aaron any thoughts?
AARON HUGHES: I tend to generally agree with that. I mean again with the whole 99% freshness goal and the ability to get a 304 back, your dataset Delta is tiny. You are not downloading the entire member list so you don't really care about latency but also with resilience, absolutely.
JAMES BENSLEY: I would split it into a few different things. One is are we talking about resiliency, so in which case probably three global locations is probably enough. If you did three different Cloud providers in three different continents the likelihood of all three going down is astronomically low. If you're talking about latency, it's a different number and that's probably more of a question for Peering DB, they would need to look at the requests from the clients, what is the latency they see and where are those high latency requests coming from and then put caches closer to those higher latency requests. There is the redundancy, the latency. Then there is also the performance, like a third aspect of performance. Me, as a client of Peering DB, if I could, I would have the same behaviour as IRR databases that support NTRM. I would have one minute sync intervals with you puts a lot more pressure on peering. That would require a lot more instances spread out. Are you optimising for redundancy or latency or performance? You know, those three questions would require a different number of POPs in different locations kind of thing. And me as a selfish client, yes, like I said I want to have one minute sync intervals so I want to have many Peering DB locations.
MATT PARKER: That makes sense. Okay. Thank you again. The.
.
Onto the next question. And this is considered the transition from v2 to v3. So the question is: How long will users need to transition and perhaps also, importantly, will you be transitioning? Let's start with Aaron this time.
AARON HUGHES: Sure. I don't think it requires a lot of time. There is, there are some differences that are somewhat challenging. For example, the flattening of the dataset in v3 means that department equals goes away. Right now you can query an AS and get back in a single pull on depth equals 2, the IX and the peer IPs, whereas on version 3, that would be 3 separate queries that you would join to get the data if you are looking at what IPs exist for on what IXs for a given AS. So, some slight different code changes. But generally speaking, this is a fairly easy change to QA, and probably just have to, you have probably already accounted for failures and checking your cache in the existing v2 set up. So I don't see this being a heavy change to implement.
ANDY CLYDE: I'd agree with Aaron on that. It's not a particularly huge lift for us. We're probably slightly different in that our use of Peering DB is analytical rather than operational, but I would say for us it's probably a couple of weeks work which is we can do on a draft API implementation before it goes live, so yeah, not it too difficult for us.
JAMES BENSLEY: Pretty much what everyone else said. I think we don't need that long to switch over. I mean,s I'm going to say T no one else has said is it so far, AI, you know, clawed is very, very good, it really is not a big deal for us to switch API endpoints and rewrite stuff. So the effort is not that much for us as somebody who runs a local Walsh and then queries is locally, that's not a big deal for us.
I think there is perhaps a slightly different issue for people who query the public Peering DB API. That may be, it's going to have a longer tail so it's maybe more like for Peering DB, to look at the volume requests coming into the v2 API, look at the volume requests coming into the v3 API, once there is like 51% of requests cottage in to the v3 API start to deprecate the old v2 or something.
MATT PARKER: Okay. Makes a lot of sense. Okay. So, those were the structured questions that Peering DB were looking for responses on. But since we have you guys here today and you are very familiar with this, I guess the final question is: Is there anything missing from the v3? Is there anything that you specifically need or want that isn't currently in the proposal?
AARON HUGHES: I think the one I mentioned earlier is an interesting aspect, the depth equals going away and the data being flattened. Again for me it's not challenging to triple the query I can get with a single query is what it does mean is an operational load that is already being on the public v2 API so there is going to be a heavier operational load on the v3 API if we open up that rate limit. That said, the size of the data, the payload is going to be smaller so we're talking about more queries per second but a much smaller dataset to analyse, so, I always, were the Chairman of the operational committee had for Peering DB, and certainly will be looking at those analytics as we go live. There is some unknown element what that data load is going to look like and we'll obviously have to adjust as it gets implemented.
JAMES BENSLEY: We are very greedy so we have loads of things that we want. We are very heavy Peering DB users. So I ‑‑ it's hard to know where to start. One thing I would like to see, maybe other people are have the same, I am hoping other people have the same issue or concern is right now Peering DB has API tokens that don't expire. Will so, I would like to see a switch to something like JSON web tokens that have a lifetime. It be be high like six months or twelve months and then an API endpoint where I can refresh it and get a new one. So it's not a manual process. I have an expiring token but I also automatically refresh it from time to time. The whole thing is automated. If somebody gets my key it's not valid forever. It's something I don't like about Peering DB right now. I would like expire API keys. What you were mentioning about the flattening of the queries. I'd be curious to know if Peering DB put any thought into drafting a...... REST API, we do those kind of queries from our cache internally where we kind of like pull our network, pull some other network, across reference all the locations we're in, see if we can do some PNIs and pull all the IPs and generate all the peering sessions and stuff. The it would be great if that was just one GraphQL query, which is similar to you. That's not so much a request, more of a question to the Peering DB team, like did anyone look into the adding GraphQL to try give users that kind of flexibility, because many many Peering DB clients, thousands of people query Peering DB and we're all implementing the same allocate on the client side, get this data, that data and compare and get the result. Like I said, it's something that Peering DB could implement on the server side to save thousands of people all preliminary the same allocate on the client side. Of course that's more effort for Peering DB and I am like a greedy customer kind of thing. So that's something else I would be interested to know about.
I would also be interested to know maybe Peering DB, you have this already and I just don't know about it but I would really like a test API. Like RIPE has the test database that they reset everyday. I would like a test API that I don't have to add something into production to check out the delete function works. That would be fantastic maybe you have it already. I see Leo is rising to his feet.
LEO VEGODA: Tutorial server. It's just the interface and you go and put whatever data you want in there, test against there, it's periodically deleted.
JAMES BENSLEY: That's a gap in my knowledge. So thank you very much. That's helpful.
MATT PARKER: Leo, do you have anything to add about the GraphQL?
LEO VEGODA: You are the first person to have mentioned it to me and maybe we should have a chat and write up an issue and see if the product committee wants to do it.
AARON HUGHES: Also probably notable is that he is here with his product development hat on in Peering DB, taking notes from anybody in the audience to help improve the quality of the Peering DB product, and that is his function is the interface between the community and the peering development staff and operation staff. So this is a good time to make comments about what you'd like to see in Peering DB.
MATT PARKER: And Andy, any thoughts from you on anything that may be missing before we take some comments from the audience?
ANDY CLYDE: Nothing specific for us from the API. As I said, we are many analytical use that is we don't dive into the detail as much as operational clients would. I mean our main concern is because we look at the historical data, in getting data back to 2019 and reprocessing as necessary. So, yeah, having some conversations with Leo over that already. And our other concerns are more and better data that we can share in our IXP tracker, a lot of which might not be within Peering DB's remit anyway, so we're looking at trying to get some traffic data. Network classifications, which I know is a difficult topic, and dataset types. Will but they are all on the data side rather than the API spec itself.
MATT PARKER: Okay. Will thanks. We have about three minutes left, I believe Will still needs a minute to wrap up, so let's start with I think Remco was up first.
REMCO VAN MOOK: So, two things. If you'd like to play with the GraphQL read only version, that's on the thing I did, I just did a lightning talk about. If you want to play around with GraphQL on the Peering DB data, I am sure not many people are using it right now. I would love to see you try and see what comes out.
Second one the things that has come up is I think getting a bit of guidance to Peering DB about the level of stillness that's acceptable for data that you are dealing with on, from a mirror version, I mean which is the question I had to answer for myself and ended up with 15 minutes plus one or two minutes of sort of padding and figuring out updates. I think that would be very good for the community to get some guidance on. Thanks.
AUDIENCE SPEAKER: Hello, it's about the data. It would be nice to have some verification on the data because went we founded the Strasbourg ISP we had a big issue because the/26 that RIPE gave us was already registered and it took like months to have it into Peering DB. And it was assigned since two years I guess, something like that, and I think if we could have some sync between the RIPE Database or every IRR database and the Peering DB database on the assignments of the IXP prefixes it would be very nice.
MATT PARKER: Okay. Great. Thank you very much. I think that's gotten a lot of useful feedback for the product team at Peering DB. Did any of you want to add anything before we finish?
AUDIENCE MEMBER: I'd like to comment on that last comment. This is not strictly ‑‑ so that comment was not strictly about the API, the new API draft, More about data freshness in general is. Perhaps it's something we can talk about afterwards like in the corridor, because we also have the same concern and we're talking to Leo about it as well. Some people ‑‑ Peering DB is kind of a best effort thing. It's up to people to put their data in it and stuff like that. So some people take the view that you need to take the information in Peering DB with a grain of salt. Which I get it because it's run by volunteers and it's up to people to keep their own data up to date voluntarily. But also the reality is Peering DB is actually a very critical tool in production responsible for production things happening in lots of networks all over the world. So I think there has to be some process where we move on from this it's best effort on valid data, do with it what you will, if it belows up, it's your problem. It's more like we have to start validating the data, provide information about freshness and etc., I think there has to be a follow‑up discussion about this.
MATT PARKER: Okay. Great. Well thank you very much once again, James, Aaron and Andy. I will hand you back over to Will.
.
(Applause )
WILL VAN GULIK: Thank you very much, Matt, for that. That was amazing. I think we got a really good load of input. I know that some comment wanted to be shared by the team, the R IX team. So thank you for that. I hope you got plenty of your good information for yourself. I am sorry but we are like three minutes late. We went over time. So, excuse me for that.
We thought it was like really interesting to have that going on. So, with that, I would also like to thanks the scribe, the tech team and everyone who did something amazing for us, and for the community, and with that,
STAVROS KONSTANTARAS: Just a last remark, they should not forget to rate the talks.
WILL VAN GULIK: Thank you. And with this, I think we are done.
STAVROS KONSTANTARAS: Time for coffee.
WILL VAN GULIK: And we'll see you all in Vilnius, thank you very much everyone.
(Coffee break)