Connect Working Group
Wednesday, 16 May 2018
11 a.m.
REMCO VAN MOOK: All right. If everyone can go find their seats, there is plenty of seats in the front, people. Good morning everyone, welcome to your favourite day of the RIPE week and your second most favourite Working Group of the RIPE meeting, the fabled Connect Working Group. Welcome to Marseille. We have a packed agenda today, so hang on to your seats and we'll get started, I guess. I am here of course as always, I am here with my co‑chair Florence, who is sitting in the front wearing red. So, what do we have on the agenda for today?
This is the agenda. So, welcome. Scribe appointment. So, let's see, who am I going to volunteer for this? Marco is busy at his lab to be, so I am going to make her scribe. Thank you for that. We have got an update on the Working Group Chair selection process. We have got presentations from NLix, from? ..?? ...Arnold Dynamics, by Marco, connect updates that we started a couple of meetings ago by Florence, and then we're going to ask you for some feedback, by that time it's lunch.
Any feedback on this so far? So let's get started with the Working Group Chair selection process.
So, during a previous RIPE meeting we realised that Florence and I had already served up or three‑year term as chairs of this lovely collective. So, it was time to run the Chair selection process. This is the shamelessly stolen process from the Cooperation Working Group that we adopted. And this is what I said last time. We'll do a call for interested parties. We'll announce a list of candidates and then declare a decision based on feedback. And no feedback means that Florence and I get to decide whatever the hell we want. So this is the timeline, October 25, call for nominations. The call for nominations went out. And this is what happened.
You wanted feedback, you're too late. Sorry!
So what did happen is after the deadline expired, well, you remember that one? We can decide whatever the hell we want. That's good, right. We're going to be friendly about it. So, we had one late entry, one expression of interest to not necessarily replace Florence or me, but, well join the collective as a Working Group Chair. That was Will Van Gulick, and given his capabilities of handling a microphone, I think what we would ask the Working Group is to approve that we're going to add Will to our co‑chair collective after this meeting. Anyone any objections, suggestions... go... go... ‑‑ oh there is somebody running ‑‑ running out, okay. That must have been the food. That's fine.
So, welcome Will, congratulations.
(Applause)
Right. So, that was relatively painless. Now onto the next agenda item. Which is... Gerry, come on down Gerry.
JERRY GRONDEL: Thank you Remco. None of you know me actually, I have been not been in the business very long. Don't worry, I am not going to pretend I know as much of stuff as you do. I proclaim myself Tor a non‑technical professional, it's so bad that a couple of years ago somebody enabled IPv6 on my residential home line and I didn't notice. Which was a good thing at the moment. . I won't bore you with a lot of marketing. But I have to give you some insights on NLix, I have to give you this because that puts the rest of my story into the perspective. NLix was established a while ago. We are most known for running an internet exchange but on that same MPLS backbone we run transit, transport services. We are spread out over 14 countries, 24 met rows now and 115 data centres. So that gives a lot of questions from customers, participants and members.
We have ‑‑ we run about 2 gigs of traffic and we have 647, I think the counts are a bit different today, as that usually goes, connected networks. . So much for the marketing bit and the logos.
I want to talk about IXs and what the questions are that we get from potential participants and current participants. And for that we need to go back to the different models in the market that you see on IXs. I'm not going to tell you which one is better or not. But this is roughly the two situations that you see.
On the left, that's the more traditional IX model. Usually focussed on one metro area, you know all the big names. They have a couple of very big switches on a cluster of data centres very close to each other, and people tend to connect either locally or remotely. So, the customer, the participants come to the exchange. The other model that you'll see in the market and we're not the only one doing this, I'd like to say that as well, is the distributed exchange where the basically you don't ask the participants to come to you, but we come to the participant or the member.
But you also see that the transport that was on the left done by the customer, or the end user, is not done on the backbone of the Internet Exchange in members being away in over 40 milliseconds round tip delay, and that gives questions. Because what happens then. And why would I do that? And for some participants and some members, it's crucial to have very low round trip delays. Others don't really care because they use the Internet Exchange as an alternative for transit.
The discussions that we have on round trip delay on our backbone are in essence the same as the more metro focussed exchanges have on remote peering, how do you know what member is how far away? In our case, it's pretty obvious. Our member states where somebody is located and we'll‑ come back to you what that actually results to. And on our metro exchanges, people tend to ping the other members to see what's happening but then you don't know where the router is of the other members. So, what does that result in and how does that affect? The other question we get is the impact of outages, they are all very nice, you have such a big backbone, we have 3, 400 interconnects between all the POPs, what happens if something becomes unavailable?
So what we started to do is gather the facts. We have installed 24 Accedian performance elements that measure a round trip delay every five minutes, we have two types installed for the very simple reason that the top one has copper interfaces and the lower one has fibre interfaced and it's just what we had available on those different locations. We also measure packet loss and jitter but for the moment we're focussing on round trip delays and what we do with that, we visualise these measurements on the website. Not just the ideal situation, but we give you the live situation. So if you go to the home page now, you'll actually see what the current round trip delays are, including any outages that we may have.
Based on the round trip delays that we have measured, we also give you the opportunity to select your peers. You can do that twofold. Of course you have got on the right, the more original way, the standard way you select from a member list currently available on the website per metro area per city better data centre. And the other way is that we facilitate ‑‑ and it's actually not as clear as I was hoping it would be ‑‑ we facilitate a gooey, and interface, where you have on the the left top slide, a slider where you can set that to whatever you want, you are located in metro A and you only want to peer with members that are, say, 20 milliseconds away from you. And than that system automatically reduces the amount of peers that you would be able to reach offer the exchange.
So that's the route server and that's the manual bit.
And it looks like that. Very nice.
The interesting bit is, and then what about outages? The traditional way of showing any outages is just give a list on your website saying this is what's going on. With 115 POPs and over 300 lines, transport lines here, it gets rather confusing because you never know what actually impacts your situation.
These screen shots were taken about a second apart from each other. This was an actual outage on a link between Luxembourg and Antwerp. If you go ‑‑ if you look from Hamburg you would not see any impact on any round trip delays that we'd have on the network. If you'd be looking from the Luxembourg point of view, you see that there is a lot of impact because most of the traffic would be flowing over that very link between Luxembourg and Antwerp. So this is how we now, live, show you live what the actual situation is, and that's done now on the website, I think there is something going on in France at the moment, I don't really know what, I couldn't get the colleagues on the phone, it wasn't a big impact but that's something fishy. But we're very transparent about it, we're very clear.
What are we going to do with that? The current filters on the route server are based on static input so we know the ideal situation or the measured situation on the round trip delays, but why not put in the live situation, because if you don't want to peer with anyone over 20 milliseconds you probably want that in a real situation and not the ideal situation. That is doable, but we're not sure what short of threshold we put in because that also gives you a lot of varying BGP tables. We're investigating and if you have any ideas on that, please let us know even if you city it's a bad idea, that's also good feedback. But that's one of the developments we're working on.
And the other one is what we call a capacity API. We have actually quite a few members that have limited capacity on the exchange. But they want to use the exchange as an overflow for transit connections that they have. So, what we have been developing, together with a rather large content provider, is a capacity API where our members are able to set a limit on the amount of traffic that they would be willing to receive, based on a couple of variables, and that API can then be read. And it works in practice, we have got a test situation and it works, and you might have seen it in the screen shot before. It's already listed in the demo situation on the website. I could show you that if you'd like.
So this is what we have been working on. It's different from what most people do, but we have a different situation on our network and we get different feedback from what metro IXPs can do.
Any questions so far? Very quiet. Any questions from abroad? No. Good. Then I think I'll wrap it up because we have got a very busy schedule here. Remco, can I hand it back to you.
REMCO VAN MOOK: Now it's my turn. Any final thoughts or questions or feedback for Gerry? I'm very surprised. No one? Good. Okay. Thank you very much Gerry.
(Applause)
Now, next up is Andrei about MANRS, not table manners, other MANRS, but he is going to talk all about that. So I'll leave that to him. Here you go Andrei.
ANDREI ROBACHEVSKY: Hi everyone, for a couple of years, part of my job was supporting community initiative called MANRS. And this is a short update what's happening in MANRS in more importantly which I think is interesting for this Working Group, a new programme that was just recently launched, the MANRS IXP programme.
So MANRS, a quick recap. I was talking with some people and explaining that there is some misconception that MANRS is a sort of a best practice. Now first of all, MANRS is not best practices, and secondly, that's not only practices. It actually sets for actions as a minimum baseline that any operator should adhere to and it builds a community, because we want to promote this baseline to a norm and in this respect, community is very important.
So, four actions, pretty simple. They are very limited in scope. So minimise cost and risk of implementing this, they talk about filtering, anti‑spoofing, coordination and facilitating global validation which means populating datasets, like IRR, RPKI, so third‑party can validate if they want. It was started by network operators and the actions as you see applicable to network operators mostly. There are other players, and specifically Internet Exchange points that can have significant impact and have significant impact on router security. So sometime ago, the MANRS members were thinking, can we open MANRS for other players like IXPs. Now, that's great, but in this spirit of MANRS, in order to join you can't just say I care about routing security, I think that's a good thing, and I will do whatever I can to support that. You really need to demonstrate your commitment by implementing certain things.
And certain things in regional MANRS is the action. So, that's why we went off and started developing the action. But before, and that was probably two years ago, we came to ‑‑ well I came to EURO‑IX with this idea and the first question was course: Well, it might be useful for MANRS but what's in MANRS for the IXP? And what we discussed, now in general I think we got positive feedback that MANRS, it gives an IXP an opportunity to build a safe neighbourhood. It provides a global, reliable researches. And I think that's also very important because we know there are multiple efforts to improve routing security, but they all sort of not consistent and not coherent. So having one single anchor, researches point I think amplifies and helps coherence of these efforts.
And of course, the experience of local communities, because IXPs, they have local communities with common operation objective, which is very important. And those communities and their experience in how issues of routing security can be addressed. This experience fed back to the MANRS initiative is very important.
So, a small development team was formed with some IXPs that expressed their interest in participating was formed. And we went off to develop a set of actions.
After sometime, a set of seven I think, actions was developed, just to cover a wide area how IXPs can contribute to routing security.
And of course, the first one was many IXPs run route server, and that's a great facility where you can implement certain controls to prevent propagation of incorrect routing information in peering relationships. Of course, IXPs can facilitate global operation and communication and operations importantly, and that was one of the purposes of the programme, is that IXPs can promote MANRS and those norms in their operational communities.
There were ideas how IXPs can assist in preventing unwanted traffic or even mitigating DDOS attacks. Monitoring debugging tools was
contentious, there were also ideas if IXPs are willing to prefer local auditing of their MANRS members the many IXPs they have a certain rules on accepting unbolding their members and we thought maybe MANRS can sort of, you know, piggy back on that process, and some auditing can be done. Now, what I'm showing you is not the final action set, I will show that shortly, but this is sort of the field of thinking at the time.
So, we went off, got some feedback, and this is the feedback NIX community whether those actions were easy to implement, easy, difficult or not useful. EURO‑IX is a big community. But there are others, so we went off and did sort of a route show through other IXP communities in Latin America, Africa, Asia Pacific and north American. This graph summarises certain feedback on whether people can see certain actions are useful and relatively easy to implement, or not useful or very difficult to implement.
So based on this feedback summarising that a final set of actions was developed and the programme was launched last month, a few weeks ago, on the 23rd April, a week after the EURO‑IX was sort of a soft launch where I also presented this programme.
So, right now we have 12 IXPs participating in this programme, all good names are there. Some big IXPs are there as well. So, this is similar to MANRS ISP list but you see there is extended list of actions for IXPs, and again there is legibility criteria don't need to meet all the or implement all the actions, I'll talk about this later.
Let me quickly go through the actions. So the first one, that's a very important one, that was felt very important by the development team and by the initial participants, that the first action is facilitating prevention of propagation of incorrect routing information. And people actually demand that had this is a very strict action that filtering is strictly to be performed on the route server, which means announcements that are incorrect, they are not propagated further to participating members.
And information is fed from an IRR or RPKI, this is again as the original MANRS, we're not talking about technology used, we're looking at the outcome.
Action 2, which is also mandatory, because that's also part of the objective of the IXP programme is to promote MANRS in the communities. It was split in different ways how an IXP can promote MANRS. And it starts with sort of relatively easy ways, i.e. in assisting their members in implementing actually filtering on the route server and sort of raising the bar for this ending up at providing some incentives linked to MANRS readiness, that might be symbolic cost reductions or some other up sin incentives that IXP can think of.
Action 3, protect the peering platform. That's not really routing, but I think that impacts general resilience of the platform, so that was not contentious, and there are many IXPs do that.
Action 42 it's to facilitate global cooperation and it's pretty simple, it boils down that they have mailing list, you facilitate this communication between your members and the IXP itself.
And the finally provide monitoring and debugging tool and the main tool was Looking Glass, which was non contentious. Legibility criteria, you have to implement action 1 and 2 and other action to say get majority of actions implemented. And please, the IXPs in this room, go to the MANRS website and join.
Now, just one last thing. Why is that important? Why are we doing this? Why we need those norms? Well the thing is routing security is that your network security depends on actions of other networks, and that's the problem, because by implementing those actions, you are not really securing your network. You actually want those actions to be implemented by other networks. So this is the sense of reciprocity that, sort of, can be underpinned by community building, that's why IXPs and other operators play very important role, that's a collective problem that needs to be solved collectively, and that's sort of the root and the origin of MANRS.
If you want to learn more, there are two things, there is a document for IXPs and there is also a joining form, please fill it out if you are interested with as much detail as possible. Hopefully with references to public documentation and join.
Thank you.
(Applause)
FLORENCE LAVROFF: Thank you for the presentation Andrei. Do we have some questions?
NURANI NIMPUNO: Thank you Andrei, and I just wanted to say, I think MANRS is a really good initiative, and I think by creating MANRS for IXPs, you have also sort of completed the picture. Security is a shared responsibility and we all need to play our part and I think IXPs are in a unique position to lead by example, because they are often at the centre of a community. And I know it's hard to get ‑‑ I know that there is a lot of work that went into trying to get all these pieces right, and I think you have done a great job and I'd like to encourage everyone to support MANRS, to join and to promote it. Thanks.
ANDREI ROBACHEVSKY: Thank you very much. And well two things. You are absolutely right it closes the loop if you have look at the original MANRS, it addresses the customer provider relationship, and IXPs, if you look at action 1, it actually closes the loop on peering relationship, which makes the whole system much more robust. And the second point I would like to stress is that it's really, we would like this ownership to transfer to the community. ISOC is supporting this initiative very much, but I think community needs to chip in and drive this effort further.
AUDIENCE SPEAKER: Andreas, from the Greek internet exchange. I cannot comment right now, but I expect the Internet Exchange will join MANRS pretty soon. Apart from that I believe that we will also willing to give some incentives to our members in order to join MANRS themselves. And when I say incentives, I mean obviously some sort of discount in our price list.
There is one small feature request that I would like to ask, in order to be able to check that our members are actually have have been audited for MANRS and they still have the ‑‑ they have not lost the property, we will need to implement some sort of functionality to query some API or some, etc. It would be easier for us if this would work in aest push model rather than a pull model. It would be easier for us if you could let us know when one of our members joined or left MANRS. Is this something that it would be possible that you would implement?
ANDREI ROBACHEVSKY: So, we are working on the website redesign and there was already a request to get the sort of participant members in a more readable form, like a Jason restful API and we can discuss that E yeah, let's discuss this feature.
AUDIENCE SPEAKER: Okay. Thank you.
ANDREI ROBACHEVSKY: Just another thing. Tomorrow I'm presenting some ideas on how we can measure and maybe expose publicly sort of readiness level of different networks with regard to MANRS, I have short slides and it's really short announcements at the Routing Working Group and MAT Working Group, so if you are interested, please come.
AUDIENCE SPEAKER: Remco van Mook. I saw in one of your slides when you were connecting feedback from IXs that one of the most contentious parts was routing filtering, and what I understood from the graph that you showed is that the most resistance you were getting for implementing MANRS for IXPs is actually the implementing of route filtering. Is that an inaccurate observation or what happened there? Because I'm really curious.
ANDREI ROBACHEVSKY: It wasn't contentious. The most contentious action was a mitigation of DNL service attacks by implementing remotely triggered blackholing on the route server. Because we couldn't RIS consensus this action disappeared from the final lest. On the action on filtering of routing announcements on the route server, initial action was a bit loose. It allowed filtering or tagging of incorrect routes, so you can propagate and you can sort of have a dry run of this action. But there was a strong push back on that from MANRS members and from the sort of initial participants that we need to make it more clear and more strict, and that's where we went.
REMCO VAN MOOK: Thank you.
FLORENCE LAVROFF: Okay. I can't see we have other questioned regarding this presentation. So I would just propose we jump to the next topic.
And the next topic is a presentation from Bijal from EURO‑IX about IX PD B.
BIJAL SHANGHANI: Hello. I am Bijal from EURO‑IX, and today I am going to talk about the IXP database.
First of all, a very quick summary of what EURO‑IX is for those that don't know. We're an association for IXPs, we currently have 78 members, 54 of those are based in Europe, 24 from the rest of the world.
We had a newest members are digital reality stakes, SA IX and C R IX.
We also have a number of patrons. And patrons are quite an important part of EURO‑IX because they support the IXPs in various different ways. So you'll see a number of vendors and data centres on here, and these are the people that the IXPs have relationships with.
So, what else do we do? We have 2 meeting a year. We just had our 32nd forum, which was hosted in by INEX in Galway. We had around 110 attendees, 42 IXPs present. Our next forum will be in Venice hosted by NAMEX, TOPIX and VSIX, so if you are interested in coming along to that, please come and see me.
We have a website and a database which I'm going to talk about later. There is a lot of other kind of activities that we do. We have ‑‑ obviously we're an association for IXPs, so one of the main things that we want to do is support and encourage IXPs to do the right thing. So we have a fellowship programme and the way that that works is that an IXP who would like to attend a EURO‑IX forum can apply for a fellowship and they can come along. We really, really encourage IXPs from the EURO‑IX region especially to, if they don't have the funds to attend, to get in touch with us and we'll see what we can do to get you to a meeting.
The feedback we get from meetings from the people that attend the forums for the first time is really, really positive, and you know they find that it helps them and makes them go back and question the way that they do things and see what other challenges are being face bid other IXs.
The mentor IX programme is similar, in that it also supports IXPs. So we have if you like, an existing IXP who can help out an IXP in need. And this can also again be, you know, anything from technical support to commercial support to even regulatory support. So whatever is needed.
We have mailing lists. We do a number of reports. We have a benchmarking report. We have a traffic report. Hardware and route server report. All of these reports are public apart from the benchmarking. The benchmarking is only ‑‑ as well is not only just for the members because it's only for IXs that take part. In the actual survey.
We have a newsletter, so if you are interested in hearing about what IXPs are doing, or if you have any news about IXPs that you would like to share with the community, then again please get in touch.
We hold a number of ‑‑ well we started to hold a number of workshops and one of the ones we had last year was actually on route servers. Once the RFC for the large BGP communities came out, the IXs who were at the workshop thought that it would be a good idea to put together a, if you like, a standard list of communities that would be used IXPs on their route servers. So, we have done some work there. All the information is in that URL, if you want to go and have a look at those. What this means is that for IXPs who want to use it, you don't have to do all this work that's already been done. And for networks that support communities, it means that you have a standard community list at IXPs which of course makes things a lot easier.
We are also on social media, so you can follow us on Twitter, like us on Facebook, and watch our videos on YouTube.
So, now I'm going to talk about the IXP database. The IXP database is an IXF project. I'm going to run through what the Internet Exchange federation is.
So, in 2012, we found that the different IXP As, so at the time it was AP‑IX, EURO‑IX and LAC‑IX felt that there was a lot of things that we could do together and that there were a lot of challenges and issues that were raised within the different regions, and that each region could benefit from sharing ideas and experiences with each other.
So, the IXF was born. The ME U was signed in 2012 with these and then in 2014 F IX joined. Collectively, we reply over 105 ‑‑ 145 IXPs across the six continents. So that's the number of members we have.
So, like I said, the MoU was signed in 2012 and then in 2014. The main objectives and these are the top three objectives, there are others as well, but the top three objectives. I think one of the main reasons that we decided to come together as well was that there was an increasing interest from governments, regulators and policy makers about Internet Exchange points. They wanted to know what's going on, or they wanted to come in and start either doing some regulation or policy within the IXs, so we felt that it was necessary for us, as the IXF to come together and sort of represent each other in a global way.
The other objective is to facilitate interaction between IXPs to address shared challenges and goals. Like I said, there is a lot of shared challenges and goals around the world, you know having been just to the LAC‑IX meeting, it was quite interesting to see the similarities happening in Africa and also in South America.
And finally, it's so provide a central resource for IXP related data research and BCPs.
So this leads me nicely on to the IXP database.
So a little bit of history for those of you that are not aware of how this actually happened. The IXP database is new only by name. And I say that because I'm sure some you old timers remember Serge coming up here and talking about the number of ASNs in Europe and around the world and looking at traffic graphs going up and to the right. So, that data that was pulled up back in ‑‑ well after 2001, was from what was then called the EURO‑IX database.
With the formation of the IXF it didn't make sense that each of the IXP As had its own database and this nearly happened, you know, they could have potentially been a separate IXP database in Africa and in South America.
IXPs had no control over their data and peering DB and to some extent still don't. So, the IXF had some talks with peering DB and then were committed to building the IXP database. In 2014, there was a hackathon in Sheffield, together with peering DB to work on both databases.
The initial development for the IXP database was contracted out to 20 C who are the developers for peering DB. Although now we have contracted the work to nix.cz.
So how does it work? The scheme is an agreed standard, it's a scheme which allows IXPs to make their member list and other data available. Now if you want to have a look at the schema you can go to that URL, you'll see there is quite a lot of data in there about IXPs and data that's not available in other places.
It allows the individual IXP to be the source. Where the data is coming from you are actually getting the data from the IXP which is the source.
The IXPs publish this data either publicly, they can send private APIs to us, and via other systems like IXP manager, and we love IXP manager.
The the IXP database will publish a single API, so those that want to use it will do that with all the information in there. Just to show how the committed is IXF is working on this project is that each of the IXP As are holding workshops in their own region. So we had one during the APRICOT meeting, we had one during the LAC‑IX meeting, we always do something automated related at EURO‑IX and there is going to be one in Africa as well.
So the exciting news is that by the end of June, we will have 110 exports working in the IXP database. So that means 110 IXPs will be directly sending their data to the IXP database.
Where are we? The database is live. We're ready to start doing integration work with other databases.
IXPs have a lot more control because it's the IXP database so they can actually decide what kind of exposure levels they want. So, for example, some IXPs are quite sensitive to certain information being public. So that information could be within the IXP database available for other IXPs but just not available publicly.
And also, all the IXPs can create new IXPs in the database and so can other admins.
We also have a last updated field which is also be in the API. So if you are doing some filtering and you want to see the latest updates. You can use that.
Aggregated vendor data at IXPs is already available.
What's coming? Aggregated data on vendors connected to IXP, so this is the IXP participants. And aggregated traffic data is coming soon. And also, geolocation and maps.
So, here is a quick summary of how to get all that good information I have just told you. The website is there. I am warning you if you are going to go there now it is a work in progress. Please keep an eye on it and I'm sure we'll hear somehow that the new website is completely ready and so is the database. We do have a mailing list for users. So if you feel you want to use the database during the mailing list and you can get support on there. The API is available and live. You can get that there. And finally, if you think this is good work, like we do, then fundus, and you can contact us on secretariat on IX F.net.
Finally, we have a video, so if, like some of your families, they wonder what you do when you are travelling around building the Internet, this is a quick five minute video available in many languages now on how the Internet works. So, take a look at that and share it with your friends and family. And if you see your language not there and you would like to translate the video, then please come and see me.
And that's it. Thank you. Are there any questions?
FLORENCE LAVROFF: Questions for Bijal? Okay, thank you Bijal.
(Applause)
And the next item on our agenda is an update from Arnold Nipper about peering DB.
ARNOLD NIPPER: Hello, I am Arnold Nipper from peering DB, I just need the first page of my presentation. I will start because I only need the first slide which says it's an IXP update. Not IXP update. Peering DB update.
So, this is only the first slide. Then we have to look at that and then you can look back at your laptops and do other works and just listen to me.
So what I want to talk about is about the organisation, so what happened at peering DB first of all we had elections, we have elections every year, and swap out half of the board. So congratulations to Aaron and to/KWROJob who were re‑elected and Aaron will be president again and Job is vice‑president.
We also had our annual meeting, which is an online meeting, then a couple of weeks ago already we had strategic board meeting covering our strategy for this year and for next year, I will talk about that a little bit later.
So, financially, peering DB, as you might know, is 100% covered by sponsorship, we are stable and we try to also make reserves for two years exactly. The money we need currently, the budget for this year is roughly 100,000, and for 2019 the basic budget will be roughly 40 to 50k and that depends on what you are requesting to be implemented.
Otherwise, on the organisation, we thought it's time to have a new committee. You know that we already have the admin committee who is taking care of the day‑to‑day work, the Programme Committee which drives the development of peering DB. Then we have the opes committee who is taking care of the infrastructure and we now have the new committee, which is the outage committee, chaired by Bijal and co‑chaired by Aaron, who will look more into developing tutorials and workshops and to be more prepared to present at events, especially tutorials and workshops.
So, for operations, what we would like to do for this year and next year. To maintain SLAs and contracts for each services we provide, and to write an operational service level policy and report compliance to this policy for each services as well.
What we also would like to do, to be more transparent, is to document our operational infrastructure, and last but not least, everyone who is dealing with personal data, private data, is that we still have to cope with DD PR.
So coming to the product platform, what we do is we have monthly release, we did a release this morning. We are now running at 2.N.4, which was a security update to mention this, the next great product release which we will have really confirms to internationalisation, currently peering DB is only available in English, what we implemented is to have language packs and the first language and the highest demand for this language is in Portuguese and Brazilian, and this work was heavily done by NTT and PT T Brazil. In the background, what we also are doing is cleaning up the DB and this is a work of the admin committee, and the admin committee has to deal with roughly 800 tickets meanwhile per month.
As of cooperations, there is only one DB dealing with IXPs, Bijal mentioned it, it's the IXP DB, the SP C H, which are in the business since even longer, and what we try to do is to cooperate with all of them and especially regarding IXPs is to create a directory so that we have a common understanding which IXP we are talking about.
Then we would like to strengthen the relationship with the RIRs because for the network parts, we are importing the data from the RIRs.
And of course also develop, I mentioned it, the workshops and tutorials for the UNs.
And this was my update for peering DB. I am happy to take any suggestions or questions. The presentation will be there, so I have, even the long deck, and you may reed through it and find even more useful information in it.
RUDIGER VOLK: My name is vaccen from Deutsche Telekom, sorry we are not a sponsor.
ARNOLD NIPPER: Not yet.
AUDIENCE SPEAKER: I just looked up to it is, so a lot of sponsors go on the support page. There are many newcomers here and please update your records on peering DB, it's frustrating if you don't do it. I hope we are done it.
ARNOLD NIPPER: Networks your IP addresses I am missing.
AUDIENCE SPEAKER: And a big thank you and clap of hands for those who do this work. Thank you.
FLORENCE LAVROFF: Any other question anybody? I can see someone coming to the mic. No, okay, never mind. On that, thanks. That's it.
And now we are going to have a presentation from Marco about dine IX. L
MARCO CHIESA: So, thank you. And good morning to everyone. Thanks to the RIPE who raised the initiative for inviting us to present our project here and have the opportunity to collect valuable feedback from the networking operators.
So, if we look at the level of physical interconnectivity that we see today in the Internet, this is absolutely phenomenal and this is a great achievement of the networking community. So if you as a network operator today connect to the Internet Exchange point, then you immediately gain access, physical connectivity, to many hundreds of different networks that exchange traffic for hundreds of thousands of IP prefixes, yet if a network wants to leverage this high and reach path diversity it has to first discover who is offering what type of services and then agree to exchange traffic with these entities.
So unlike many aspects of the Internet, which are regulated by standardized protocols, established inter‑connection agreements today is mostly a human based and longer process, which we can describe in four different phases.
So the first phase: Finding a partner. This includes two different aspects. First, identifying who is offering what type of services, and typically operators can access databases that contain this information or attend face‑to‑face meeting and find out potential entities to which they can engage in business. Another important aspect is trust. Can I just an entity to engage in business? And this often boils down to reputation of these entities and the way this information is collected is through personal relationship, word of mouth or brand Rick initial.
So the second phase is discussion of properties for agreements such as technical information service level agreements and the business information. What is the price for the agreements.
Potentially this information is formalised, written down and then agreement is made, or eventually just a handshake happens.
Ultimately, the output of this last phase is given as input to a network operator that has to translate these formalised properties of an agreement into a real network device configuration. So we argue that an excessively long interconnection process can result in a substantial friction in the establish. Of Internet agreements which ultimately may result in miss inter‑connection opportunities, inefficient use of port capacities, and an optimised traffic delivery in the face of sudden changes in the traffic demands.
So in order to get a better picture of how long it takes for a network operator to establish an agreement, we circulated a survey to over 100 operators and we are thankful to all of those that answered this survey, and we tried to understand how long it takes to establish an agreement. And we asked exactly how long it takes for each of these phases.
So finding a partner, it takes hours or days.
Discussing properties, days or weeks.
Formalising the terms, days or weeks.
And finally, deploying the agreement, hours or days.
So we also asked how long it takes overall to establish an agreement, and for most networks, not all of them, it takes around weeks or months.
So this may or may not be an issue. So in order to, with the people investigating the operators' perceptions about the possible benefits of reducing inter‑connection time, we also asked, we ask the operators whether reducing inter‑connection time would provide benefits for the following use cases: So increasing the responsiveness to traffic dynamics, increasing peering port utilisation, ex employing new economic opportunities and leverage on demand services.
So the results showed some proponents that do not see an immediate benefit from reducing the inter‑connection time, but there is a significant amount of people that care about reducing inter‑connection time.
We also asked to the network operators whether there are concerns about reducing inter‑connection times and using a tool for doing so. So the top concern is confidentiality. No one wants to disclose information to a third‑party that is deemed confidential.
The second top concern is independence. Network operators seems to want to minimise dependence on third‑party entities.
And the last concern, one of the last concerns was stability. Does it affect Internet routing stability? I will not cover this last point in this presentation.
So based on this survey we identify the need for a digital protocol that would facilitate the inter‑connection, the establishment of inter‑connection agreements in the Internet. We identified five requirements. First one is an express I have interface that can be used to describe the information that needs to be exchanged in order to establish an agreement.
Independence. This reduction in inter‑connection time should ‑‑ so we want to minimise the dependency on any third‑party entities in this establishment of an agreement while still being able to reduce the inter‑connection time.
Confidentiality. No one wants to disclose information that is deemed confidential to unintended parts.
Reputability. We want to offer a way to network operators to provide reputability score that are based and can be validated. So, these are based on ‑‑ so it should be possible to verify the reputeability score has been given based on an exists agreement and not only word of mouth.
Tamper approve persistence. So if information is made public at ascertain point, no one should be able to modify it at any point in time.
So to this end we designed Dyn IX. Each network operator runs a local Dynamics node and this offers and interface that be used to query and offer agreements among the many different networks. So let me first focus on the language that is used in this interface.
We introduce a high level intent that describes the technical and business information that is related to an agreement.
So this information includes routing related information, service level agreement, the price for an agreement, and its length. So in the end, this intent is just a data structure that contains all this information, fields are not mandatory, and this information ‑‑ so one field in particular, pricing, one can express the pricing when it is offering and agreement as a function of different fields in this intent.
So this intent can be used to query or to offer route in the Internet and to establish agreements.
So let me now focus on the dam note pardon, node part. In this work we focussed on minimising independence on third parties. So this end of course we used or block chain that used the intents, mart contracts, a different functionalities of a block chain to build this system and the reducing to the largest extent possible dependency on third parties. The way we use the block chain has a few advantages that we envisage.
One is transparency, if you publish something on the block chain, this is public and will stay in the block chain, cannot be removed.
So for instance, if it will be possible to rate scores on the block chain. And another important advantage is that it would be possible to validate if the information that is stored in the block chain is legitimate or not based on the fact ‑‑ based on whether the agreement existed or not between members.
So of course this solution may not feed everyone's need but we see this as one interesting conceptual interesting and promising approach for reducing inter‑connection time.
So let me show you an example. So we have our nice block chain here and we already stored in the block chain information about a network A, information includes the offered services, contact information and reputation score that is validated on the block chain. So now there is a new network that joined the IXPs. It will update the block chain with its own information. And then it may discover on the block chain that network is offering a service that it needs.
So of the block chain, this network B can contact network A, query for an offer for an agreement, network A may eventually reply to this query with an offer. And if everything is agreed, then the two parties will sign, digital tee sign this offer and push the hash of the contract digitally signed on the block chain. One this is pushed on the block chain the two networks can start exchanging traffic and the agreement is on the block chain. So periodically, at the end of the agreement, both networks can update the reputation scores, and through smart contracts we can verify that this reputation scores are actually linked to existing agreements.
So, we designed this ‑‑ we developed a prototype, proof of concept of Dynam‑IX that is built‑up on the permission block chain hyper ledger and we evaluated it on 200 instances on AWS, and we ‑‑ I will only cover the first two questions that we covered in the evaluation here.
How long it takes to establish an agreement? We conducted a stressful test in which an entity trying to establish an agreement with just one entity and we observed that it takes, for Dynam‑IX to conclude the negotiation phase, around 2 minutes in this worst case, but in regular condition, this is typically below 10 seconds.
How fast does the block chain grow? So since we store information in the block chain, we want to know how fast it gross. So the answer clearly depends on the number of blocks that we create per time unit and the number of agreements that we have per time unit. So, to give you a rough picture, in order to sort 10 million transactions we need to use 100 gigabytes, and what does it mean, so if we have an IXP with 1500 ASes that establish on a daily basis 20 inter‑connection agreements, then this is roughly 10 million agreements. So this is the amount of space that we would need in one year for such an IXP at this reasonable rate of inter‑connection agreements.
So, in summary. We presented and designed Dynam‑IX which is a digital proposal that facilities inter‑connection agreement using an inter type structure. We believe that it may bring, based on the survey, we envision this system to provide benefits ranging from new economic opportunities, increase port utilisation, and enhance responsiveness to traffic dynamics.
So we have a proof of concept built upon a black chain, we evaluated it in practice to a certain extent. We use the specific property of a block chain to provide transparency, verifiability and persist answers of, in our case, reputability scores, but was course that there may be many other things that could be implemented on top of a block chain. Of course alternative designs are possible, but it is conceptually interesting to see what can be done with this new technology such as a block chain, and in the tend of course it boils down to what are the level of trust and privacy among network operators, among networks.
So thank you for your attention, and I'd be happy to take questions.
FLORENCE LAVROFF: Questions for Marco anybody? Okay. All right. I think that's it. Thank you Marco.
(Applause)
Right, this is new time for the connect update. This is an initiative that we started at the last meeting to ensure that we can have on the slides interesting updates relevant topics for the group.
So I really encourage you to go through the presentations which I have listed up there. They will be, I'm sure, a really useful use of your time. So we have here a couple of presentations. The first one which I have listed here is the Netflix content distribution one. Pivo, the linked in peering tool. Then we have the route server security from Job Snijders, and I also would like to point out to an article from Emile, does the Internet route around damage in 2018?
I also would like to mention that there will be a nice peering conference, that's a little bit out of our region, but we are there to connect, right. So that will be peering Asia 2.0 in Hong Kong in Q4 this year, 24th and 25th October.
To finish this update. I would like to also mention that there is a change on the DE‑CIX site and I'm wondering whether Wolfgang Tremmel is here to talk to it in more detail. All right. The stage is yours.
WOLFGANG TREMMEL: I actually uploaded a few slides. Never mind. Can I have a quick show of hands, who is on the DE‑CIX peering LAN in Frankfurt? Hands down who has changed the net mask recently? Okay. Those who still have their hands up now, please change the net max have /22 to /21. We have a few IPv4 addresses left on the peering LAN but we need to do this. The last change we did from 23 to 22 was ten years ago so I guess we are now good for another ten years at least.
We have an auto detection system where we can check if you have changed your net mask and if you have no changed within the next weeks, our customer service department will chase you up individually.
Okay, basically that's t please change your net mask if you are peering LAN at DE‑CIX Frankfurt from /22 to /21. And thanks for the time.
(Applause)
FLORENCE LAVROFF: Thanks Wolfgang. And I think that this is it this time for the connect update. If there is something that you would like to mention or something cool that you have read somewhere, feel free to let us know and we will also put this on the slide. Thank you.
All right, time to give the mic back to Remco.
REMCO VAN MOOK: So, that brings us to the intentionally left blank ‑‑ that brings us to almost the end of the session for today. This is the point where I solicit feedback from the room.
Any feedback you have for us right now that you are not going to put on a web forum that we can take into account for next session? Nina.
SPEAKER: Nina Bargisen, Netflix. I have some feedback, I have some self feedback as well. I'm kind of embarrassed about my own activity at this Working Group today. There is a number of really good interesting presentations. There was some stuff up there that I actually had a lot of remarks to but I didn't make it out of the Chair, and I notice that none of you in the room did either. And I think we can all do better. This Working Group is not a working group for just leaning back and listening to people who have put some effort into presenting. It is also a forum for this community to talk and debate and comment on what is going on, and we didn't do that today. And I just think we should do better next time.
Also, just feedback for the conference. This room is not good for this Working Group for the same reasons. So, my feedback. Thank you.
(Applause)
AUDIENCE SPEAKER: Hi. My name is Bengt Gorden. Just this is just a comment for the last comment sort of. If you have a look at the mail archive for Connect Working Group. It hasn't been ‑‑ I mean it's not 50 e‑mails during the last five years. And they actual work should be at the mailing list. Not here.
REMCO VAN MOOK: I don't disagree. But...
AUDIENCE SPEAKER: Just a comment.
REMCO VAN MOOK: I wholeheartedly agree with you. At the same time, I mean, we, as co‑chairs, have been struggling with getting feedback from this lovely group of people, and well basically the only way we can get feedback out of you is by forcing you while sitting in this room. So, the e‑mail list hasn't been very effective as you rightfully point out. I think we could try to do better. But, that's ‑‑ well we as chairs can try. But at the same time, it's really up to all of you.
AUDIENCE SPEAKER: I would just say that I'm at fault myself. So...
AUDIENCE SPEAKER: Martin Levy, CloudFlare. I am going to disagree with the last statement, if I may. I am going to agree with what Nina said, but for two different reasons. The second question, or statement, revolves ‑‑ the second resolves around a measure of just this as a communication tool, as a cooperation of people in a particular connection or interconnect part of the industry. It's an area that is ripe, pun intended, with multiple fora for discussion both in mailing lists or in face‑to‑face or in just random chat groups, there is an enormous amount of communication. This particular group, quite frankly by the statistics, does not get even close to the majority or the average. It is very low. But that doesn't undermine the need for this meeting.
In regards to what Nina said, and I'm instantly guilty, we would love ‑‑ let me turn around ‑‑ we would love people who have never come to the microphone, to come to the microphone. The usual suspects do this on a regular basis. I am guilty in that department. And so, this is a catch 22, and absolute catch 22. So I feel guilty, like Nina, not coming to the microphone, but in a way I sat there going oh I hope somebody does. So if you haven't come to the microphone, realise that you should in order to help the subject matter. That's all I can say.
AUDIENCE SPEAKER: Otherwise you'll just be listening to Martin and me all the time. Leave leave which is something you and I have to do all day long. I wouldn't recommend it.
AUDIENCE SPEAKER: Nina: Can I jump in with one remark on the mailing list. I kind of agree with Martin, it's true the general RIPE idea is the mailing list is where everything goes on, but I mean, that is, were my point of view, more in the policy process, in the whole we're discussing standards and that kind of thing, and that's not really what this Working Group is about, so I'm okay with the mailing lists just being for hey, it's time to think about what we want to talk about at the next meeting. Because this meeting is more about us, who communicates so many other fora, as Martin is saying, all the time, that we should just make sure we are active in this hour and a half twice a year. I mean honestly, we should be able to do that.
REMCO VAN MOOK: We don't even have a 9 a.m. slot, so there you go...
AUDIENCE SPEAKER: That will be the result next year, right.
REMCO VAN MOOK: Yes, that might be a threat that I'm going to have to defend the 11 a.m. and throwing Address Policy out of this room to the rest of the Working Group Chairs. Bent ‑‑
AUDIENCE SPEAKER: Bent: Would I like to say that I'm not opposed to the information that is put afford, but it doesn't really feel like a working group. It feels like more that this Working Group actually is not needed as a Working Group. If feels more that it's ‑‑ the presentations are good, they could be in another, not in another Working Group, but maybe in a Plenary instead.
REMCO VAN MOOK: Who knows? It should also come as no surprise that there has been ongoing discussion between the Programme Committee of the Plenary and the co‑chairs of this Working Group about some of the presentations and where they belong. So yes, absolutely.
But, since we're on the subject of having somebody who doesn't regularly come to a microphone, speak up, I got given a piece of paper but I'm actually going to give it back to him. He has got his own piece of paper. Paul hope /8 err, had a couple of questions for this room. And I think they are interesting, so, Paul, by all means go ahead.
AUDIENCE SPEAKER: Paul, from a real small network in the Netherlands. I want to see a show of hands. Does anyone still build BGP prefix filters on public peering interfaces, so on the Internet Exchanges, we're not talking about private interconnects, manually? So by looking at e‑mails from the Internet Exchange mailing list and then typing it into your config instead of getting it from routing registry? Does anyone still do that or know someone else who does that?
REMCO VAN MOOK: So a show of hand for people who manually maintain 5 million line files.
AUDIENCE SPEAKER: None, okay. Then I have got a second question. Should we take some action to bend these messages from the mailing lists of the exchanges? Thank you.
REMCO VAN MOOK: I think that is a helpful selection to the IXP operators in this room.
All right. Anyone else have any rocks to throw at anything?
AUDIENCE SPEAKER: Hi Remco. My name is Shilandi, I am from Net Africa and I would like to make a suggestion. I thoroughly enjoyed the presentations today and I agree with Nina and Martin, there hasn't been a lot of, you know ‑‑ we are actually just sitting here listening to other people and I would suggest maybe to have a session where everyone can share their experiences or ask each other questions in a more informal manner, I would say. Just to discuss the topics that were mentioned today, but in a more informal way to give our own feedback, our own questions and suggestions on the topics. Would that be possible?
REMCO VAN MOOK: I think that's an excellent suggestion. Logistics wise, that's going to give us something to think about. But, I will gladly take that to heart. The challenge that we have is that we have got a 90 minute slot and we're trying to get the most value out of it for all of you, which, so far, we have chosen to do in getting as diverse selection of presentations for you. But if we should really do a deep dive into two or three topics and have a more engaged discussion instead of doing or basically chasing half the Internet to get you six or seven presentations, that would be very helpful feedback from this room.
So should we try to tone it down and have longer discussions about fewer subjects? That a good idea? I sort of ‑‑ this is sort even a humming at an IETF. This is sort of a vague grunt.
AUDIENCE SPEAKER: Blake which say owe. I'm not sure that's she was suggesting actually. I think she was trying to get ‑‑ well I'll let her follow up on that, but I think the intent of the question was more, or the suggestion of more around let's have a 10, 15 minute discussion session at the end that's much more informal like get up to the mic, talk about the what purpose of this Working Group is, which is to foster connectivity in the Internet and even in private inter‑connection or you know the original charter of this Working Group was like if we're going to talk about met owe Internet connection or, this is the reason we dispanded the IX Working Group to make this, right. So, I mean, I'll let you follow up on that if you want, but that was my take on that was let's just have a more open discussion forum at the end of this session to get more people up to the mic and say what they think.
REMCO VAN MOOK: Gladly. Absolutely. Anyone who has any suggestions, feel free to contact either Florence or Will or me at the end of the session. Drop us an e‑mail. You could even use the mailing list for this. Oh my God!
So, anyone else hiding in the back behind the lights that I can't see? I think that's ‑‑ in that case, co‑chairs, are we good to go for this time around? There we go ‑‑
AUDIENCE SPEAKER: Tasha. I was in the Address Policy Working Group and changed and there we had the discussion about the last IPv4 addresses and there is a pool for the IXPs, and the question was, if there is traps a need to expand this, because currently it will last for years, this pool, and perhaps it could be wise to extend it to double it or something like this
REMCO VAN MOOK: I mean, I am an IXP operator, I am personally not opposed to getting more address space for IXPs, oddly enough. Is there ‑‑ I mean, I take it that requires a policy proposal in Address Policy. Any takers I think is the question here? Does anyone want to go ahead and push that through Address Policy, or get that discussed within Address Policy?
AUDIENCE SPEAKER: The question was, is there a need for it? The people who could answer it are sitting here, so...
REMCO VAN MOOK: And they are awfully quiet right now. Well thanks for that piece of information, thanks for that input. I am sure that it will be discussed in the appropriate areas.
AUDIENCE SPEAKER: Blake Wezeo. According to the slide from two talks ago, the DE‑CIX is going to need an is there 20 in ten years, right?
REMCO VAN MOOK: Yeah, so I mean, I happen to who know people who know people who wrote the IXP address space policy in the RIPE region and I think the maximum size that's allowed it a 21, so if any IXP needs more than a 21, they are on their own basically. Unless that policy gets changed as well. All right?
FLORENCE LAVROFF: I think this is basically it. In that case, thank you all very much for your time. Have a lovely RIPE meeting and see you next time.
AUDIENCE SPEAKER: Before we all leave, I'm Tomas, before we all heave, we have one guy here in the crowd who has a birthday today, and we all would like to sing him happy birthday. So it's thee owe over there and we promised to sing for him. So is it fair that we just spend happy birthday. Let's start...
(Lunch break)
LIVE CAPTIONING BY
MARY McKEON, RMR, CRR, CBC
DUBLIN, IRELAND.
