RIPE 92
Main room
20 May 2026
9 a.m.
.
WILL VAN GULIK: Welcome, we are at the hour, welcome, welcome, to the main room. .you are quite early. That's a success, well done.. It means that you were wise last night.
.
.
Welcome to connect. This is the main room, if you are expecting to go and see OpenSource, it's going to be in the side room.
[Sorry technical fault ‑‑ 10 minute gap here]
I am also the peering manager. So if you don't know peering manager, it's an OpenSource project that basically helps you to track BGP session at the edge of your network, so, if you have transit peering, private peering, customer, whatever that is, it helps you to track autonomous system in BGP sessions, it helps you to render, configure automatically for your routers, and as I state in the slide, it relies on PeeringDB for finding networks properly, out mating the discovery of the peering session you can have with them and a bunch of other things.
It's completely vendor agnostic, and unlike some tools in the network industry, it's free, it's open, no premium feature. If the feature lands in peering manager, it's available for he everyone and it's not company based, so no company, nobody wants money for it. Nobody asking me for money for it, so that's okay.
Over the past years, the peering manager has been around almost ten years now, and over the past year I had a bunch of asks to create a peering portal, like the front facing peering portal for self‑service peering, and decided to tackle that issue which was due for five years or so today, at least in the past few weeks. So, basically, what do we want from a peering portal? Like we want to request peering for, to peer with the system, we want to be able, it to be able to discovery IXPs, facilities, this is Peering DB for the data for it.
We want to be able to discovery the session for it, and to request the session for it. Meta has a good peering portal for Peering DB and Microsoft as a terrible peering portal because it requires your credit card to ask for peering, which is... yeah. Terrible.
What's peering manager role? It's a tool that's run in your automation framework, so you don't want it to, you don't want it to be publicly exposed, it's probably not very secure. But we want it to have the logic for the peering portal. So it provides the data for it, and it helps you into managing the incoming request, basically we want to introduce a way to receive a peering request at the peering manager site and infer what peering session we can turn that peering request into.
That's pretty much the peering manager goal. The ultimate goal is basically this. We want a peering request, we don't care about the e‑mails, we want to kill them, it's not useful anymore for our community. So we want the peering portal to kill that e‑mail. And making things more smooth error and API connection wise, like this is the ultimate goal. The really ultimate goal for me is like peering manager is on one side, peering manager on another side, they talk to each other directly, and they also discover the peering session and basically you don't have any e‑mailing direction direction into it, just approval on one side or another.
The portal architecture I came up with is the following: So, we have the end user, which came to a peering pole, which will come to a peering pole, ask for a network with you, a network session with you, and the peering pole is going to forward those requests to your peering manager which will make sense of it, of them, if there are lots of them, and notify you about ‑‑ there is a peering request coming to you, do you want to approve it? Do you want to decline? Do you want to maybe approve only a sub‑net of the session, reject the other? So, it's basically this.
In peering manager, we had pretty much everything here already, at least half of it. When I say we, it's always me, but, I say we...
So, in peering manager, thanks to Peering DB again, we know which ‑‑ if a network has a Peering DB recall around some of the details of it, thanks to Peering DB, we know the common locations between two networks, given they are IXPs or data centres, facilities, also named like that. And we did not have the possible session between two networks if they were not inside peering manager already, so it was almost there but not there yet. We had a way to track peering sessions, of course. But we did not have the peering request model, so basically an envelope where you could, that you could ingest and say I want this peering session, I don't want to create them yet, but I'd like to have them in the future.
So that was 50% of the work basically. And tried to have support for that draft over there. It's a draft that has been designed by I think it was Meta, Google, that sort of thing, was pretty much stale at this point but I'd like to maybe revive it somehow.
Peering session from this is pretty simple. Basically carrier end product. You have peering ‑‑ you have connection on one side, you are connected to one IXP, you may be are connecting yourself twice on that same IXP with different IP addresses and you have the same on the other side, and we try to map all the possible peering sessions between the two sites. So if you have two on one side, two on the other side, it makes four. Simple math.
Current results. It looks basically like this, we do see it so, I don't care about the styling etc., I am just shitty at this. But that's just bootstraps and stuff like that. And obviously Hurricane Electric and NTT, I am not sure they are good candidates for peering, but at least everyone knows them.
I didn't put CloudFlare because they are just a blogging company anymore, so...
And basically, this is what the user that wants to request peering with you is seeing. So, I didn't put all the screenshots because this is just boring, but this is the final page of the requested peering session and then end up with this, they have the R.I.P., the location, the pending status, and from a peering manager perspective, you basically get this.
So, on the back you have the peering manager UI, but on the front you basically are trying to accept a bunch of peering sessions, and this, when you accept them, they are going to be actually created and they enter your automation framework. So you can populate them on your routers, and then notify your peers, your new peer, that the sessions are now ready to be used.
There is no notification mechanism yet, but there will be one. And the tool notification mechanism I have been thinking of is like e‑mail, shitty, because we want to avoid them in the first place, and the second one is like web bugs, you enter a web book and when the operator accepts or declines the peering sessions and you get a notification on your web book receiver. So that's pretty much it.
.
The result, basically this is fast API application basically because it's a simple to understand, simple to tweak. Python, you can understand it the way you want. Bootstrap 5 for the UI obviously with my with my shitty design. But it's not the implementation. This is mostly like approve of concept. Like, if you want to make your own, there is documentation that will be published. You have a reference implementation for you to work with. But you can write your own peering portal the way you want.
The main work of that peering portal thing is like providing the proper API for you to work with. So you don't have to tweak the peering manager the way you need it.
The peering request lifecycle, pretty simple.
So the user came in, creates a bunch of sessions through the portal because the portal is just a front‑end that we make API queries to the manager. The user came, create a session, the portal injects them, send them to peering manager, and you have the pending status that we saw earlier, and you can either cancel them. This is again a user, the requester operation like they can cancel the request because they don't want to peer with you anymore because you maybe insult them or whatever, or you can ‑‑ the operators to the one receiving the session, they can reject it because they don't like your name or your face or whatever. Or they can accept it because you are someone they actually like to talk with.
It's like real simple but it takes a lot of effort to come to that in the OpenSource project because there are also politics, someone wants this, someone wants this, so you have to find a middle ground that is usable for everyone.
It's things, and details about the implementation. Like high level details. When you create a peering portal, the biggest issue you have, like you have to avoid the fact that someone may come to your peering portal and say I'm Google, but they are actually a different person, and they want to create or maybe delete peering sessions. So, you want to avoid that. And a probable solution to avoid that would be to go through Peering DB OAuth because the user logs in with his or her own Peering DB account and Peering DB gives us a way to know for which network the user can act on behalf. So this is one of the key ‑‑ it's really important to have this because you don't want to have an invalid request, but it's not implemented on the peering portal I am going to OpenSource because it's ‑‑ I was too lazy.
The interaction between the portal and the peering manager is basically one user with one single API key. So that's ‑‑ so peering manager doesn't know that this is person X, Y, Z who created the session, the session request. This is just a peering portal saying I have this coming in, do something with that. And I again mention the draft, so I think that draft is pretty important. It seems to be stale now but I think the last modification for for it was May 2025, so about a year ago. But it basically highlights a way to create a proper, let's say, standard, standardised API for peering session and peering session lifecycle. So, I think it's pretty important. So if there are people who are ‑‑ who were involved with that draft in this audience, come talk to me, I'd like to revive it, see if we can do something about it.
.
Now, what's missing right now is the private peering session because you can peer over IXPs but you can also peer over direction link, like direction interconnection, you put up a fiber, correct your router and you want to go through it and the missing link in peering manager is that link between what's a connection, what's a facility, and where it ends up on the router, so this is something I have to work with.
There is also the complete session management, so you can now request a peering session, cancel it, but you cannot update it, delete it or monitor it. The monitoring part is, in my opinion, important because if someone wants ‑‑ if someone sees a peering session failing on their end, maybe they want to come to your peering portal and see what's up with it. And as I mentioned at the very beginning, the automated peering request and approval, no portal involved, like just system communicating with each other, maybe idealistic, but we all have to have an idea of where we want to go.
The two links to the OpenSource now.
Last but not least, I think this is not peering manager anymore, but the OpenSource maintainers play a critical role even in our field because there are a lot of tools which is OpenSource and even with all the AI stuff, which is good or bad, whatever we want with it, like, there are some good, there is a lot of bad as well, but they are really critical because we receive security issues which are not security issues sometimes, and we receive PRs, which are pull requests, which are sometimes, like I could have crafted them myself by just throwing something into chat GPT or whatever, this is important to review them.
If you have critical OpenSource tools that you rely on, it could be peering manager, it could be whatever other tool, remind to support them either by helping them, in could be by funding them or something, but by other means as well.
I myself can thank links and HTP because they have supported me through the years because you have a day job and a second job working on OpenSource, it's helpful to have these guys behind you.
And now I will take questions or no questions. Whatever.
(Applause)
WILL VAN GULIK: Thank you very much. So, I know we have got one question from the chat and then I'll go on the mic there.
AUDIENCE SPEAKER: Good morning, Marco Schmidt, I am reading out a question. First of all, we, as AS15435, have been a user of peering manager, and use it for the whole config generation of our peering routers.
Do you consider also publishing a basic version of the peering portal as for example with Peering DB I think that can help the adoption?
SPEAKER: Absolutely, this will be released soon‑ish. It can be two days or five years, whatever. But, it will be definitely published, yeah.
AUDIENCE SPEAKER: Mike Blanche, independent peering enthusiast. Thank you for this work, I think it's great. It's like another layer on top of Peering DB to actually be able to use the information that's in Peering DB to manage your network and its interconnections. Just a couple of comments and thoughts. On the IETF standard, I'm not one of the authors but I know one or two of them and I think they are just very busy, so any help that anyone could give resurrecting that draft, I think that would be very welcome. I think Facebook has an implementation for the peering API, so they are using it now, so more implementation as in this would be fantastic.
The other comment is on support. And your last slide about thanking people who have helped support this, I think that's really important. There is concerns now with the changes in some of the peering policies and some of the large networks, about how they are perhaps using Internet exchanges a bit less, systems like this help make it easier to carry on using Internet exchanges and to reduce the administrative overhead that these big networks claim is an issue. So, for any IXs that are out there, if you want to support this work, I think it would really help to help keep these big networks on the IXs because it reduces the administration.
WILL VAN GULIK: Anything else in the room? I think it's quite silent. But it was really insightful. So thank you again for that.
(Applause)
WILL VAN GULIK: Now we have James who is going to speak to us about some stuff testing on Layer2 environment I think, and it's a really interesting observation. So, I think it's going to be really interesting. The floor is yours.
JAMES RICE: Hi. I am James Rice. A small UK ISP that spends a reasonable amount of time and effort on security. This is a somewhat uncomfortable talk about one the subs that's responsible for many grey hairs. I'd like to thank many of you, including a lot of people in the room today that I have been talking to about this issue for over five years now in various forums over dinner and long phone calls. The support and input has been very much appreciated. This is a case study from one of the big three European Internet peering lance where customer traffic was disrupted and disclosed to hundred of ports for almost four years.
.
Slow down!)
.
It may have been happening for much longer and it likely affected up to tens of millions of people data. This is hopefully a coherent picture of what's happened. Some lessons for Internet Exchange operators and participants and where we are today which is still not fully fixed. This still remains an unknown mechanism and so some trafffic still continues to be subject to blackholing.
So, this is a comparison of what should happen or what everyone expects to happen and also what also happened on the right there. Everyone expects that you send a frame destined to participant B's MAC address from participant A, it makes its way to B and that's the end of the story.
Unfortunately, when members change MAC address, you end up with traffic still going to the old one. And because flooding is enabled on the peering LAN or was enabled on the peering LAN, to a greater extent than it is now, this traffic gets flooded. It makes its way to members who have got devices which are misbehaving and which then go and reforward this traffic back to the intended recipient. And RFC 4861 has a bunch of mechanisms where you don't need to send refreshes for neighbour entries if you have in this case forward progress ‑‑ so, yeah, they perpetual participation mechanism here is demonstrated as mount B changes MAC address for whatever reason. There is many reasons that MAC addresses change. Their peers don't know that the MAC address that is changed they continue to send traffic to the old MAC address. The exchange floods in as Anycast and then some members are having devices which misbehave. They don't do the Layer2, is this actually for they? They then forward on the traffic to the original destination, with its correct MAC address.
As a result, the originator of this traffic never actually does a refresh for the neighbour entry because it's got the RFC 4861 positive confirmation that it's making forward programme.
The second mechanism is receipt of neighbour advertisement message that's a response to enable solicitation message. So, here there is a TCP dump of a real exchange that's been sanitised but you can see the old Mac ends OBFB. Neighbour solicitation, Unicast, neighbour solicitation was sent to that MAC address, it doesn't exist anymore, if gets flooded and then it gets a response from the new MAC address, but this actually keeps the old entry, the old stale entry alive as reachable.
So, packets continue to be flooded.
The two mechanisms here, the first one is what you'll mostly see if you have bilateral BGP sessions with neighbours because you have the forwarding acknowledges of the BGP connection of the BGP making progress. Whereas if you are peering by via route servers the dominant mechanism will be the neighbour advertisement response to enable solicitation.
Then, from BGP tools, it was posted on the ops list after another complaint of mine which I made public back in November 2024, he pointed out how easy it is to demonstrate that this problem exists. It's a case of find a peering LAN ‑‑ find a peering LAN IP address which is not in use, put in a static neighbour entry for it, and then ping something, and you end up getting multiple responses back because this point there were multiple misbehaving devices on the peering LAN which was taking traffic that was not for them and then forwarding them on.
.
So this should have been zero replies, and it was three replies and Ben also put a sanitised radius access request frame that had been flooded on the peering LAN that shouldn't have been anyone else's to see.
So how members noticed this was happening.
There was a discussion on the ops list several different members mentioned various issues that they had had when changing MAC addresses when updating their routers, some mentioned that maintenance had to be backed out because they were just seeing weird brokenness. The things that I noticed were ACL hits on a Layer2 breakout switch as a reseller. There is some bogon filters which were catching traffic which wasn't even for us or down streams, it should never have caught those bogons but it did do.
Also we noticed BGP sessions were failing but only to the neighbours that were configuring TTL security. This was really strange at the time, we didn't know why, but in hindsight it's because what's happening is the misbehaving members devices are forwarding on the traffic. They are routing it, back to the peering LAN and decreasing the TTL at the same time. Where you don't have TTL security on sessions the session also just keep working, like normal. If you have TTL security you might actually notice that your BGP sessions are being forwarded via a third party.
There was a duplicate ICMP replies, this only happens if you have multiple misbehaving devices on the peering LAN, but on this occasion I think we ended up with about seven of them at some point in countries I think one of them was in Singapore, it was 156 milliseconds away.
One of the other things I noticed was an unexplained traffic in S flow. It was traffic not for us, it was not huge amounts but it was unexplained and probably should have been investigated more. And some members were complaining of hundred of megabits of inbound traffic on ports which should have been empty. There was apparently rate limiting applied to the Anycast but it doesn't seem to have been always if fully effective.
If you know the CIH out of security, then this broke all three of them. In terms of confidentiality, back in November 2024, so several years after I first reported the problem, I realised that the only way I could actually get action to be taken by the IX on this was me to look at how sensitive this traffic was. And it was quite uncomfortable looking at the traffic. It turned out that HTPS, the server name is not encrypted by default, it's in clear case in most cases. One the first things I saw was a law firm had an IP address, I was like I wonder if this is the IX seeking legal advice on this disclosure issue.
I went to the website and it was actually a tax lawyer so in this case it wasn't relevant. But then I also realised that if this was a divorce lawyer, this is the kind of information that gets people killed. That's very uncomfortable because this traffic is being flooded to hundreds of ports, any of them could be logging this, Indexing them, putting them in a search engine like Showden, allowing people to see what websites were being visited from a given IP address at a given time. This shouldn't be happening.
Integrity. This is more of a case can anyone modify your traffic? And the answer here is well it's being passed via third party devices. Yes, they can. Other people's routers are now in the traffic path that should not have included other people. And the third thing in security is the availability. This is does it keep working? And since there was the rate limiters on Anycast, then not necessarily, packets are being lost.
We don't know when but we do know that one of my downstreams, they have about 40 to 60 thousand downstream customers that they are the voice provider for and their voice traffic, in this occasion, went across the peering LAN.
Their response when asked about what would happen if the traffic was being rate limited is it would be very, very bad for safety. And again this seems to be like a safety of life issue that's very uncomfortable to keep in its current state.
So we have a timeline. March 2021, is when I first raised a ticket. It was actually about traffic to a point provider that was being flooded on the peering LAN. Things moved, then kind of went quiet, I chased it again, a year later I was told that they were looking to disable Anycast flooding in the future approving concept. Then I discovered over a year or two later that this was suddenly closed in July 2022 with no remediation. There was a member ops list thread in May 2023, several people reporting the same issue. There was one member of staff engaged but then nothing happened, nothing substantive. Then something else happened in November 2024, where I realised that had this is the same issue, it's still not been fixed. /8 to the membership and the Board. Then posted demonstration. I end up on a phone call with a senior Executive Board member. I get assured this is not waiting until next week, this is early Friday afternoon phone call. And then Saturday, I realise that had nothing is actually happened. I end up on live chat with their support, they tell me they can't reach anyone from senior management so they can't do anything about this. They will get back to me. One of might have questions was is the IX taking responsibility in terms of demand identifying members for all this? That's another question which has never been answered.
I left the members meeting the next week, having shown the conversation with my customer regarding the 999 calls and left thinking that this is actually now moving forward quickly. So I was quite surprised when it was nearly eight weeks later that anything was actually done. There was a filter deployed in January 2025, members were not notified. And then in February 2026, I noticed more behaviour that looks like the unknown Anycast issue again, it's within confirmed that yes, the remediation is not complete. There is still a mechanism, it's still being flood. The mechanism is not known, but members still haven't been notified. That's a potential black hole issue because if you are learning prefixs from a route server and you have a stale neighbour entry for your next hop, then traffic just gets dropped on the floor.
So there were choices here. The issue is not entirely a technical one. Anycast failing was enabled. That's a bad choice, my time at LONAP we disabled Anycast flooding back in October 2001, so this is a a 24 and a half year old problem solved in place that is still not fully solved here. There is a no understanding with the multiplex. One is harmful traffic patterns will be cause for having ports shut down. But this wasn't used.
The exchange has devices on every switch, on the peering LAN which could have detected this behaviour, but it wasn't. Everything was driven from the members.
So lessons for Internet Exchange operators. We ever one for members, we also have one for operators here. Disable Anycast flooding. There is nothing you can really do other than disable unknown Anycast flooding. It doesn't matter what kind of source MAC address filters you have, it doesn't matter what kind of ARP filters you have, what kind of neighbouring discovery inspection that you have. If you are flooding packets which can be used as forward progress, which responses will indicate forward progress for, then you still risk having this unknown Anycast perpetuation there.
.
This traffic was difficult to find because the broadcast domains were just full of all sorts of other prohibited traffic. I found members which were peering with each other using OSPF E 3. I am sure this was unintentional, but it's another ticket that I had opened.
Apply the MOU. It's like the members have an expectation that the MOU will be applied, there is potential for discretion but if you do exercise discretion and not apply the MOU, make sure you are accountable, explain why you have not applied it.
Verify your fixes. It wasn't. It wasn't fixed. And where something is unusual, if you are seeing traffic you can't explain, then well don't just rate limit it, investigate it and figure out why it's there. Don't leave it to the members to investigate and figure out why it's there.
Finally, consider moving to a Layer3 routed model. Because this just eliminates so many problems. All of these Layer2 issues just go away.
Lessons for members. TTL security really helped. You could tell straight away that where you have a difference between sessions where you have got TTL security not coming up and sessions which don't have it, that this is unknown Anycast being forwarded by third parties issue.
Look for things hitting your ACLs which you don't expect. Look for things in your sFLow which you don't expect. Not on this slide but I should have put is consider whether route servers are actually for you. Because obviously if you are Internet Exchange isn't looking for problems, then route servers actually mean that you are vulnerable to this perpetuation mechanism when you otherwise wouldn't have been.
Push back on tickets being closed. This might mean actually going and checking if the tickets are still open. And push back on strange things that are NOC tells you do. I got that to ask all my peers to clear their neighbour caches which didn't seem to be the right fix.
Anyway, did I do enough? Is a question I keep asking myself because obviously customer sensitive traffic was still being flooded for longer than necessary. It's quite chilling the sensitivity of such traffic. I could have removed my traffic from the exchange until remediation was confirmed. I didn't do that. I ask myself what threshold should I have done this. Did I meet my duties to notify my customers and their customers that their data may have been disclosed. I am awaiting the IXP operation rationale on why they don't see the issue should be node identified. Whether I should have informed my customers anyway is open.
And I didn't verify the operators remediation. I assumed that the fix they put in place was complete. It wasn't.
And I also didn't look very much at the traffic for several years which I could have done but I just took on trust that it was going to be fixed.
So, Did I escalate enough and quick enough. Did other members escalate quick enough? These are questions I asked. I phoned friends and asked them many times. Now I guess to ask the audience, is this fine?
STAVROS KONSTANTARAS: We have some questions.
AUDIENCE SPEAKER: Jen Linkova. Thank you, this is exciting. As I understand what we have seen here at least for v6 was a corner case of vendors implementing may in the RFC which is unusual, which allows them not to sit dark source local address in NA, right?
JAMES RICE: Yeah, it looks like it.
JEN LINKOVA: So, I guess I need to think about it more, but maybe, maybe this needs to be fixed as well, right, because it's obviously didn't take into account the scenario of VC in the packet which was not addressed to you on Layer2 but still addressed to you on Layer3, so I think that may ‑‑ I'd like to take an item to find out why this may was in the first place but maybe it actually should be changed to like should not or something like that.
JAMES RICE: Yeah, I think it's possibly worth making sure that IXs don't rely on those mechanisms which will take years and years to fix when there is a lever that the IX can pull.
AUDIENCE SPEAKER: The problem is a long term known problem that was even part of the Cisco exams in the nineties, so, my question is: Where was ‑‑ when was this knowledge lost? What can we do that new people coming into our field learning the things we learned, we all broke networks, and the networks has no chance to break the network in the customers and we have to enable them to do so to they can learn and avoid such problems.
WILL VAN GULIK: It's not a question, it's a comment. And I will go to the comment and I agree, we had this discussion many situations, we are trying to push the community that's getting older to get younger to get new people in the crowd to be aware and to learn from the older people around to understand what is make we did in the past, and we should remind ourselves that we must transit, like give out this message to the younger crowd so we can help us all make a better Internet for the future. And it was a really good comment. Thank you.
STAVROS KONSTANTARAS: Do we have in the questions from the chat? No.
And now I'd like to introduce the next speaker which is Stefan wall, which is a very well known member in our community and he is also a Board member of the Euro‑IX.
STEFAN WAHL: Yes, the satellite says, beyond peering lance, we had a meeting in Vienna on the 4th May, funny enough it's a well‑known phrase, 4th May, and we have some presentations there and Stavaros was also there and we had a very good discussion afterwards and discussed some things which may be could be better in the databases we use on a day‑to‑day basis.
.
Why is this talk? Peering DB and IX foundations still describe an Internet Exchange as a single peering LAN. Real IXPs have now multiple ASNs route server fabrics, remote POPs, carrier service, Cloud on ramps, all this stuff and it does not express this. This makes life harder for the multiplex, people using API, route server operators, anyone actually automating stuff using these databases.
The old assumption is an IXP is a peering LAN. A member connects with an ASN and a port.
The directory describes that relationship.
That's now for decades the thing how we am handled it. IXP dB is a Euro‑IX directory of Internet exchanges. And the members. Peering DB, that works published peering intent. And where is the tooling stuff, A route servers, BGP Q4, automation pipelines, etc., etc.
So, the timeline where I tried to lean the presentation on is the BCOP works we have done here in the community, then we have the continued push on RIPE meetings 89, 91, authoritative IRR data, there was some presentations during this time, RPKI, ASPA, we had already had some presentations in this week about this. And then we had an interesting talk from Stefano, blind respondents in current IRR validation. The last thing is actually the takeaways from the Euro‑IX meetings in Vienna. That's opting up Layer3 services on the Internet Exchange which are not really represented in any database at the moment, which makes life really hard to automate stuff with the existing APIs.
So, already mentioned why now.
I had a very interesting talk with Leo about Peering DB. The upcoming API version 3 which I am really looking forward what they implement, what the community wants to have implemented in Peering DB.
They think there is still the possibility to add things to this. Then the IRR BCOP, Stavaros prepared in the last twelve months. That's something from the Working Groups we had at Euro‑IX, RFC 8950, which is a v6 only fabric for peering lance.
So, as already said, operational reality is different from the things we have in the database. Because it moves faster than the community sometimes, or often. So as an example, Matt Peterson had a presentation about the peering lance they have in San Francisco and he showed that they have not only Layer2 lance and also Layer3 services and he called this, this is actually a Layer2 .5 Internet Exchange. They leak, they have two different VRFs and they leak services from the Layer3 network in the Layer2 peering mesh. Is there any chance to put this in the database? No, can't do this at the moment.
So, the SFMIX is not alone with this issue. I picked up six of these issues. I have seen immediately. There could be more, and I hope that there will be some feedback from the community about it. The one thing is the big IXs like the DECIX, London, and the others who have multiple sites in the world. The representation is especially in IXP dB is not optimal, would I call it suboptimal.
Cloud on ramps, they are an extra service nowadays you can buy it an Internet Exchange. These services, you find in IX APIs as an example but you don't find it in other APIs like in peering or IXP dB.
Remote peering, this is something which has also to do with multi‑cert fabrics. Posted caches that's the thing the SFMIX people do there.
MultiASN services, PNIs at IX locations, I think that's a little bit problematic, but it could be interesting to see what PNIs exist in a location if members agree to put this data in the database.
So, where is the schema breaks nowadays? We have no service locator. We had no Cloud on ramps. We have no remote peering visibility. The hosts cache, the multiASN and the PNI visibility is not in the APIs at the moment and therefore it's also not in the database even if maybe sometimes they have it in the back‑end, it's actually not accessible.
So, and then the next thing, and then this is IPv6. Already mentioned the beginning RFC 8590. IPv6‑only peering lance, they are coming up for tests and Internet Exchange in Germany. They have seen some issues with it, but it's coming. We have to put it some where, we have to document it somewhere and it cannot be done in the common fields of the databases, it should be done with an object.
.
Link local addressing, some people discuss also link local addresses, not global Anycast addresses. Can I do link local addresses? Can I put them in the database? No I can't. And per service prefix limit. If you look at the IXP dB, and say you take AMS‑IX, you see a lot of peering VLANs there, there is about a dozen there, but can I put say a prefix limit different in every VLAN? No I can't, because it's the IXP is, has already said, it's an AS number, and this AS number is true for all the peering lance you have at the moment, there is no EIX can between the VLAN, the network, related to an ASN, you have not have a different ASN to the VLANs right now.
Then, we had the example also I said, the IRR in IXP dB, the trusted sources we have nowadays are very, very old thing. It's also well discussed and there is replacement already. We have worked on, it's actually functional, it's RPKI. But we are still a lot of legacy space, and not every region is a RIPE region. We have regions where they do not have also the legacy stuff covered. So therefore, we have to trust on the IRR stuff. But what IRR? There is a well‑known stuff and then there is the third party stuff, and can I have a look what kind of IRR the operator actually accepts or presents or which he regularly updates. No it can't. Because the field is not there. It's easy to implement and even if it's an old technology and really decades old, it would be okay for the next years to have it inside so everybody adapts maybe what's the RIPE region is doing.
So, they designed these sessions in IRR is based on the trust model. We have the data freshness. The object selections and failure semantics. This has to be represented in the API. I think that's not too complicated to add them. And therefore, my suggestion would be to do it. How could something like this look like? This is an example. This is only a suggestion. You do not have to do it this way, but here, you could see how these features could be integrated into the APIs and in the front ends. This is also covering the RFC 8950.
What a does this mean for best common operation practices? That means that the filter scope follows the service scope. An optional partial route servers can have different acceptable prefixes in the peering LAN. The BCOP needs to acknowledge that, we have to put it somewhere, per service trust anchors, so, if you have different services on the ‑‑ on my IX, I should have also the ‑‑ I it should be possible to have different transactions. If you have different regions as an example, you should have also ‑‑ it should be possible to have different trust anchors there.
Cross service leaking. This is a bit complicated because there is also huge risk involved so therefore of the tooling should help to lower the risk here for the communities they are leaking prefixes inside an IXP from Layer3 to Layer2 is something which I think is new. But it will show up more often.
What is not proposed to get it right because I mentioned IXP dB and Peering DB a lot, it's not about merging Peering DB and IXP dB. It's not about building realtime validator. And it's not about replacing the BCOP work. It's still stands.
The downstream tooling, what does it mean for the downstream tooling, the API would be changed. It's about the route server configurations, automation pipelines and member facing user interface.
We have here an alignment between the IXP dB and Peering DB. As an example member identity authoritative IRR sources, RPKI ROA and service vocabulary . Locator semantics are used easier. A locator ID is used in both. Where we diverge is that the IXP internal operational State, local policies, member intent route server configure artifacts should stay where they are at the moment.
How the layer fits, it's actually the practice layer. There is a directory layer where we have the peering Db and the IXP Db and we have the provisioning layer, which is then using the IX‑API.
This is all the stuff in automation.
So, what are the open questions?
.
Should the service be a first class directory object or a property of membership?
.
Who owns the it? I would prefer the joint effort by the way.
How do we keep the schema light enough that small IXPs are not punished for being simple?
.
What's the right model for non‑member presence? Say what's about hosted cache providers, Cloud on ramps, PNI facilitation. How do we expose all of this without become can operational source of truth we never wanted to be?
.
That's one the issues we have to sort.
So, I'll come to my nearly last slide. So concrete questions for the Working Group.
There are three:
.
Should there be a mandate to align work between IXP dB and Peering DB more than we do now.
Second thing is: Add service tier semantics for the BCOP roadmap. That's also a question.
And surface non‑LAN services in the director? Should they be shown up in this directory or if there another source of truth we could have here implemented or could already use.
So these are the researches I used for the presentation. I added them, and if somebody wants to read about it, that's a good start. There are also three other slides where there is some references to Peering DB, if you want to have a look at it feel free to click the links there.
So, thank you. And my last statement the director does not need to model everything but it needs to stop pretending that nothing has changed in our world.
WILL VAN GULIK: Thank you very much.
(Applause) that was really good and I can we need to have some kind of a discussion right now.
So I'm expecting some people to come to the mic because they have something to say.
AUDIENCE SPEAKER: I wanted to add there is another directory which you didn't mention which is a PCH directory, and I would really if you could have a directory which has all the information from PeeringDB, IXP dB and PCH at least their IDs to really identify which IXP is being talked about if I reference, for example, to IXP DB ID 1 which has PeeringDB ID 5 and which has PCH ID 77 or so, because the names are not always identical.
STEFAN WAHL: Thank you very much. I haven't put PCH in because I had only 15 minutes.
AUDIENCE SPEAKER: Otherwise I don't see any need to coordinate between IXP dB and Peering DB. Honestly I would shut down IXP.
STEFAN WAHL: I will not comment on that.
WILL VAN GULIK: Do we have any other comments about that topic? Because I still think it's something interesting. Oh, someone coming.
AUDIENCE SPEAKER: This additional services, I am not quite sure that they are needed to be public in some databases especially peer NIs for example but there is one service that could be automation but it's very important provided by IXPs which is the multicast, which is very important to be listed in certain places for IXPs that do all these kinds of things.
STEFAN WAHL: Okay, thank you.
WILL VAN GULIK: I am thinking out loud here, but we also discussed the timing, the BGP things recently, so that might be one service that we should consider because because that's something quite curious.
Any last comments?
STAVROS KONSTANTARAS: Stefan, great presentation, thank you very much. How would you consider going forward in terms of adjusting the schema to cover the current needs? How would you think of a corporation model or some small community of people that you know they are going to take into questions or requests or just a model, how do you envision this?
STEFAN WAHL: There is no short answer on this. You mentioned that there is maybe a small team, all my experience over the last decades, I am sure that if you have less than seven people you find the solution. If you have 70 people you will never find a solution or it takes a long time. We are using APIs. APIs has version numbers. There is no problem to have a Version 1, 2 and Peering DB Version 3 now, there can also be Version 4. So, why don't we add features and make a new version tech on it. If it's not used we see this and we can adapt in the next version. So I would have a different approach here, not aesthetic as we do today. I would like also to use what the industry is using, IX‑API, great stuff. There is a lot of information inside we could use and we see what actually the customers using inside the automation tools. So why not use this information and also add this to the directory stuff. This can can done in a small team. I would suggest something like a hackathon and maybe also working together is a good idea with Peering DB as we shared information here. Also working together with peering manager, there is a peering manager is more than 50% of all Internet exchanges worldwide using peering manager, work together with them, talk about what they actually need, what the customers need and add these features. If it's not working, we make a new version.
STAVROS KONSTANTARAS: Maybe we can talk to the RIPE NCC completion for a hackathon.
WILL VAN GULIK: Thank you very much.
AUDIENCE SPEAKER: Hello. Just a thought about this presentation, right. We see ‑‑ as far as Layer3 services are concerned, it's not a taboo anymore, we say that loudly, many IXPs are already doing Layer3 services, it's a thing, it's one the services we are providing. So, if we are creating and commanding this scheme would I say it auto bandwidth useful to do surveys to understand actually what are the Layer3 services that some of us are doing already and trying to standardise them because now still today, we have always been concentrating on Layer2, peering, peering, peering, that's it still peering is there, but caches, partial transit, you know, service ASNs and so on, it's something that that is to be discussed either in RIPE or Euro‑IX, that's my point.
STEFAN WAHL: I jumped over this slide. I think I have five seconds left. With this Layer2.5 service, we get 85 gigabit of traffic so it's actually already used.
WILL VAN GULIK: Thank you very much.
(Applause)
Now on with our last speaker, Nina is going to talk to us about the have of full route peer for route collection.
NINA BARGISEN: Hello. This is a lightning talk so it's going to be quite short. But I have been playing with data like so many other folks, so I wanted to share that in this group a little bit with some of the stuff that I have learned and why, and a little bit of explanation about why we're doing what we're doing.
So first off, in case anybody forgot or haven't heard about us before, RouteViews is a route collecting project and it's a tool that means that you can look at the BGP table from different backbones and in different locations around the world.
We are working on a basis with sponsored collectors that are sitting at IXPs. We are currently at 52 collectors and still growing the platform. But how do we want to grow it and where do we want to grow it is part of what I'm going to talk about.
The background, it's a very old project, we were started back in 1995, based out of the University of Oregon. It's still based out of there and is now operated by the network start‑up resource centre, another organisation based out of University of Oregon and partly funded by the national research fund in the US, and private sponsors. Anybody want to help, let us know, we can always use that.
So, what are the challenges when you are collecting data year over year over year over year?
Well, it is that your storage needs grow and we are growing our peering base as well because we want more data and it all means that everything grows, so at some point we started thinking about is it the right peers we have? Is it the right strategy we have? We were operating in a fully open, anybody asking? Yes of course we want your routes and basically we want your routes.
But, we were thinking about it so a little bit over a year ago, we came out with new peering strategy. We were a little bit more selective and we definitely went on preferring people who will give us a full routing table and not a standard peering configuration.
And the underlying strategy that's not part of the policy is also we are chasing people who were operating on the edge of the Internet. Do you have many locations on the edge of the Internet and will you give us full tables from there? We believe that you will be a very good peer. But we hadn't really checked it out at that time because we didn't have the time, it was more based on industry knowledge on how the Internet has evolved over time, I think I talked about it a year ago, and sort of this is what we think is useful.
But then a couple of weeks ago, I got into the analytic mode and I started thinking hey we actually have the data so let's have a look at the peers that we had. We also gained for me very attractive peering, content networks with a lot of sessions in a lot of locations, so I wonder if I can count something useful and see if they actually have a value or not.
And this is what this is short talk is about.
So, what kind of information do I get when I look at what people are announcing to me? Well, maybe there are some unique prefixes. Maybe there is some unique origins. There are some unique edges. We're peering folks, we love edges, right, we love paths. And maybe there is some shorter path and we love those too.
So, we can look at that, what's in that dataset, compare it to the rest of the dataset, oh that's a lot, but it's possible. And then we can sort of roll it up and look at total ASN, how much value does that bring.
So etc. That the attempt that I have here
Just a little bit of definitions. Edges: Basically, in the AS path there are two ASes next to each other. That's an edge. So for A, B, C, D, we have AB, BC and CD.
Paths: That's the whole AS path, except it's not ‑‑ we strip out the peers AS because otherwise all the paths are unique and it doesn't really make any sense.
So, does this AS see some prefixes unique to anybody else? That is basically what we are ‑‑ we try to look at.
Then I now have a bunch of examples.
So, all these ASNs are my favourites. You are all my favourites. But this particular favourite is, we have a number of distributed sessions throughout the world with these guys, but they are a traditional backbone network and we see ‑‑ we have a few unique paths but not really that many. So, for this table, I need to explain that the uniqueness here is compared toe these other sessions and the rest of the dataset. So it's the individual path compared to everything else. Here we're rolling out to the ASN and we see we have a little bit more, but, you know, only less than a couple of thousand unique paths from these guys. We still love them because we have like 3,000 shorter paths, so you get a better way if you use these guys.
.
Does this make sense? Anybody looking ‑‑ I see people nodding. That's great. At least one person, so I love it.
Same story for IPv6.
So, but, you know, and this is something I am going to be looking at further on, so this is a single Tier 1 provider. I wonder if what happens if I pool all the Tier 1 ASNs that we peer with together? That's going to be an interesting thing and I'll come back with that later. I haven't done that yet.
Here is one of my favourite content providers. One of the reasons they are a favourite is we have a shit load of sessions with them and if you have a look, all of those sessions, each of those sessions have a good number of unique paths, and remember, these are compared also to the other sessions. So, those are good guys, and then when we pull it all together, we get a really good number and we also sort of like are getting sort of okay, 1% of the dataset is actually something.
So, and the same story on IPv6 for this network. We have some other guys with a different technical setup in the way they peer with us. The first one that we're just peering on all neutral locations but this one we have multihop sessions and they have been kind enough to do internal work in order to provide us and other route collector projects with this kind of feed. So thank you very much.
.
Again, some sort of like okay, we kind of knew this story but, oh, we didn't know that story. So that was great. And I know, I didn't disclose it here, but these are from different regions of the world, so thank you for this one. And it all aggregates into something really nice. And same story on ‑‑ that was actually IPv6 that I was doing. This is IPv4 also lovely good story. Sorry about that.
Just for fun, I took a normal peering configuration, so this is a good network in Asia, thank you for peering with us, thank you for giving us your data, but when you are just announcing your customer cone to us, we're not learning a lot about the local topology. But that's okay, we're learning something else, and we still want these sessions and we still want people's customer cones as well, but on a topology inference spectre, it doesn't make a lot of new data.
Then finally, a regional provider in Africa, again we say well we want feeds from you in different locations, in Nigeria, in Kenya, in South Africa, but it turns out it's not really a lot of difference between those sessions and we know most of what's announced to us already except when we aggregate it we get some new information, but we still love you guys anyways, so keep peering with us. Same story for IPv6.
Yeah, I made a summary. You can see the trend quite heavily.
So, from a perspective of the data showing the topology of the Internet, give me your full sessions in as many locations as you can if you have a lot of peering, we would love that. And we would love to work with you if you technically can't do that and you need some other solution, we will find that.
Okay, questions, comments or coffee break?
WILL VAN GULIK: Thank you very much, Nina.
(Applause)
.
That was good. We have got one person at the mic there. Okay, two.
AUDIENCE SPEAKER: Sebastian Becker. Thank you for your great work. Continue please.
AUDIENCE SPEAKER: Martin from Yellow, AS 9075, so happy to give you our full routes. I was wondering for our own information about what you showed for the others and I was wondering how do we, can access them because we are happily providing this full views, but we don't have the analysis on our side. So, I was wondering how we can access it for us?
NINA BARGISEN: That's a very good question, and I can say that we are, we are working on and thinking about if we should do something for people who give us the full feed exactly by providing them with some of the analysis that we do ourselves, also to make it sort of a measurement for that.
But we need to balance it with that we are also a service that completely rely on the community's goodwill, so, it's kind of a balance. All the data is there, so anybody can pull down the data and, you know, feed it into whatever you like to feed it into, or write a very good code yourself and make the same. But obviously some of these contribution things is something that we want to display in one way or another to people who do make large contributions to us.
WILL VAN GULIK: Great. Thank you. I think we're done with that. Thank you very much.
Perfectly on time. So, we are almost done. We would like to remind you to rate the talks please. It's really useful for us. It's really useful for you, all the crowd there, because then you will know that you get some better talks next time if we did a bad choice and that you didn't like a speaker or whatever.
I see someone lining up at the mic. You have got a comment. It was for the previous speaker or for us?
AUDIENCE SPEAKER: Apologies, I have a 30 second advertisement when you are ready.
WILL VAN GULIK: Okay. So rate the talks, And then I think we will see you the next RIPE meeting in Sophia and you have got your 30 seconds starting now.
AUDIENCE SPEAKER: Hi, I am Mike Blanche, you might remember if you were in Bucharest I came and talked to you about what might be coming in the Digital Networks Act. It's been, the draft has been released and I am talking about it in the Cooperation Working Group in the other meeting room in the next session. There is a lot of interesting and concerning stuff about new networks being brought into the scope of telecoms regulation and the European Commission looking to regulate how you interconnect, how you peer, regulators monitoring this and it's ‑‑ if you have some time, please come along to the next session. Thank you.
WILL VAN GULIK: Thank you very much. I think that's useful.
.
With that, we can close the session and go for a coffee break. Thank you very much for coming this early this morning and we'll see you next time in Sofia.
(Coffee break)
.