Closing Plenary
BRIAN NISBET: Good morning. How are we all this morning? Closing Plenary session of RIPE 79. We have the happy few who are here at this point in time. We have some excellent talks this morning. And then we will let you all go home.
Before we start, I just want to announce the results of the PC elections, and thank you all for participating. 499 votes, which is a really good number, and shows a really good interest in the community in this particular thing and it's really important that we get good people so we can curate really good content, and thank you to everybody again who submitted a talk for the Plenary sessions; whether accepted or not, it's vital that we get in a really good content for the meeting.
As I said, 499 votes cast, and the two people elected are Pavel Lunin and Dmitry Kohmanyuk. So congratulations to them.
And we'll be doing all this again in May, it's a regular thing, so please, we really do encourage more people to step forward for the PC.
So, in a slight change to the advertised running order, we're moving somebody up to the front, because they ‑‑ you know, flights apparently, so, first off, we're going to have one of our lightning talks, which is from Doug.
DOUG MADORY: Hello, everybody. Thanks for accommodating my travel requirements.
So this is a project that we have been working on on and off for the last year or so, looking at route filtering at IXPs and high we might be able to contribute. We are known for doing analysis, it would be nice to build a tool or service that might make things better, so this is a little lightning talk about a tool that we're in the programmes of releasing, a first edition.
And so here is the motivation. So, we see IXPs having a unique role in trying to improve routing security. Obviously we all know in this room, this is a notoriously difficult task, but incremental improvements are possible, and route servers, those mediating thousands of connections at exchanges offer a great opportunity to do route filtering on behalf of their IXP members as well as for the good of the greater Internet.
So, last year, the MANRS programme extended its programme to cover IXPs and in that the thing that was interesting to us is that the technical filtering portion here in the red box. And what we looked at this last year, and said you know, could we help here. Could we measure this. If we could, the benefits would be twofold. Maybe we could offer some sort of technical verification of MANRS compliance for IXPs. I'll admit that, I don't think we're there yet, where we offer anything that would assure compliance or give a grade, a letter grade top compliance. But, I do think we have achieved something with we could offer some feedback to IXPs, specifically a route server admin in order to try to improve route filtering.
So, to accomplish this we needed to collect routing data from IXPs. And since this is a lightning talk I'll spare you the revolution of the project and skip to the end. We partnered with the PCH. They publish MRT files from the IXPs that they are in, there is approximately 180 or so of these. These MRT files contain all the messages collected with the route server as well as any other entity that they are peering with at the exchange.
For anybody who has worked with this data, you'd be familiar with the, there is some logistical challenges with working with this, and this ended up being a big part of our project, was just how to handle all of these files. So, the way this gets published is, there is one MRT file per minute per exchange, so we're doing about 1,444 files a day, and a that's about a quarter of a million files a day. We have toppled over their servers a couple of times this year, but we're grateful that it exists, because to get this any other way would be very, very hard to come by.
This is a very simplistic flow diagram of how this data is flowing, we have got exchanges all over the world, data collected by packet clearing house, we have got this elaborate system pulling down a quarter of a million files today to our or ecosystem Cloud infrastructure where we are evaluating these messages, pulling out the route server messages, evaluating them and then offering a daily update of the things that we're seeing at these exchanges which is live now, we'll look at that in a second.
So what can we do with these messages that we're seeing at the route servers? So, unlike some exchanges, notably AMS‑IX offers an unfiltered view of, unfiltered session with a route server where they will send you the messages that they filtered and tag them with communities, letting you know why they filtered each one, that's really useful to see how their filtering works. Not many exchanges by the numbers have really implemented something like that, so we can't positively confirm that's been filtered, we're seeing the messages after they have been filtered. However, there is still value there for this project, because we can see the things that ostensibly should have been filtered, but were past by a route server anyway.
So things like RPKI invalids. We did add an exception for DECIX for the invalid lending on a message marked with a D 66 community, this is their blackhole mechanism, and they are the only ones using this mechanism. But, typically those are /32s and they are always always RPKI invalid if the route had a ROA, the message is invalid, so we spare that out of the statistics at their request.
The IRR unknowns, this is another category we're looking at. This is simple origin validation which we know is not really how the exchanges are doing their filtering, they are more, it's more a process of resolving AS‑SETs, creating white lists and they're not really, the filters are not aware of route objects at that point, so, those are collected but the value may be unclear.
Bogons are straightforward. Carlos brought this up yesterday. Our experience with Bit Canal last year we thought it would be worth highlighting where are some of these bad actors at exchanges, if they are there, and there may be controversial thing that we have added.
So here is the view if you were to go to this link, and take a look at what this site looks like. The opening page is just a list of all the changes we are collecting data from. Again, through packet clearing house and the summary statistics of unique route, in this case is a prefix and an AS path combination. And how we evaluated those. And you can ‑‑ we tried to make this useful to a route server admin so that they could maybe use this to figure out where our gaps in filtering, so we tried to be very verbose in the data that's presented. If you were to click on a particular exchange and you could explore what are all the prefixes that have failed some sort of ‑‑ or been an exception to one of these rules, and for each of these, you don't have to take our word for it, each of these links is hyperlinked to an outside source. The RPKI goes to the RIPE validation UI and IRR stuff goes to the IRR explorer. Them you can also click on the prefix itself. And it will grab all the messages seen in the previous week for that prefix at that exchange with communities' time stamps and how we evaluated it. So the hope there is that is enough information to trace down a problem if there was one.
And I would say that in the course of this project we have had three different cases where we were collecting data and speaking to folks doing filtering out the exchange and found problems either in one case the filtering had fallen over and no one there knew. There was a case where they have a very elaborate system where they thought they were filtering and in the end it turned out that they weren't. And another one where the updating had stopped and so they were slow ‑‑ the RPKI state was slowly getting out of date and I think more invalids were creeping in. So, I think those experiences validated the need for some sort of external monitoring and kind of encouraged us to keep going on this project.
But, so this is our first try at this, and I'm sure it will evolve over time with feedback from the IXP community, but this is what we have got. So, I want top thank a number of people who helped advise and contribute their insights in our data, and that is recollect that's my lightning talk.
(Applause)
CHAIR: Thank you. Do we have any questions?
AUDIENCE SPEAKER: Hi.
CARLOS FRIACAS: I think this is ‑‑ this is not a question, but do you have any contacts from any IXP saying or asking to be exclude from that list?
DOUG MADORY: I haven't. Maybe I will. But no, I have not.
AUDIENCE SPEAKER: Thomas King, DE‑CIX. That's a really cool tool, so thank you for that, first of all. I just wanted to point to a second source of data which probably is helpful. There is SLAs Looking Glass which comes with an API and which a lot of IXPs nowadays, and this tool comes also with a feature so that you can see which route or which IP prefixes have been filtered down for and for what reason. If you don't see that on the PCH data, you will see that on the SLAs Looking Glass.
DOUG MADORY: We did have a call with the Atlas Looking Glass guys, it's a good point. Not everybody is running that, so we kind of wanted to go for the biggest at a first hack try to see if we can get the most exchanges at a time. But that's a good point.
CHAIR: Okay. A personal thanks for my side for mentioning trouble with working with certain datasets, maybe we can reach out to some of them and ask them to help us be more able to ‑‑
DOUG MADORY: In the meantime, if there is any anybody that is interested in working with this data, and doesn't want to download a million files, we have this on disc, so come find me, I'm happy to share that. I'm sure packet clearing house is okay with that too. That was a lot of work.
CHAIR: Okay. So thank you very much.
(Applause)
The next talk talk is Thomas King from DE‑CIX.
THOMAS KING: Good morning everybody. My name is Thomas King, I am the CEO of the DE‑CIX and I am prepending joint work which we have done together with AMS‑IX and Linx, which is about the IXP API, which is an API for provisioning interconnection services.
And let me quickly motivate why we have started this. So it's mainly because you, our customers, have asked for that. We had a lot of discussions lately with our customers, actually when we started this roughly one‑and‑a‑half years ago or so with our customers, that they were asking for an API so that they can easily provision, configure, cancel inter‑connection services. And so it happened that AMS‑IX and links, we were talking about this request for demand, and as we were all, all TTL three of us were already starting their own APIs, we were saying no, guys, that's the wrong thing to do, we should come up with something that is of value in terms of that our customers only have to implement one API instead of three, or only one if others start providing APIs. We were saying we should joint forces here and start something that probably will end up in a standout which can be used within the IXP community.
And the reason for why our customers are asking for this kind of API is because we see that the interconnection set‑ups you are running get more and more complex, there is not only peering and transit any more, you have different interconnection requirements, PNIs, a lot of Cloud connectivity going on nowadays, data centre interconnects, all this kind of stuff, and so we see your requirements of having a tool or making it easier for planning and deploying infrastructure, especially interconnection infrastructure more quickly and more easily.
And this was the driver for us to start thinking why we shouldn't work together here. And we also realised that the businesses for Internet Exchange, especially large Internet Exchanges, changed over time. Now the large Internet Exchanges, like AMS‑IX, Linx and DE‑CIX, they do not run only one IXP any more, they actually run a lot of them. In terms of DE‑CIX, we run 18 all over the world today, and I guess we will start new ones where it's needed over time. And we also see that we do not provide peering services only any more, we also, as customers, were requesting that from us, we were starting provisioning or providing other interconnection services as well, I already touched it, Cloud connectivity is quite huge nowadays and remote peering, especially if the IXPs run by the different operators are interconnected, is seeing a lot of traction.
The VLANs between data centres and also covering larger areas, not only data centres in a midway area, but also regional connectivity is often provided by IXPs. And lately, also paid peering got a lot of demand and interest from you guys, from customers, so IXPs also started providing paid peering services.
And so, you know, to cover also this more complexity, which is coming with providing more locations and more services with us thinking about how we can make sure that, that it's easier for you, as a customer, to consume all of this.
And we also realised ‑‑ and that's not new, right, we see that everywhere, that if you have repeated jobs to do like provisions services, that's error‑prone for humans, because humans are not good in doing things over and over and over again. They are good in thinking createively and, yeah, and coming up with clever ideas. But doing repetitive jobs over and over again is not something humans should do, And it's always time‑consuming, and especially, humans are usually only available during business hours, they need to sleep, they want to rest over the weekend. This kind of stuff, so a computer and API can be available 24 hours whenever you need it.
So, that was the reason why we were saying we need to really dig into this topic and come up with an API that allows us automating this kind of stuff so that we can provision interconnection services a lot quicker, a lot easier for you to consume. This is what we did. So we were looking deeply into how we can also reduce the complexity during the provisioning process that you will also see within the API, how it is structured. So, because the provisioning processes we have been doing for so long, 25 years or even longer, they have, you know, developed over time and we never sat down and think why do we do this step or should we improve here? We reviewed all the processes and came up with cleaner processes.
And we can also now provide interconnection services within seconds or minutes instead of hours, as is before, when humans were involved.
And in the end, that will also reduce the cost of, for you guys, for ordering and provisioning interconnection services, but also if you want to connect to different IXPs because if they all provide the same API, you only have so implement the API once and then can you know just change the end points, you want to talk to, and then it's easy for you guys to use the API.
We hope that that will become an industry standard over time. This is why the three largest IXPs started doing that, and we are already in discussion with the URX community and the IXP Manager, for instance, that's a tool you probably know for the medium to small IXPs, it's heavily used around 70 IXPs use that, so we're in discussion with them, how we can get IX API into that.
And in the end, what we want to do is we want to free up our scarce resources in network engineering from repetitive work and make more room for creativity and, you know, coming up with clever ideas so that we can generate even more value.
So, let me quickly go a little bit more into details about what an IXP is, how it works and how the API works, what it really does. Because, so far, I have only, you know, talked about motivation and, you know, more high level stuff.
If you look at an IXP, you'll see that an IXP usually covers a certain area, it's not only a switch nowadays, sometimes it is but usually a little bit larger, it covers several data centres, and by covering, I mean IXPs run a Layer2 network, covering different IXPs ‑‑ sorry, different data centres. And usually they also provide route servers as a means for easily setting up BGP sessions so that when you connect to an IXP you can exchange a lot of data because you get a lot of prefixes with the route server.
Let's have a look how a customer usually connects. Usually it's within a data centre and he just connects to the infrastructure run by the IXP. And, of course, we also have resellers nowadays so the reseller is in between providing transport services to get to the IXP from the place where the network is located because sometimes the network is not in the same data centre as the IXP.
And as I was already saying, that remote peering gets more and more demand and is more and more used. We see that the different IXP networks for different regions are interconnected somehow, and I just draw that here quickly so that you can see that. Remote peering is supported by the IX API.
Let's have a look what needs to be done, what are the provisioning steps you usually ‑‑ we usually, together, you as a customer and we as an IXP, operator do together to set up an interconnection service. Let's focus on the the peering service, it doesn't matter if it's local or remote.
So, the first step is that we will ask you a lot of questions about who to contact in terms of implementation contact, who is a peering contact, who the the legal contact, all these kind of questions, we need to register a lot of contacts to know whom we have to talk to.
The second thing is that the Mac address of the customer's router will need to be registered to the infrastructure of the IXP because, nowadays, IXPs usually run a certain level of port security, so we filter out a lot of protocols and also only allow the single Mac address to talk to the whole Layer2 network, that is registered, just to make sure that there is not anybody else interfering with the Layer2 network.
And then we created a VLAN configuration, so that depending on if you want to run VLAN or if you have dedicated port so that you can be part of the Layer2 network where the peering happens.
And then, after all that is established, we then usually create together with you a route server configuration where we ask you a lot of questions for filtering, the IRR database filtering and all the RPKI stuff. So that you can easily connect with our route servers.
This is provisioning steps we usually do together, and this is exactly what we did with the API. We mapped these steps, these different steps, one to one, into a restful API call. So let me quickly go through the list. It is exactly the same list from the slide before.
For registering the operational contacts, we go to the contact part, and there is a post request for contacts. We do the same thing with registering the Mac address, there is a post request for the Mac addresses. Then we create the VLAN configuration or you create the VLAN configuration on our side if you, as a customer, are issuing a post address saying you want to have this network service configuration being configured. And the same is true with creating a route server configuration, so you are telling us that we should configure a certain route server configuration. And, of course, you have to provide some parameters. And actually, I will quickly give you a demo of how that works so that you really can see how this API works.
So, we have prepared a video, and I will quickly walk you through how that looks like. So for ‑‑ you probably are aware of Postman, Postman is like an IDE for using APIs, right. So, what you do is, you have to configure the end points, for authentication you have to configure different keys, the secret and things like that. And this API ‑‑ so this Postman collection we have created here you see that on the left‑hand side, there are different sets of API requests, we already have prepared. And I will quickly go through that, creating the contacts, creating the Mac addresses all this kind of stuff.
As this is already going forward, you can see that authentication part is already executed and, you know, if you authenticate yourself you get a token back for the session, that session token is automatically put into the environment of the Postman session and then it starts. Here, this case, we are, we are reseller, actually, we are the reseller IX switch, which doesn't exist any more, I guess, because it was acquired, and it's just an example here. It could be any other reseller as well. And you can see that, that we now are creating a sub‑customer for them, so that we can configure services and interconnection services, actually peering service for this sub‑customer. And this sub‑customer we're creating is called Any Name Corporation, and as we are setting the parent to the reseller, it will be created as a sub‑customer Of IX switch.
So, we see that this value is then copied over to our environment so that it's used for further requests we send via Postman. Then, as I was already saying, we will create quite some contacts ‑ the implementation contacts, and all this kind of stuff. Today, the contact list is empty and now we fill it up with information. We create a network contact, implementation contact, legal contact, billing contact. Peering contact, this is the information we need at least to start doing business with you guys. You will see that it will be automatically filled out here. I don't think that's a lot of interest for you. It's just shows you that it's ‑‑ how it works, right.
The next thing will be that we then create a demarc, and/or actually we get a list of demarcs. These are the physical ports that are already existing where we then can configure peering service or interconnection services and channel on top of that. And we will see that after we have seen that now, if we request all the contacts we have just created from the API, we think that now they are all there.
So, moving forward, with the demarcs, so we request all the demarcs that are available, so meaning the physical ports that are configured for the reseller, in this case, we see that there is a 10g export available, and it's instead production and it's at site 87, so we map the different data centres in the API.
And, of course, you can then, you know, based on the ideas for use, you can figure out where that is looking into the different facilities which are already modelled in the API.
And then, as I was saying, we need to reduce the Mac address of the customer. We are the API, so that is known by the system. And can then be later used for creating a network service. So, here we get an overview of the different network services available. And we will create a new one.
So, you get ‑‑ it just shows you all the data is there, you have an overview of how that can be used.
So, now, we are creating the network service config, meaning the VLAN setup or even a dedicated port can be used and we also, in this case, we configure a VLAN. We specify which VLAN we want. We can provide a range, so the server is picking the one that would work which is not taken on this particular port. And we provide ASNs and all this kind of stuff.
And after the network service config is created, we move over to creating the route server sessions, which are called network feature configs in this case because we abstract from peering, because this API is meant to be for any interconnection service, so in a peering service, we have as a feature, a route server, but for different other interconnection services, we might have other features. Though they are modelled here like this.
And you also see that after the network service config was created by the API call, and there was a new API assigned to that network config, meaning that now we have an IP address that can be used within the Layer2 network for communicating with all the other routers in that Layer2 network, and then the next step, as I was saying, there will be the route server configs created.
Of course we separate here the legacy IPv4 and the more new one, it's already 20 years old or something, IPv6. So we are generating a route server configs for both of that.
And as we walk through this API calls, I directly want to show you how that maps into the internal systems we are using at DE‑CIX. Internally at DE‑CIX, we have an automation switch we call ARTEMIS, which allows our customer service to interact with our systems directly on a, you know, like on a website, without needing to config anything on a console. And you will see that here, so we just look up the any name corporation and it takes sometime so the DE‑CIX logo is bouncing to create the database, and then you will see that this service is already provisioned within our internal systems. And here we have created a service in Frankfurt during the API calls that I just showed you and we add a remark so that also our customer service people are aware if there is an issue and you call them to figure out what's going on, or if you need to resolve an issue, they can directly see that what we have created was coming through an API, so that they can help you with that as well.
So, I think that's pretty much it. I don't think we need to go into the details about the ‑‑ that the IP addresses are correctly configured. So we can switch back to the presentation.
Thank you for switching.
So. We would like to ask you, if you are a reseller or a customer or an IXP or any other kind of interconnection provider, please think about implementing the IX API. We have a website where we have a lot of documentation, a sent box, yeah, a lot of material need to start working with the IX API. It's all there, please go there and have a look, and I want to emphasise that there is a workshop next Sunday during the Euro‑IX forum where we will have a discussion about the IX API and how IXPs especially can use that and will use that.
And it's super important that the IX API is an open project. So, the three largest IXPs started it, but we want to make it as open as possible, because we know that, you know, we have some demands to the API and we have a view of the world how it looks like, but it might differ from other customers' and other IXPs' view, and so we want to make sure that everybody can contribute to that. So what we have done is we have generated a very simple governance model which actually works like this.
We have a board, and the three IXPs are part of that board. And we have members and we already have other IXPs being part of that, who contribute with ideas, with specification, with discussion and also with code, to further develop that. And we have pilots and pilots are more the clients of using the API.
So we have separated because this, between members and pilots because we see that there are different demands. IXPs have a different view on things. And clients of the APIs in general have, so we have put this into two groups. And within the clients of the IX API, there are mainly resellers like Interaction, they are also the launching partners of the IX API and they heavily contributed to that, so it really helped us making the IX API what it is today.
And this is exactly how we also want to drive that over time, so that's the starting point from our point of view, that model will probably evolve as we go, depending on how much direction we see within the industry.
And the board has a final say on how the specification should look like so they give the final go‑ahead for releasing a certain version of the IX API specification.
So thank you very much. I think we dropped one slide about the road map for moving to the video. Could that be the case? Could we go back to the slide with the road map? Could you please quickly go back, or can I do that with this? Let me try that. Because I want to show you what's coming next.
Here it comes.
So, before I finish, let me quickly give you the overview of how we see we will develop the IX API further.
So, today, we have Version 1, which mainly focuses on peering released during EPF. We are already working on adding support for private VLANs and Cloud connectivity. We will do that in parallel. And we guess we will be ready releasing the specification and also the box code and everything else within the next six months. We are working heavily for that with interaction and with Epsolom for that and we already have a backlog of additional features which we haven't, we didn't put on the roadmap yet, because they are not really clear to us today, how they should look like, so, for instance, statistics monitoring and even more details about physical infrastructure, that probably will come, depending on what you guys need and want to see there.
So that brings me now to the end.
BRIAN NISBET: I think we all know there is a questions slide there.
(Applause)
I didn't see who stood up first. I am going to work left to right here.
AUDIENCE SPEAKER: Erik Bais. You mentioned ‑‑ first of all, let me start with, I loved the presentation, loved the effort that AMS‑IX, DE‑CIX and Linx are doing here, I think this is very helpful for the community. One special thing that I think you owe an apology for is to Stephen Wilcox from IX Reach; the remark you made there was inappropriate.
THOMAS KING: I'm sorry, I didn't know. So ‑‑
ERIK BAIS: I will definitely change that line about IX Reach ‑‑ it's okay if you leave a company and you use it as a demo account. The remark on it was not okay.
THOMAS KING: I'm sorry, I didn't want to ‑‑ yeah, so, I'm sorry.
AUDIENCE SPEAKER: Will. Representing a tiny, tiny IXP. I was wondering why you didn't came to the community first before doing the thing with the three big ISPs.
THOMAS KING: What do you mean with coming to the community first?
AUDIENCE SPEAKER: There is another project ways called IXP Manager which tiny IXPs use, there is an API there that does a lot of cool things. Maybe it could have been an opportunity to go and add some of the features that you needed there, maybe that that was an option.
THOMAS KING: No, it wasn't an option for us. First of all, let me say that the IXP Mandate tool is great tool. I love it. The bad thing is, neither AMS‑IX, Linx or DE‑CIX is using it. So, this is the reason why we didn't start with IXP Manager because we have our own tools running within our infrastructure, and we needed to come up with something that worked there, because, to be honest, we do it for our customers first. Of course we want to make it available to the industry, and then, from my point of view, it brings the most value to our customers if it's for them easy to interconnect with other IX API to all the IXPs they are connected to, but we needed to have a starting point somewhere and this is exactly where we started. We were saying, look, we know there is IXP Manager, etc. But to get the ball rolling quickly, let's focus on what we have today.
BRIAN NISBET: I realise I am biased from the point of view of IXP Manager, but it does seem like, I mean, all of us in in this industry seem to love inventing new tools as often as possible for a variety of things. But, I mean, so noted, but it's just one of those just general observations; like, oh, this is a tool that does this thing over here. But I have my own tool that can do the same thing over here. So...
AUDIENCE SPEAKER: Marcus Stoegbauer. One question that comes in my mind: Did you do any research before you started this API if other IXs were maybe out there who are using an API? And just to put this into perspective, we have an API for ES already, and which are tactically doing those things. I am wondering why there is a new one which is being pushed by the major players and it feels like that something that you want to push into the market to have an advantage and not talk to the smaller IXPs which are out there, and which ‑‑ which knowledge could be incorporated in such an API while developing it.
THOMAS KING: Yes, of course we did a lot of research what is out there, but we figured out that none of the APIs out there exactly cover the needs our customers were telling us and we were seeing. So this is why we were sitting down saying we need to come up with something different, and this is what we did. So, I'm not familiar with API, you guys are providing, but, in general, we have spent a lot of time researching what is out there, and, you know, the APIs out there are good in some regard. My point is the part ‑‑ my understanding is the megaport thing is really good in Cloud connectivity, and is focusing mainly on that. I might be wrong, but that was our impression back then, and, as I said, our goal was to come up with an API that works on protocol provisioning interconnection services overall, and, based on the requirements we got from our customers, we came up with what we have today.
AUDIENCE SPEAKER: I don't mean that our API should be used for anything ‑‑ or for everything, obviously, but, I mean, there is experience out in the market and apparently you chose to ignore all this experience and start your own thing. This is what it seems like to me.
THOMAS KING: That's not true. For instance, we selected for good reason interaction with Epsolom and we were talking an a lot of other companies as well, if they wanted to join this effort. Interaction and Epsolom said yes because the time and resources and money to work with with us on that. Others, for whatever reasons, didn't decide to join in the early stage. But the reaction is very strong in having an API for Cloud connectivity, for instance, so we were building on that experience and developing together the version 3 of the API with us. And again, and just to make the point, if you think you can contribute to the IX API, it's an open project. Please come and talk to us and contribute and help us making it better, because it's just Version 1, right. There is a long way to go to put all in what we want to see there, and so if you have something, please join us.
AUDIENCE SPEAKER: Martin Levy. As a company that puts an awful lot of stuff on GitHub and yet always runs our own version of that code internally, I am wondering when this is going to end up on GitHub so that your community can, in fact actually be made true. You got into a bit of a spat on Twitter a few days ago, so you have had a few days to think about this one.
THOMAS KING: As you probably know, Martin, it's available on GitLab for a long long time already.
MARTIN LEVY: I am showing my bias here, my apologies to those who are GIT lap lab but I stand by my comment.
THOMAS KING: It's available on GitLab, everyone is welcome to contribute. And let me end with the last comment. Steve, if you hear me, I am sorry for what I said, it wasn't meant to be a criticism or anything, it just was an example to me. So, sorry if that got into the wrong slot.
BRIAN NISBET: Okay. Thank you very much.
(Applause)
Okay. So, Meno is there. Obviously, as always, we, roughly 800 of us, show up in a random building somewhere in Europe or the Middle East or possibly even further afield at some point in time and expect the kind of network connectivity we have in our offices and all the services and everything else. And we generally get it. And Menno is going to tell us how they did it this time.
MENNO SCHEPERS: Hello everyone. I am doing the technical report. The RIPE meeting has been set up by a team of colleagues from the office in Amsterdam. This is the core team at the moment. And in the weekend, we also had help from four more colleagues from Amsterdam. They helped us set up everything here.
During the setup weekend, we set up a lot of stuff like, well we make sure that everyone gets blinded while prepending, we bring the servers here, we set up switches, access points, a lot of stuff listed here and we got something new as well, that's the limit timer, I'll show you a picture of it for those who haven't seen it. It's actually telling you how much time you have. It's saying I have 24 minutes, I think that's way too much.
I'm going to go a couple of slides back because I wanted to show you the if the fibre cut that we have had. This was a week before the meeting, all of a sudden we lost connectivity to our router that we already installed here. And that was a bit scary but also we were quite lucky, it was a week before because it could easily be fixed. And there is still maintenance going on in the building, I think you have probably heard sometimes in the side room, I don't know if that was the same place where this fibre cut was, but I'm glad it happened before the meeting, otherwise it would have happened this week.
Eurofiber are our sponsor, quickly send a team here and it was fixed the same day, and everything was fine then up till now.
The Wi‑Fi setup that we have consists of a lot of APs, they are under your chairs and we set them up and configured them and we hope that everything works well on the Monday. Well, this Monday, there were quite some problems, people were noticing various issues, some of them had to do with our Wi‑Fi setup but some also had to do with the problem with our DHCP server. I'll come to that slide now.
The DHCP server that we have is an KEA. We have configured is active stand by and for some reason the stand by also decided to join in in handing out IP addresses. This resulted into a very strange situations and not all of you were experiencing issues but the more people that came into the room, into the venue, the more issues we saw. We fixed this by shutting down one of the two services, not a proper fix of course but we still have to see what went wrong because the config looked okay to us.
Then our routing setup. The last RIPE meeting, we used Bird 2. That worked well, but we spoke to Martin Winter and he wanted us to also give FRRouting a chance, so we decide, okay, and we thought, okay, let's use it. It worked well. Also, RPKI, we did see an issue with RPKI on the Monday and that problem was due to our VM server, the VM with the validator and the VM with the router, they started at the same time and we think that something went wrong there in the order, because for some reason, the router showed all the RPKI prefixes and then we thought RPKI was running fine, but running the test showed that there were some, that we were still allowing invalids.
So the problem was fixed by Marco. He reloaded the peerings and then everything started working fine. We should also have a look into making sure that that problem doesn't come back again.
The configuration that we used, we're going to upload it to GitHub where I'm going to put a link at least where to find it. We'll do that next week from the office.
Then, the NAT 64 network. It's quite interesting. A lot of people use it. We have a max of 110 people using it and a max of 656 people using the main network. And there has been quite some discussion also on the mailing list, the ‑‑ that the NAT 64 network should maybe be the default network. We also had e‑mail asking if we could do something like this or at least treat the networks more equally. I think it is possible that we make the RIPE MTG network by default the one with NAT 64, but, yeah, I was also questioning who should decide on that. Is that us, the ops team, or is it the IPv6 Working Group? But I think we should come up with the decision for the next RIPE meeting, everyone would like some clarity on that, because this is a thing that keeps oncoming back every RIPE meeting. So maybe something to think about, maybe we can vote for this or something. I don't know.
Then, I just want to thank everyone. A lot of people gave us feedback. A lot of people helped us, debugging issues, but there was also several people walked into the ops room with chocolate and, yeah, we like presents, so keep doing that.
And also thanks to the stenographers for doing an amazing job. And to also thank you Eurofiber for the connectivity. Thanks, Martina, also for helping us out, the ops team, and we are helping her and together we make this awesome meeting work.
And then thanks to everyone here in the room, everyone who participated to make this such a cool meeting to be at. Thanks very much.
(Applause)
BRIAN NISBET: Yes, there are, apparently, questions. Quite a lot of them.
AUDIENCE SPEAKER: Jen Linkova. IPv6 Working Group Chair. The question of SSA that keeps coming back and obviously we probably need to find something which makes everyone equally unhappy. So, the most recent proposal circulating between some people is, can we do an experiment during, let's say, one Plenary session and see how it goes, and measure the impact? Because it would be really interesting to see the number of users explicitly intentionally switching back to dual stack, because I don't know how people show which SSID devices they are not. I'm never sure, I always have to check because of the behaviour of your laptops and phones, it's unpredictable. So I suggest we might look into doing like an hour‑and‑a‑half experiment and see how it goes. Thanks.
BRIAN NISBET: Surely we can get Daniel to write a process where we can decide when we should turn the networks on or off again. It's not like he is doing anything more interesting.
HANS PETTER HOLEN: I just want to make a remark. We discussed this during the Working Group Chairs' lunch and the agreement there is that we would send ops team an e‑mail to ask for a proposal on how we could implement this, one way or another. And when we see that, I mean, that would give you some opportunity to think through a way of doing this safely and then we will make a decision for the next meeting. I mean, we don't need a big process for that, do we?
AUDIENCE SPEAKER: Andrei: Part of my point, because this is not the first change to the RIPE network. Me personally, I won't remember when IPv6 was deployed to the RIPE meeting network and there was a discussion should we enable IPv6 or not because just enabling IPv6 can break things. Also, I remember when I attended my first RIPE meeting, which was number 65 in Amsterdam, there was just the one SSID with 4 gigs or 5 gigs. Now there is a different SSID, so this is an easy change, and somebody who doesn't have 5 gig device have to change SSID. So those changes have been done and I don't remember any any big discussion, so maybe I think like you from the ops team should do the change in like a continuous evolvement of the RIPE meeting network with current standards. And that's how we should go.
(Applause)
BRIAN NISBET: I think it's worth saying, certainly from the organisation point of view, spitting out 2.4 and 5 gigahertz didn't ‑‑ broke very little, you know, it was the same thing. But absolutely, I mean, the point is fair.
AUDIENCE SPEAKER: Fernando Garcia. There is a remark about the same thing, NAT 64. I remember I connect to that network in Reykjavik, my laptop won't remember it and I was connected all the week to it and I didn't discover it ideal. Yesterday, I tried to do an SSH and it didn't work and I discovered it was I was using the NAT 64 network. So really good work.
AUDIENCE SPEAKER: Just a quick comment. Every time I walk into a RIPE meeting then my phone would connect to RIPE meeting because it's the same NAT. What I'm suggesting is, we keep calling the RIPE meeting ‑nat64 and we want to rename RIPE meeting to ‑legacy and a lot of people don't have chat and they have to explicitly choose to stay in one or the other. That would kind of stop the pre‑existing SSID bias that we are now witnessing. So, just again, just call it MTD ‑‑ legacy or whatever.
AUDIENCE SPEAKER: Jim Reid, a long time RIPE meeting participant. I did just want to make a couple of statements and it's obvious because I don't think we make these things often enough.
Menno, you and your colleagues do a fantastic job. Well done.
(Applause)
I'd also like to add one or two other comments to that. Again, we had the hackathon at the weekend before the RIPE meeting started and I am very, very grateful to you and your colleagues and everybody else from the NCC that helped to facilitate the hackathon and gave up your weekend to make that a reality, so thank you for that. You deserve to be acknowledged for it.
And also in terms of the infrastructure support, it's not just the technical team that do such a great job, we have got Martina and all of her colleagues with the rest of the meeting logistics, and also we have got the stenographers, we have got other colleagues from the NCC that help out with scribing and managing the chatrooms, and a lot of us just take that stuff for granted. There is a huge amount of hard work goes on behind the scenes and it's not always acknowledged, so again, my thanks to all of you for all you have done.
(Applause)
BRIAN NISBET: I think we are very lucky to have the meeting that we have and at lots of different levels.
RANDY BUSH: I just want to commend the engineering and ops design by covering 800 people, brilliant.
MENNO SCHEPERS: Thank you.
BRIAN NISBET: Thank you very much.
(Applause)
So, we have two lightning talks at the end of the PC organised Plenary, part of the Plenary session. So, Iljitsch, on AS paths, long, longer, longest.
ILIJTSCH VAN BEIJNUM: Hi everyone. Thanks for staying around. So, last month, I was at NLNOG meeting and someone mentioned they do AS path length filtering. I think they mentioned that they rejected all AS paths longer than 20 hops.
So I was a bit shocked by that because I know there are people that prepend their AS path to make them longer than 20 hops. So obviously, as we learned from Doug on Tuesday, you don't want to go overboard in prepending, and 20 hops is very long and, as we'll see soon, it's probably too long, but if these people don't know that they are going to be filtered, then they will have trouble, they will be unreachable for some parts of the Internet, but they don't know why. So I think that's a problem.
And I think we should probably think about fixing the problem by having some community guidelines on this, so both the people prepending and both the people filtering know where they should draw the line.
But first, let's see what's out there. I'll skip explaining my methodology and show you what I saw on route views.
So, these are the lengths of the AS paths. And there you see on the Y axis how many of them were on the route views, there is about 30 million paths total. So you see it starts with one or two hops, is very, very little, then you have the big spike at 4 or 5 and it trails off pretty quickly, but you see the blue one, which is the actual paths, goes all the way out to 45, the green one where I removed the prepending, it's much ‑‑ the long tail is much shorter.
So 45 is the longest. That's because it's prepended 40 times. The longest one that has no prepends, so I didn't remove prepend, but it doesn't have any, is 14 hops. The average, including prepend, is 4 and a half; with no prepends, it's 4. So, on average, it's half a hop that you get from prepending. But the interesting thing is, that almost all paths are no more than 20 HTTPS, and almost all paths are no more than 10 hops if you remove the prepends.
So, what is going on here? So apparently, this guy, way at the end, is trying to win the traffic engineering game from this guy, so maybe he is doing a bit more than he needs to do, right. So, how do you win at traffic engineering? So basically, if you are at 7 hops, you are already beyond the 98% of people who are 6 hops or less if you remove prepends and 90% if you keep the prepend. So basically, to reach 7 hops that's 5 prepends, so really after 5 prepends, you are not gaining ‑‑ really gaining much and you are still seeing too much traffic coming in on the prepended paths. You should probably look for another way to do this. I think Randy suggested one a few days ago.
So, that's what we see up there, and how useful it is what we see.
So my questions are:
Is this useful to come up with guidelines to make sure that people don't over‑prepend or over‑filter? So, let me know. What do you think?
AUDIENCE SPEAKER: Erik Bais: I think it's actually a good idea to actually have some guidelines on it. We, as an NLNOG community, we have had a BGP filter guide, filtering long AS paths is actually one of the things that we had some examples there for, and by the time I actually wrote that particular suggestion, it was like 40, 45 was actually what we saw in the DFC. We had the actual filter suggestion at 100, and the reason behind it was because there are actually devices on the Internet that if you go overboard and have really long AS path prepending, like 255 or more, it will actually break things. So that's why filtering in itself is good, but you need to have sensible, you know, measures.
AUDIENCE SPEAKER: A very quick question. Name and shame, please!
ILIJTSCH VAN BEIJNUM: Well, I imported all the stuff in SQL so I could do the query and show it to you right now, but then I would go over my ten minutes. So that will have to be off‑line.
AUDIENCE SPEAKER: Two quick qualifying questions. First of all, as all ASes paths after you remove private ASes ‑‑
ILIJTSCH VAN BEIJNUM: I didn't check for private ASes, but I have been looking at stuff, at AS paths and route views, for a long time, and I have seen many weird things but I have never seen a private AS. So I'm assuming that's not a big thing and certainly all the really long paths they didn't have private ASes.
AUDIENCE SPEAKER: Again, the second question. So is the data included in covering aggregate, so if you filter at X, right, how many prefixes will disappear because they don't have any other routes? That would be interesting to hear before you make recommendations on filtering paths.
ILIJTSCH VAN BEIJNUM: I'll get it out of the data and put it on the mailing list.
AUDIENCE SPEAKER: Well, having guidelines is a good idea, I am a little afraid that people that use heavy prepending are people who do not look for guidelines. They just took some courses or some formal training and they just do it because they think this is the best way to do it. And just to make sure they prepend it a lot.
ILIJTSCH VAN BEIJNUM: That's true. But once we have guidelines, then after some time has passed, hopefully these training courses, and so on, they will include this, so probably, over time, it will get better.
I have another question ‑‑
BRIAN NISBET: We have one minute.
ILIJTSCH VAN BEIJNUM: If we do this, do we want this, to make this a RIPE document or maybe an information RFC? Any opinions about that?
PETER HESSLER: I was going to answer your previous question. I think a RIPE document could be an initial step and maybe an informational RFC later on. But to answer your question, I do the traditional IXP and PNIs and get a better local pref than transit, than intransit prefixes and when I see at lot of hops or a lot of prepending on specific routes, then I will personally ‑‑ I will drop the local pref because they clearly don't want me to use it. I don't remove them; I just depreference them, so hopefully traffic is balanced the way they tell me they want it.
BRIAN NISBET: We're out of time. Sorry, we're out of time.
ILIJTSCH VAN BEIJNUM: I think Randy can do it in three seconds.
RANDY BUSH: Announce sub‑prefixes. Announce sub‑prefixes. Prepending is unnecessary and raises your vulnerability exposure.
BRIAN NISBET: Okay. Thank you very much.
(Applause)
And, yes, he could. So, as the last lightning talk, just to make sure you're all awake on a Friday afternoon ‑‑ morning, even ‑‑ Fernando Garcia. Those of you at Reykjavik will remember this, but are you up to the level of RIPE 79? So engage your brains and your web browsers, and let's play along.
FERNANDO GARCIA: Okay. Hello. If they tell you there were in essence in the RIPE meetings, they lied to you. And the second one, the database certification was a smoke bomb. This is the really thing.
So, I shall put in a little disclaimer, a real disclaimer. This is personal, my company doesn't even know I'm here, so please keep silent.
Second: In fact, this test doesn't show what you know or not. Well, perhaps.
And if there is a difference between reality and the test, the test is right.
So, no...
And that's why I said the important things. No, this is not one. Well, this is also such, but this test is IPv6‑free. And for technical reasons, we can only have 100 participants. This is the limit of ‑‑ for buying the licence, I hope to solve this if I do it in the future, so you may be quick.
And this time we have a prize. Last time, we didn't have a prize, now we have a prize, but it's not a /22 IPv4 public prefix. It's just a bottle of very good Spanish wine.
Of course, for technical reasons, that also goes to my business, by the way. For technical reason, the prize can be only to someone present. If one wins remotely, I am sorry.
Let's go.
And now, we go here... play...
Well... here we go!
So, as many of you know, you might connect to that page with your laptop, mobile, iPad and enter that number and name. We have two players, let's see, we reached the 100 limit. We have just one minute. Well, I will tell you some of the basics. We have, this time, ten questions, to avoid reaching the limit. And only for people only four people ‑‑ nobody want to play? Come on ‑‑ well, I was telling you there are 10 questions and I think the difficulty with that is that, with ten seconds, you can ‑‑ you can't check the answers in Google. So... ah, okay, that's good.
In 15 seconds, I will start again. So be quick, please, if you join.
Okay, I will start now.
Okay. Question 1. In which RFC can you read "With sufficient thrust, pigs can fly?"
Yes, RFC 1925 is the correct one.
Who are the winner, Becha. This is typical suspects.
Okay. I hope you have been attending all the presentations because this is related to some presentation that you have made.
Question 2. Geoff Huston told us that BGP is really old, but which one is older? Which protocol is older?
Oh, yes, it's not DNS. It's ICMP.
And cyber is leading.
Now for the DNS guys, here is a question:
What institution operates two root DNS servers? It's VeriSign. That's right.
Okay. This screen is really colourful, so let's go for some colour.
Question 4. Where are colours not used? Okay, OSPF areas is the answer.
We must run, if you know about IP protocols, the next question "What is protocol IS 16?"
Answer: Chaos.
And this week we have speak many times about Jon Postel, so this is important, it was a great loss.
"Which one was the first RFC in which Jon Postel participated?"
Answer: Yes, 45. By the way, it was called new protocol is coming. He wasn't speaking about, not IPv4, it was all one. New protocols have come in all the way.
And there is a grandfather of the Internet, that is ‑‑ he is working now in Google. But Clement is now winning.
"... is one of the grandfathers of the Internet. How many 1st April RFCs has he written?"
He wrote three RFCs.
Next question: And you must be ‑‑ I hope you were here first day and you were very attentive because you must remember "In single mode optics why we use 1310 NM?"
"
Answer: Yes, minimum dispersion.
Some people thought it was minimum saturation, but that is 1515.
We are reaching the end, just two more questions.
And this is another DNS question.
"Which one of these doesn't have a country code TLD?"
Answer: Alaska.
And let's see, Clement is still winning. Last but not least, this is for the old people, like me.
Question: "TCP is defined in RFC 675, but where is IP originally defined?"
Answer: In IEEE trust anchors on communications. Number 5, May 1974.
And the winner is Clement. Is Clement here?
(Applause)
BRIAN NISBET: With that, and thank you very much for the quiz and waking us all up. The PC ‑‑ hand over the Plenary back to the RIPE Chair. Thank you very much.
HANS PETTER HOLEN: Thank you very much, Brian.
So, the meeting has come to an end again. Somebody said "this morning", but it's now after twelve o'clock, so it's not morning any more, so nobody is tired, everybody is ready for yet another week? No.
We have had 736 attendees here, and that's not a record, but it's a pretty good number anyway. A quarter of you are newcomers, that's great. And the distribution between the different types, I mean I looked back ten meetings ago, and it looks pretty much the same. There isn't that much difference here.
Of course, it's always interesting to see which country is the biggest one in the RIPE service region. I know both the Netherlands and Germany are bigger than the US, so that's a good progress here.
It's also interesting to see that Romania comes up because there are quite a few from my company that's joining me here now so I guess I'm making my contribution to that.
A big thanks goes to the Working Group Chairs, because they work between the meetings, our thanks to our Chairs doing an effort with their Working Group to make that happen. And as you can see from this slide, there is one of the Working Groups, the Routing Working Group, that only had one Working Group Chair, because the other co‑chair stepped down at the last meeting. So, at this meeting, they selected two new co‑chairs, so Job and Paul. So, thank you very much for volunteering to work for the community.
We also have an excellent Programme Committee, as you can see here, and I think they deserve great applause for the work that they have done so far.
(Applause)
You are getting the hang of it now, taking the cue on when to clap. I like that. Then, there has been a PC election, and here are the two winners of the that election. So we're looking forward to their contribution.
(Applause)
We also have representatives on the NRO NC and there was an election for the next three years, and Filiz has won that election. So, congratulations, Filiz.
(Applause)
We have been working on diversity, the Diversity Task Force has been behind the childcare, with eight children, mentoring 24 peers this time, that's really great, and they have published a Code of Conduct version 3.0. And I would urge you all to go home and read that and think about it and, if you have concerns with it, don't tell us that "I don't like this"; tell us what can be done to improve this. I mean, this is what consensus in the engineering community or in the RIPE community is all about. It's raising the issues and finding good solutions to the issues. And I think that's where I would really ask you all to contribute, and don't wait too long, because I would really be eager to get this in a shape so that we can get on with creating a good community and be inclusive, and not have to discuss the sort of the basic foundation of being nice to each other. That would be my plea to you on the way home or over the next few weeks, put in an effort that we now have something on the table that the task force has been working on this, thinks it's good, but there may be room for improvement, let's sort those out so that we can move ahead.
We have established a database task force charter and timeline has been published. And I'm really looking forward to seeing the sort of a bit out‑of‑the‑box thinking on a high level, where do we want to take the database into the next 10 to 20 to 50 years moving ahead, because times are changing, requirements are changing and this is going to be really important work. They are not going to make decisions, they are going to present documents for the community to review and discuss.
RIPE Chair selection process. If you are now fed up with me, you have your chance here. You can put your name forward to get on the NOMCOM. Daniel, as Chair of the NOMCOM appointed by the RIPE NCC Executive Board, wants 100 volunteers so that the random number generator that will pick a random number, not a random number but ten random persons to serve on the NOMCOM. That's kind of what we're aiming for here, and looking forward to see that. There will also be a call for volunteers for chair and co‑chair. I may put my name forward, so you may have the chance to have me here for another period of time, but I really would like to see a good co‑chair at my side moving ahead in the case that the NOMCOM wants me to serve further on.
Community Plenary:
That's something that we used to have because the RIPE meeting ended in a Plenary and the Working Groups presented their work, and we could discuss matters that didn't fit in any of the Working Groups. We have kind of lost that for some years now, but now we brought it back last evening, and we had discussions on the Chair selection process or a presentation on the status there, the presentation of the establishment of the Database Requirements Task Force, and a quite lively discussion on the Code of Conduct, and I think you ‑‑ thank you all for the engagement in the community here, that's really important. And we started the conversation on the RIPE next generation PDP, or it's is the PDP fit‑for‑purpose, as some of our friends in governments tend to put it, and is it their purpose or our purpose or is there any difference? I think that's something we should work upon, and I'll review the notes from the Plenary and probably come up with a proposal to establish a task force to look at that moving ahead as well.
Also, the findings from the accountability task force that we had is something that I presented there and want to put on a sort of a work list so that we can pick from that, moving forward, and address all those issues that had been raised.
And there will also be minutes from this session so that that can be recorded for the future and moving forward.
So, Axel, are you here? You are. So, last night, Christian held a speech to you, and he made the comment that he was missing all the pictures from the history of...
Fortunately, I didn't have my complete picture library with me so I was not able to go back to our first meeting, which I believe was in California, I met you and Rob at an ICANN meeting and we did quite some sightseeing as part ‑‑ as being on one of our very first ICANN meetings and learning what these strange people involved in names were doing.
So, I found a nice picture of you prepending on one of the many places that we have been been together. It's almost like I could say that we have travelled the world together. It's not that excessively as it sounds, but thanks for all the good discussions we have had, all the times that we spent together. And it's kind of one thing, one quote that I will remember from Axel, and I'm not sure I got the words exactly right, but the thinking there is, yes, of course we will do that if the community wants us to do that. And that's been kind of his attitude as the managing director of the RIPE NCC, that he is here to serve the community, and I think that's really what the RIPE NCC is all about. And it's all ‑‑ it's what Axel's leadership has been all about.
So I don't have any champagne with me today, but a virtual toast to Axel.
(Applause)
I was waiting for the timer to start to blink red, but it didn't.
So you told us you would leave but you wouldn't go away so I thought this picture would be an appropriate end to that.
Prizes. That's why you are still here, right.
First newcomer registration.
First timer, and then the trouble with this service region is being able to pronounce names from non‑Norwegian countries. Rayhaan Jaufeerally, You can come up and get your prize.
And then the second price goes to somebody from the Netherlands, the first registration from the Netherlands, Paul Hoogsteder.
It seems that people are more interested in pictures with me than the prize!
Okay. And starting to think a bit about the environment. I mean, we're travelling around the world but we can do a small contribution in returning the badges and making sure that they are recycled and that the lanyard can be used again the next time. And there is an incentive for doing that. If you call take out your badges, you have got the badge ‑‑ and you look on the last page, well not the last page, but the second last page and it says do you want to win a week, a ticket to go to RIPE 80? You can fill in there and when you hand it in you can win a ticket to the next RIPE meeting. Cool!
But then you need to remember to hand it in.
We do want your feedback. You have seen this URL. Thanks to our sponsors.
(Applause)
And see you all in Germany in Berlin.
(Applause)
And that was not quite the end of the meeting...
HANS PETTER HOLEN: So thank you everybody. That's officially the end of the meeting. Safe travels home and see you all in Berlin.
