Closing Plenary‑RIPE 78 ‑‑ Reykjavik
Friday 24 May 2019
11 a.m.
BRIAN NISBET: Good morning everybody. Welcome to the Closing Plenary session of RIPE 78. If could you take your seats and end your conversations, that would be awesome, thank you very much. Before I have to start mentioning explicit people. I can see you all.
Anyway, we have a couple of great presentations and then onto the closing pieces of the meeting. But first, very briefly, the results of the PC elections and thank you to those who both stood and participated in the elections. And the two members who were elected are Franziska [Lisbau] and Jelte Jansen. So thank you very much. The full details will be put up on the website of the results of the election.
So, on to our presentation. There is going to be a slide put up there. So, pleased to introduce Susan Forney from Hurricane Electric on peering complex 101.
SUSAN FORNEY: Hi. This actually is my first RIPE meeting ever. But this is not my first time in Iceland because two years and 3 three days ago I was in Reykjavik to get married. So, this is a return trip. So I am very happy to have an excuse to come back here to this wonderful place.
What I'm here to talk to you today about is the economics of peering. Peering is really great. It's a wonderful thing but we don't really think about what it costs us to have a peering connection. So, today I'm going to go over those things. And I'm going to accomplish that by answering the following five questions first, why is peering never free?
When is peering worth the investment?
What type of peering should I do?
Why do I need a peering strategy?
Why should I be a good neighbour?
So let's start out with why peering is never free. First, peering is a connection between two network devices. And as we know, network devices are not free.
People are needed to configure network devices and maintain them and people are not free either. And network devices need electricity and rack space and a place to live and none of that is free either, as you know from your hosting bills.
So, peering has a cost, but as with anything with that cost it also has a value and to figure out what that value is, first you're going to need to think about a few things, like how much your port is going do cost. Don't forget optics, rack space, power, support, those lovely people you pay, the vendors. How much is going to cost a data centre. And what ‑‑ don't forget those pesky setup fees, and then while it's true that if you have a port and you are going to have a transit provider the transit provider would also consume a port. Any time you use a port to do something like peering, you are making an investment and you should think about how much that costs. So, it's a good exercise to keep track of it. If nothing else that is going to help you when the budget guy rolls around and asks you how much it's going to cost to run the network next year.
To analyse what this is costing us, I created a little chart, and my ISP means that ISP I'm using for a provider and my IX is some Internet Exchange. And what I have done is, in my, you know, limited experience in my career is just come up with garden variety prices for most exchanges, what it costs, your mileage may vary, you maybe getting transit prices, but this is just to try to illustrate. I started out with the device port, on average it's going to cost you about 200. If you break down the costs it's about €200 for a port on a device. The setup fee for a cross‑connect, usually like about twice the cross‑connection cost, so €500 I put down. Setup fee for the service, for your exchange port or transit provider, it was like 250 for an ISP, €500 for an IX and then you have your recurring costs you have to consider. So your ‑‑ we're assuming here a 10 gig port and your friendly Internet provider is going to expect usual a 2‑gig commit, so we put that down there, the commit price for this is €2,000. So, basically, you know, a euro per mega bit. The bursting price, I am setting at €1 per megabit. And then we don't have a price per port here, you know, on the ISP that doesn't matter, and then the cross‑connect fee of €250. If you look at the IX, it's a little simpler, you have got your upfront cost for the device port is the same, for the setup for the cross‑connect fee that's all the same. Service fee sometimes on the IX is a little pit more so I bumped that up a little bit. Obviously there is no commit on an exchange port so that's not applicable. But then there is the price per port and €500 for a 10 gig port is not bad for the industry. Then your cross‑connect is still 250 Keogh. So there we go.
So, to determine if it's worth the investment, you need to consider how much traffic you could actually move to that port. And to do that, you should consider who your potential peering partners would be on that exchange. So, for instance, exchanges where you can reach a content provider or a clout network can be a real advantage to you. If you are doing a lot of business say with you know Google because your company uses you know Google Office, Google Docs, peering with Google could save you a lot of traffic over your transit provider. Similarly if you have AWS or digital or somebody for a Cloud provider and you can get a peering connection with them, that's also going to save you a lot of bits that you would ordinarily have to pass across that transit connection. Also, don't forget to peer with caching networks like Akamai, Fastly and Limelight, because a lot of those traffic goes to those caching sites first and peering with them will save you a lot of bits on your transit connection.
So, to give you an idea of how this can work out for you, I am going to give you an example of a university I worked with at one point, they were trying to figure out how much traffic they needed to ‑‑ that they were using and where would be a good place to peer. And so, ordinarily if you are thinking about it you think oh a lot of research organisations and places they would peer and that would make sense and it does. But unfortunately these universities also provide transit for the dormitories, and when you looked at the traffic for them, 75 percent of their traffic was going to streaming services like NetFlix and Hulu. So, the big benefit for these people obviously would be being on an exchanges where they could get to these services and save a lot of money. So looking at that is really to figure out if it's worth the investment. If you don't know those things, like you are not in universal and you can't count on it being Amazon prime or whatever, then you might want to use NetFlow or sFLow because that can give you a lot of information about where your traffic is going and make you some, help you make some good decisions about where you should go and who you should peer with.
So, to help illustrate this, I made a little graph to show you an average cost of, based on the numbers that we used in that chart, what the differences in price is and so for the ISP cost we're still using what is basically a euro per megabit, and you can see that the cost starts out a little bit high at 500 megabits, by the time you get to your commit price at 2 gig on the ISP we start to approach you know, €1 per megabit. So that's looking good.
Since the IX cost, remember, was about €750 per month, that's lower and as you can see, it NetFlow does get free to my point, but it gets really close, you know, we're going all the way down here to like 17, 20 cents or so a megabit. Right there, it's looking like slam dunk, the ISP is way more expensive than a peering port. You have to take into consideration weights going to happen when you put the traffic on. The second graph I'm showing you, the orange line is is the ISP traffic and the grey line is the IX traffic. And what I did was I just assumed that 50% of your traffic could go across the ISP and 50% would go across the IX just to keep things simple. And then the blue line is the cost averaged between those two providers, the IX and the ISP. And so you can still see that yeah, things are looking great. It still looks like the peering port is a really good deal even when you average the cost you are paying less than just the transit. But, that's not what you need to think about.
What you actually need to think about is that commit cost which you probably forgot about because until be ‑‑ if you have got 50% of your traffic on IX and 50% of the traffic on your ISP, if you have a 2 gig commit, then you aren't hitting ‑‑ you haven't satisfied that commit until you get to 4 gigs of traffic. And so, the difference between the space between the orange line and yellow line shows you how much money your wasting until you get there. So, you need to think about this when you're putting traffic on an IX port to make sure that you're not wasting money and you know, getting ‑‑ not getting the value that you actually thought about.
So, in addition to the actual cost of transit IP in the port, don't forget to factor in your support costs. The operators costs money and if you streamline or automate your processes you are going to save. First, if you create peer groups for all the people you are going to be peering with on the exchange it's going to save you time and money over individually configuring each one of those peers every time you want to turn somebody up. You can also automate it makes it even better. And if you do that, all you're going to need to know from your neighbour is their AS number, their IP address, their AS‑SET and their prefix limits and you're ready to go.
Then, consider the support priority in your peers, you can waste a lot of money by waking your engineers up in the middle of the night because a peer on the exchange went down. You might want to consider deprioritising those things so that you're not doing that and unless of course you are a university and it's NetFlix, then it's a fire alarm, right.
Monitor your port capacity on your IX connections and increase it before you get into trouble. Because bits that fall on the floor on the IX on just as bad as bits that fall on the floor from a congested transit port. It's the same problem. And then use things like communities to make your peering a little smarter and get yourself a little more value.
So, now that we talked about the cost, I want to stress that it's really not all about the money. There are actual advantages to being on a peering exchange that are beyond what the cost is. Peering can provider you real benefits in terms of reduced latency and improved throughput to strategic partners and that can be worth a lot of money to your business, so, even if that port costed you a little bit more it might be worth it shall. You are going to gain some diversity in your edge, increase traffic flow, reduce latency and help your routers rebuild tables because not all the traffic is in one place.
It's going to improve the scale of your network, which helps you grow in the future. And your internal and external customers are likely to be happier. So not just money.
Now, the easiest option at most public exchanges, if you're going to think about what kind of peering you're going to do once you get there, is to peer with the IX route server, and this has some obvious advantages. First, you only have to set up one or two sessions if you peer with with both route servers or just one of them, and now you have access to all of the routes on the exchange, right. It's a little bit easier and faster, and even if you peer individually some people on the exchange, you can still peer with the route server. Although you might want to prefer the directly connected routes. The disadvantage with peering with the route server, however, is that you do have less control over your routing, and you might not get all of the available routes because not all networks advertise all of the routes to the route server. The other thing is, not all exchanges have route servers, so it might not even be an option.
So, in addition to peering on exchange you also can peer with people privately. You can make a direct connection if you are in the same data centre with somebody, and you have enough traffic to just fight cost of a cross‑connect. That's another way to peer it and saves you even the cost of having a port on the exchange. Of course you are going to want to make sure that it justifies the cost of the cross‑connect on the the ports on your device. And the other reason why this is good is in some exchanges, keeping traffic when you are doing a lot of traffic between just two peers, keeping the traffic off the exchange can put a burden on the switch and it just being a good neighbour to peer privately.
So, peering directly with other networks on the exchange obviously is what most people do. It's the most common and convenient way to set up a peering session. You set that port up and now you are ready to peer with literally everybody who is there. You have more routing options than you do with peering with the route server once the port is in place. The sessions turn up quickly. And I also just mention that peering across the exchange can be sold, some people charge for it, this does happen very often.
Now, let's talk about why you need a peering strategy. So, this is obviously going to get you a little bit more value from your port. If you think about it strategically, and some of the things you might want to consider are: What networks would you benefit most from peering with? What exchanges should join, because there are a lot of them out there and there are probably in some data centres there is more than one exchange you can join. How are you going to route those prefixes once you get the routes in your network?
So to determine if a network peer makes sense for you, obviously, first, do you send a lot of traffic over the transit connection? And could a direct connection improve your latency and have a compelling performance argument for you? And do you have excess bandwidth on that IX port? That's something to consider because sometimes peering with again, you know, a big provider that is going to ‑‑ that's going to be very advantageous, also adding that to your port can cause you to possibly congest it, so you need to think about that.
To illustrate how this can work. I have made this little drawing of this green company that has a satellite office, which designated by the little office icon, and the green company has a direct connection to a satellite office and the office has a router that connects back to the company and to the Internet. Now, as it turns out, that satellite office does a lot of business with this blue network down at the bottom, which has some downstreams and it's a good relationship because the satellite network has the Internet connection that makes it a little bit closer to get there and it's working out pretty well for everyone.
Then the green network gets on an Internet Exchange where the blue network also happens to belong, and they set up a peering connection. Well, if they don't do it carefully, here is what can happen. Now instead of the happy time where the satellite office was going to the Internet to get to the blue network, now it ‑‑ if the routing isn't set up properly, the satellite office can go through its home office, through the IX and back down to the blue network, causing increased latency and bad performance, which is exactly not why you got on the Internet Exchange.
So, as we have seen, peering can improve your routing and reduce your latency or not. So, if you peer at more than one location you may want to consider a routing architecture that allows your prefixes to be announced a little more strategically to keep your traffic local. Some peers can benefit your network more than others, and if you figure that out, you're going to get a return on your investment more quickly.
So, last point. Why you should be a good neighbour?
So, peering works when it is a great experience for all parties. Clean up your advertisements. Please. Do not leak your private IP space or routes with private AS numbers to your peers. It just looks bad and it makes them not have a lot of confidence in you. Please be easy to contact by keeping up to date routing information and contact information in things like peering DB dotcom or in the RIPE registry so that people can contact you easily. And keep your IRR records up to date and this is more important than it ever has been because a lot of networks that are upstream from you will not accept your routes if you do not have good IRR records and it might not be obvious. In networks like NTT and Telia who have very secure routing policies, if you do not have a good IRR path and your destinations is in that network, they won't accept that route. So keep those IRR records up to date so that your routes will be accepted everywhere.
So, while the other network that you were peering with on that exchange are probably great people, the reality is you can trust no one, please. Set maximum prefix limits on your peers, one of my favourite stories about this was a time when you used to work for a small software company and I was in the hotel one morning and I saw this other provider crawling out of of the elevator half deadened I asked him what happened he said, okay, he said one of my peers readvertised the Internet to me last night. And I said, didn't you have max prefix limits set? He said, I do now. Don't let this happen to you.
Filter the routes that you accept, so that they are only valid routes from the peers AS are accepted, and deny private IP space and bogons so that people don't accidentally advertise bad stuff to you.
So building filters does not have to be hard. You can script it yourself or you can use a tool like BGP Q3 and you can get this from GitHub, it's very simple. I used an example here to show you how easy it was to generate a prefix list for a Juniper router. Look at this. Just, simple little command. Then the argument is the AS. And boom. There you go. There is your prefix filter all generated for you. You have no excuse.
So, please be responsive when you are notified of an issue. No one likes a peer who ignores them, especially if they are experiencing a DDoS or a phishing attempt. I think we had a rather spirited discussion about this Thursday morning, about why it is important to be able to be contacted.
No one can take advantage of you without your permission. If you control your advertisements, that's going to help you. And then, even if you do everything right, not all networks are going to want to peer with you and honestly this has more to do with the peering policy than it does with you. Don't take it personally. However, I would encourage you that if someone declines to peer with you, ask again, because sometimes people will not peer with you because their port is nearly at capacity at the exchange and if they upgrade that later, then they might peer with you later. But they might not think to come back to you, so ask, you know, if they say no, it didn't get any worse.
So all in all, peering is a really good thing. By talking about this I don't mean to, you know, diminish the joys and benefits of peering across an exchange, but hopefully now you have a better idea of how you can make it a good experience.
So. Questions?
(Applause)
AUDIENCE SPEAKER: Thank you. Interesting perspective. I assume that this presentation is aimed at rather small networks because I think you should add a chapter into it saying something about as you grow, because there are a couple of things that is lacking. You are mentioning the private peering, or basically, but you are not putting it in the model. I think ‑‑ you can extend the model into when it private peering a good idea? What are the consequences for what happens on your IX and what happens on your transit cost? And Atlas third thing that I think benefits most networks these days, in particular access networks which is embedding content provider service in the network. At some point that is a beneficial idea for both parties as well, and belongs in a model like this because it will affect the economy of the Internet Exchange and the private peering and the transit as well. So, it's a good starting point, but I think there is a lot of things to be put into this model to be comprehensive for everything an ISP should look at when they make the decision on whether to pie a big pipe or to go out and do it more granularly.
BENNO OVEREINDER: As a note, I know that some people in the RIPE community are thinking of peering best current practices document. So maybe you can have also, give them input or collaborate. And keep in contact.
AUDIENCE SPEAKER: I forgot to state my name and affiliation. I am Nina from NetFlix.
AUDIENCE SPEAKER: [Milan] Internet Exchange. Just a short comment actually. It's your second RIPE meeting because the first one was RIPE 68.
SUSAN FORNEY: Some people make a difference between the main RIPE meeting and the regional ones.
AUDIENCE SPEAKER: Blake Willis, Zayo. Thanks. It's helpful. It's nice to see it all in one place where it's management compatible. If I could add a quick thing, please don't post prefix list updates to IXP mailing lists. It's a waste of everyone's time. Please don't do it. I am about to bomb somebody right now for that very politely saying much better way to get your routes accepted rather than posting stuff to mailing lists is to sign your routes with RPKI.
BENNO OVEREINDER: Thank you.
So. Next up is Sjoerd, actually one of the most interesting presentations in the Plenary, because Sjoerd will tell us what we have done in the last week, when we go to lunch, for dinner, go to bed, when we paid attention to Plenary presentations or not.
SJOERD OOSTDIJCK: So. My name is Sjoerd. Hopefully you haven't noticed me too much this week because otherwise that would have meant we would have had some serious problems.
This is the technical report, like Benno said, I am going to tell you about the stuff that we do. And I think one of the most important things that we're doing right now is RPKI. We have enabled this on our network, and so far so good, I don't think anybody has really noticed anything. We're dropping invalids. For now, we are using Bird virtual router on, with the RIPE validator and it's running on VM aware on pretty slow CPU really but it's actually doing great. We might try something new next time, we're not sure yet. But this is kind of what it looks like if you give it two slow CPUs. You haven't been doing very much network bandwidth to be honest, you haven't really gotten over 300 M bits, that's a shame, they were thinking about giving us a 10 gig uplink but I don't think we would have needed it. You need to try harder next time.
This basically means, at least in my opinion, that everybody should be able to do RPKI because everybody has the capacity to run a couple of virtual routers somewhere in their network, surely.
If you don't know how, steal our config, it's up on this. I recommend just going and downloading this presentation instead of typing in that thing. So, there is nothing stopping you from doing this in my opinion.
Things that did go wrong. Interestingly enough, on Friday we normally start the setup, and when we got here in the morning our stuff just wasn't here. It was stuck in customs, and, as luck would have it, the computer system was down at the port or at the customs or something and they just couldn't clear out the container to release it and it took about until 2 p.m. for us to get our stuff and finally start setting up. But, you know, we made a couple of long evenings and everything worked out a good meeting, as far as I know.
It did start out quite interestingly upstairs in the side room at the first tutorial. The power just kept going out. I don't know if anybody actually noticed that, but I think somebody just had a small twitch and spilled some water into a power block, they were just sitting there looking at us trying to figure it out. Don't be ashamed if you spill some water somewhere, just tell us, we'll pull the plug and everything is good. Just let us know.
And the only other thing that really happened is the Windows tricaster rebooted twice, but it's Windows, so, you know...
We had to reboot the steno laptop. That's also Windows. And one of these clickers died. We thought we got good ones, but apparently if you stick them in a boat, they don't survive. I don't know.
Obligatory network stats. You guys, like I said before, you haven't been doing a lot of traffic to be honest. But actually the spread from v4 to v6 is pretty good. It's kind of hard even for me to read this from here. But basically, the ‑‑ well, the 2.4 and 5 gigahertz is the second one, and the bottom one, the orange is basically the NAT 64 network and the green bit is the normal network. So, that's pretty good.
Of course we have a networking app, you guys have been using it a lot. So that's great. The orange one is basically in the middle is when the meeting starts and when you guys start chatting. There wasn't a lot of chat going on yesterday. I don't know why. It's like just a slow day or something. I don't know. And in here, every horizontal block is one day, so the left stat, the left graph has a lot more days than all the other ones.
And that's it really. This is the technical team. We had a couple of new guys. We have Andrea, who is helping us. He is over there. It's his first time helping us on the technical team, and Rob as well, who you probably didn't see, he was only here for the second weekend. To save you money, we sent him back home.
And that's it. Any questions?
(Applause)
BRIAN NISBET: Thank you again for allowing us to read our e‑mail while we should be listening to presentations. Very important.
AUDIENCE SPEAKER: Andrei: Can you please go back to the slide with networks. So, if I read correctly, the NAT 64 network has actually more connected clients than the regular networks? Do I read it right?
SJOERD OOSTDIJCK: It's stacked so it's a lot less. So the green one is the baseline and then the original one is stacked on top. It's about a sixth of the normal network, something like that.
AUDIENCE SPEAKER: So I was ‑‑ all right ‑‑ I was maybe over‑excited. Still, there was the question on the Monday Plenary whether 2019 is the year of NAT 64 network, so maybe I would ask is 2019 the year of NAT 64 network is the forward network for the RIPE meeting maybe for next RIPE meeting?
SJOERD OOSTDIJCK: We'll think about about it. No guarantees.
AUDIENCE SPEAKER: Because the name is the most important.
BRIAN NISBET: That would be a very brave decision.
AUDIENCE SPEAKER: Erik from Interlan. Can you go back to slide 7, please. Why do you have fewer invitations than meetings? Can you initiate the meeting without invitation?
SJOERD OOSTDIJCK: I don't know. I think it's maybe that you have multiple people in a meeting. But, I didn't produce the statistics so that's the only thing I can ‑‑
AUDIENCE SPEAKER: The difference is quite big.
SJOERD OOSTDIJCK: I suppose it's big meetings.
AUDIENCE SPEAKER: Randy Bush. New guys?
SJOERD OOSTDIJCK: Yeah, fresh blood.
RANDY BUSH: All guys.
SJOERD OOSTDIJCK: Yeah.
(Applause)
BRIAN NISBET: So, we have a couple of lightning talks to round out the Plenary agenda before the PC hands back to Hans Petter, and first up we have Faucet: Openflow SDN from Richard Nelson.
RICHARD NELSON: I was a bit stressed about being last but putting me after that talk is good.
.
SDN is one of those terms that kind of means all sorts of things to people so we have to be a little bit explicit about what we mean.
Openflow is now an old protocol that's not being developed any more, and it certainly hasn't, but I'm going to suggest to you that it's slightly exaggerated.
This is about the enterprise space, I am sorry I realise not many people here are in the enterprise space. The genesis of Faucet was a long time ago when they wanted to connect an Openflow switch to the university network and he needed a controller that supported VLANs so he couldn't find one so he wrote a prototype. It got moving there. Overflow turns out to be work really well on the place, that works well for policy and individual users and security, and stuff like that. So Faucet has concentrated on that. It provides Layer2 and Layer3 working. It's designed for centralised control plane so it does not implement spanning tree or IPs or anything like that, it also has a fairly powerful ACL system that allows you to customise the installation and do proper SDN control for what you want.
OpenFlow represents packets processes as a pipeline of processing tables. This is the Faucet pipeline. Actually, that's the maximum pipeline. Faucet is a dynamic thing, so, individual tables are only created on switch when the features that use them are actually configured into the controller.
Openflow Faucet uses pure Openflow 1.3 multitable. There is no driver code or customisation to specific hardware in there and that allows it to be really and truly multi‑vendor, it will work with any particular piece of hardware.
And to make sure that that works, we have a fairly sophisticated test suite. So it has the internal unit testing, but then it can be hooked up to a switch and we can check that everything actually works by sending packets and seeing what comes back and it does performance testing so you know it if you hit the slow path or something like that.
Uses Open vSwitch as a reference implementation of Openflow, but then you can hook it up to a real hardware or other switch, and actually check that that switch implements all of the Openflow features that are required for Faucet to work. And this has the effect that you can actually use it to automate part of your purchasing policy. So, Stephen Stewart from Google, the Google enterprise group have announced, I think over a year ago, that they are going to do just that. So now when they are buying switches they use the Faucet switch. With that push we have got hardware support for that. Most of these are Openflow people who have been around for a while. But Cisco added Openflow support to their catalyst 9 Ks last year specifically to support Faucet.
Just quickly, Faucet is designed to be really simple. Easy to use. It's designed to be easy to automate and it sort of fits in to a Dev ops style deployment. It's also very lightweight. It runs easily on a Raspberry PI.
Grafana, Prometheus and InfluxDB seems to be the the new sort of standard monitoring stack, and we support that too.
Because we're good at security, other people were started using Faucet to build on top of it to do interesting and quite clever security things in a variety of things.
When we got this controller, we wanted to deploy it and show that it worked and show it to the world. The first really significant production deployment was at the NZNOG conference in January 2017, it was a bit hairy. Geoff Huston may remember coming along and finding all the developers huddled in a bar and discussing time‑outs because there had been fairly badly bitten by some assumptions that turned out to be wrong. But it worked well enough that they invited us back and it's been ‑‑ it now works reasonably well. We've dog‑fooded it at our ‑‑ it's a multi‑vendor network and everything is online, you can download the switch configs and you can see the dashboards and the performance tools installed.
Last year, the developers wanted to shoot for something bigger, and we managed to get invited to SC 18. It's a computing conference that's a big conference, about 15,000 people and they have an exhibition floor with hundreds of booths with lots of HP vendors and super computer centres and they do live demos so they need to build a network to support it.
SCinet has become an event in and of itself. To give you an idea of its size, at the top there are 40 separate 100 gig services that were brought into the venue over, especially laid fibre just for a conference that lasts a week. The core was a Cisco and a Juniper, the production network is out on the right‑hand side. And the distribution network for the exhibition space was at the bottom. And Faucet appears, it's a little bit hard to see on this diagram ‑‑ Faucet, that's our main switch and our controller and then we had switches in each of the distribution so this was a collaboration between ourselves and ES net and a certain Cloud vendor. We had equipment from three different vendors. That switch there was a barefoot Divino‑based switch, an OpenFlow wrote an Openflow agent to sit on top it. We think this was the first over float hybrid P4 network. We had a couple of different 32 by 100 gig switches, so we think it was the world's first multi‑vendor Openflow network operating at 100 gig.
So what worked well. Well the SDN stuff worked well. We obviously had to retest things like the new OpenFlow agent and stuff but when everybody got there it was all plugged in. It booted up and just worked first time. The automation also worked really well. We just dumped some stuff out of the super computing database and ran it through the automation and all the configs just download and it happened really quite easily.
Some things didn't work so well. It turns out that running fibre cables across a concrete floor when people were driving forklifts etc. Around to build booths it's something you only want to do if you really have to. There are all sorts of problems with mismatched optics and booth owners bringing the wrong gear and stuff like that. But fortunately, because the automation, our guys had lots of time to run around and help them.
It's a show case network, so everything ends up in these nice glass‑fronted cases and you can look at it and see what's going. The total network is, I think, 50 million dollars worth of equipment and there was 200 volunteers to build and operate it. So ‑‑ but the Faucet team was quite a lot smaller and that includes the management side it have as well. That was us.
Thank you.
(Applause)
BRIAN NISBET: Thank you very much. We have a short amount of time if anyone has any questions or otherwise. Super computing. The amazing work that the folks do here for the network and then you scale it up and up and up, a colleague of mine worked in it a few times, to bring that kind of network in for a week and set it up and run it and then tear it all down again, yeah, it's very impressive.
RICHARD NELSON: It was interesting to go and see.
BRIAN NISBET: Thank you very much. Okay. So for our last trick this week, we have something that will hopefully just check how awake you all are at this point in time. A little bit of interactivity, so, Fernando Garcia and it's an interactive little quiz for you all and are you up to the level of RIPE 78? So, we'll see how this ‑‑ we're doing lots of interactivity and experimentation this week, so let's see how this works.
FERNANDO GARCIA: Richard said that he was interested before the earlier presentation, so...
Okay, this is something that we have made in the SNOG meetings in four times and it worked very well. We were able to wake up the people. So I will try something like that after today's session.
This is a little game to see if you are able to be a real RIPE engineer, right.net ‑‑ you know. But this is a quick game to discover how knowledge of these things. But fears and disclaimers. Fears that an employee of Telefonica digital of Spain, but my employer doesn't want to know anything about this. Neither RIPE, neither RIPE NCC, this is my only fault. Also very important, this game is not RPKI protected, so probably has been hacked and changed. And I have the final decision, in truth, this agrees with me, I have the final decision. Okay. So let's play. I don't know how many of you know Kahoot. If not, you are going to discover it.
This wasn't expected.
You can use your laptop, your mobile, your, I hope you can use your tablet, whatever, and have Internet connectivity. If you want to play, connect to kahoot.it and this pin, okay there are 855 tenants, but okay ‑‑ let's see, when the number stabilise, we'll start, okay. One minute or something like that. I have ten minutes by the way, you have ten seconds to answer each question, because we meet a lot of difficult test to discover that you can't look at running Google, so, we use ten seconds. And there are 15 questions, important, you get points but as you are selecting the current answer and by the time you use. So, if you do it in two seconds you win over the people who do it in five seconds.
Okay, let's start...
Let's go. Okay. You know, you must select the correct colour. The company that built the first Internet routers was originally dedicated to? Select correct colour.
There are many good books about this, and probably I can recommend you some of them. One is called, by the way, I didn't write it, it's very good, when they start to stay up at night, everybody should read that.
Next question: Null route, by the way ‑‑ sorry, I don't know who is null route, the winner, of course, will get ‑‑ a browser in ‑‑ at least until the meeting finished.
Okay, second question: One of the first super computers of history is a grey XMP, which was its CPU clock?
Very well. 105 monitoring hertz. It seems a joke, but it was a real ‑‑ and by the way, the photo you saw is the grey XMP that they have in the super computer centre of Catalonia.
Null route is still winning. There is someone faster than you.
Third question: In which film one of the characters is a computer called Wopr?
It's war games. The first movie I went with all my university friends in two rows of the cinema, with diskettes, print of of paper and everybody looking at us.
Okay, ace, if someone wants fame, you can say that's me. If ace is here, or you can wait to the end. Null route has disappeared. I think he was wrong with this.
Okay, next question: The prefix 13.0.0.0 /8 is now managed by ARIN, but who was the original owner?
Xerox PARC. Good.
And AS 185 D, okay, this is easy to discover, everybody look who is AS 1835.
Okay. 5, the IPv6 protocol is 6 and not 5 because?
No, there was not a typing error. But number 5 was used for a streaming protocol. Yes. Most of you know that.
AS 1835 is still winning. Very well.
Okay. Next question. TV in TLD really means?
Most of you know this. It's ‑‑ but basically they sell television domains.
Okay. 7. CDP is winning now. AS 1835 disappeared.
Okay. Question 7. The first mass spam by an e‑mail was:
A new computer from DEC. Okay, we can disagree on this. Some people can say, but you can know the rules in the beginning, I have the truth ‑‑
Question: Which of these following innovations was not intended by Van Jacobson?
Anycast. He is one of my heroes. I don't know him, but seems a really mindful guy.
Next question: Which of these is a valid IPv6 address?
Yes, the last one.
Next question: MPLS Unicast over ethernet uses the Ethertype?
Blue is the right answer.
Next question:
The technical standard of the Internet are defined by?
The IETF is the correct answer.
Dotwaffle still is winning.
Next question: Where was the first RIPE meeting held?
Amsterdam is correct.
To be honest, I thought in Lucerne until I see the RIPE meeting presentation.
Dotwaffle, okay. Still winning.
Next question: What RFC and year says "Plan that will take up past the exhaustion of the address space"?
Red is the correct answer. RFC 1287, 1991.
Next question: The book "Hackers" tells that the first good hackers appeared in the TMRC. TMRC means?
Green is the answer.
The last question: Who wrote the RIPE Doc RIPE‑431 RIPE anti‑spoofing task force HOW‑TO?
Red is the answer. Yes, it was me. With a friend that is not here.
And the winner is: Dotwaffle followed by Ace. Is Dotwaffle here?
Okay. With this I finish my presentation, you can vote for it, but probably... okay, thank you for playing and thank you for attending RIPE 78 with me. It was a pleasure.
(Applause)
BENNO OVEREINDER: Hans Petter. So all good things comes an end, so Hans Petter can close the session.
HANS PETTER HOLEN: Thank you, Benno. So. Another week of RIPE meeting has come to an end. So, this meeting wouldn't have happened without you guys, who were here and made this what it has been.
199 newcomers, and 742 checked in as of 10:30 this morning. Not the biggest one but almost. That's cool, right? Iceland, far away, and nobody will come. Well, no.
27% newcomers, that's a really good recruitment for this community. And I think the split between commercials and academics and so on, is approximately where it has been. There hasn't been changes. Looking at the countries, it's interesting how easy it is to come from Germany to Iceland, beat the Americans. And then usually we have a huge turnout from the local community, but I guess with the proportional size of Icelandic population, I think it's really good with 38.
A lot of the work, not only at the RIPE meetings but between the RIPE meetings, is due to Working Group Chairs looking after the Working Groups, so I want to give a special thanks to all the Working Group Chairs.
(Applause)
There has been some change in there. Paolo sent me an e‑mail today that he is stepping down so the the Routing Working Group would have to start a collection process for a new Chair. So, an extra applause to Paolo.
And we also have two new Working Group Chairs, Sandoche for the IoT Working Group, and I assume that Rob Evans was confirmed as Working Group Chair for the Services Working Group as well.
(Applause)
Thank you so much for serving, for volunteering to serve their community.
The Programme Committee has done a tremendous job, so if I could ask you all to come up on stage and we usually give you a special thanks. So, as you know, the Programme Committee has a lot of volunteers that are elected by you guys, and the regional ‑‑ the NOGs, and there is one special, there is always one that's more special than the others, and that's Benno, and he has been Chair now for ‑‑
BENNO OVEREINDER: Chair four years and PC six years.
HANS PETTER HOLEN: Since the PC has a term limits, then he has to step down, at least for now. So give them a warm applause.
(Applause)
You have already heard about the PC elections but I have kept them in here for reference so that it's documented, and Franciso, welcome back, and Jelte has been elected, we heard earlier today, so congrats to the two of you.
(Applause)
Then I will talk a bit about the type diversity task force update. We heard about the code of conduct in the lightning talk earlier this meeting. This code of conduct is still under discussion. If you want to discuss it, join the diversity task force list, it's open, and before it's concluded it will be shared with the whole community and call for consensus on the RIPE list, as we do with these kind of documents.
The task force is also gathering gender metrics, it has also worked to make sure that we have on‑site childcare and is also reaching out to local communities. So that's kind of an active task force working in this space.
Women in Tech lunch was a great success. This time it was a bit different from the previous one, it wasn't sort of centred around the food but it was more a session in the lunch break and you you could have food before you went in there.
On‑site childcare, fully booked, 14 children, so this is a good recruitment to the community.
(Applause)
And we have had amazing feedback from the parents.
RIPE meeting monitoring, I'm not sure if all of you are familiar with that but when you register with the meeting you are asked whether you willing to become a mentor or if you would like to have a mentor. So, I would really ask everybody who has been here for some years and feel that they have something to contribute to newcomers, to sign up as mentors at the next meeting because it's really popular and it's a really good way of introducing people into the community.
We had 20 mentors/mentee pairs this time but I think it's always good to have new blood in also on the mentoring side here.
We tried a new way, the Programme Committee tried a new way of getting questions from the room at this meeting. And we have had feedback on that. And if I'm going to characterise it, the old‑timers thinks that new stuff is not worth it, so they would like to have their lines at the microphones. But a lot of newcomers that thought that it was a really great way of raising questions, so I think this is something that we should at least have a close look at and maybe not just stick in the old ways, but that's something for the Programme Committee to evaluate afterwards.
We have also discussed in the PC and the especially in the Working Group Chairs lunch this time, time‑keeping, and that's something that we are working on, but this is also, as, you know, this is a meeting when you get to discuss things, and we think it's important that if there is an important discussion going on, we don't really want to cut it short just to go to the coffee break. Of course, the coffee breaks are important for you to interact and for stuff and stenographers to actually get a rest between all the talks, but really, we need to have the policy discussions and the good discussions in the community as well. So this is always going to be a balance.
Chair selection process: Five years ago I was appointed as the successor of Rob Blokzijl, that has been Chair for 25 years, he was appointed as a volunteer at the first RIPE meeting. And what he tasked me with was to put in place a procedure for selecting my successor. Now, this has been discussed over a couple of years now and there seems to be now a convergence towards some text that's been published on the list. We had a BoF on Tuesday, there are now two documents under discussion, the Chair selection process by a NomCom and then a document describing how to form and set up that NomCom. So this ‑‑ I have shared on the RIPE list link to say these two documents and if you want to discuss this, it's still possible for another, let's say, three weeks and then we will do a call for consensus on the RIPE list here. It looks like there are we were actually going to a point where we have a documented procedure to replace me and then we will run that procedure. I may or may not run again, but part of this is also selecting a vice‑chair, so that there is some redundancy even on my label.
Big picture BoF, we had a BoF to discuss a lot of topics around where do we want the RIPE community to go, and that was valid and that was a really good discussion. I have three takeaways from that BoF, there were a lot of other things and we will write up and share some of that, some of the notes that we made. But one of the things that I put on my list to discuss with the Working Group Chairs and PC is the notion of a RIPE community Plenary session so that we have this common thoughts that we have now had into different BoFs to have that in the Plenary session somewhere on the agenda. There was also talks on the database to have a task force on a high level purpose and direction of the RIPE database, and this is not about adding new fields or tweaking some of the existing design, but to step back and have a sort of a bit more visionary look at where, today, 20, 30 years later, what do we want this database or what do we need this database for and how shall we develop it further?
And what I plan to do there is to appoint a task force, I'll propose a charter and propose, appoint a task force, a small one to work on this to come up with a proposal that can be discussion and adapted by the community. I think that's an efficient way of moving ahead there. If anybody is interested to serve on that task force, drop me an e‑mail and I'll have a look at the volunteers and I'll also approach some of you directly because I think, I know that some you have strong feelings about this. And see if we can set together a balanced small task force on this.
One of the other things that came up in this discussion was that, yes, but we are discussing this now but accountability task force had really done a lot of work already so I will review that report from the accountability task force and look at what actions they propose and then that's actually something that we can also discuss and agree upon following up in the community Plenary session.
So that's my takeaways, and of course there were a lot of other things discussed and things that I will put on the to‑do list for further discussion, but that's at least my summary from that session.
We would like your feedback. So, please take the RIPE NCC survey for 2019. This is the first step in giving feedback to the RIPE NCC on what you think they are doing good, bad, where do you want them to go? The survey is now available in nine languages. And it takes ten minutes or less to complete. And it closes at the 30th June, so please do this before you go on this year's summer vacation.
Here is the link for that one. Of course the second way that you can give input to the RIPE NCC is, next time there is an activity plan coming up and you can give input on that plan but this is then the sort of the first step before the RIPE NCC starts to make the next version of the activity plan.
Prizes. That's the only reason that you have come here, right. So, we used to have for many years the first one who registered but then we figured out that somebody probably had a sneaky algorithm to figure out how to get first on that list. Well, I think I'm first on the list because that's hard‑coded in the programme, but anyway, so we decided this time to pick the first local one, the first from Iceland, and
Gunnar Örvarsson, are you here?
(Applause)
And I have also been told that this is a very special day for you. So this is also a birthday present. So happy birthday.
And then the other prize that we will hand out goes to a newcomer,
Aleksandr Grichishkin.
(Applause)
And then as always, even though RIPE NCC staff does a tremendous job in putting together this, they are totally dependent on the local host, so, if Ern and Marius from Farice and ‑‑ we have a small token of appreciation to you as well. Thank you very much for helping out with making this a great meeting.
(Applause)
So, thank you so much for inviting us to Iceland and making sure that this was a really memorable event for us. Thank you.
And I said feedback. We definitely want feedback for the meeting as well. So here is an URL for the meeting feedback, so please click on this before you leave or on your way home when you're waiting for your aeroplane, and than brings me to the very end of this meeting I think, unless there is ‑‑ there are some people moving here ‑‑ on the side. I was supposed to thank our hosts and sponsors, but...
HANS PETTER HOLEN: Thank you. Then the only thing left is for me to close the meeting and welcome you to all to the Netherlands, and this time, or next time it's not in Amsterdam but in Rotterdam, and that is to call for some variation and also show you that there are more than one city in the Netherlands.
So thank you so much for this meeting, safe flight home and see you all next time.
(Applause)
LIVE CAPTIONING BY
MARY McKEON, RMR, CRR, CBC
DUBLIN, IRELAND.
