RIPE 87, Rome

27 November 2023

Opening Plenary at 2 p.m.:


27 November 2023

Opening Plenary at 2 p.m.:

MIRJAM KUEHNE: There are a lot of chairs here I can see here in front, it's going to be cosy. Wait a few moments so people can find a seat: Right, let's get this started, there's still some peeping coming in, there's some space, a lot of chairs here and the front rows, please find a seat, but yeah, welcome, welcome to RIPE 87. It's great to see so many of you again, or also newcomers, see for the first time. We have quite a good turnout, I will show you some numbers later. So I am Mirjam Kuhne, I am the Chair of the RIPE community, we also have a Vice Chair, Niall O'Reilly who is unfortunately not here in person for family reasons but he is participating remotely, so he is on Meetecho and will jump in when necessary, and you might also see him on chat commenting on questions you might have or just chatting with you in the background, which is great.

This is actually our third meeting in Rome, the first meeting we had here was RIPE 21, I was there, I think. I was relatively fresh still at the time and to this community, and we looked at the minutes and the minutes it said at that point it laid it was the larger RIPE meeting ever with 110 attendees and the second time we were here in 2010, there was also something interesting happening at the time, I mean this was 2010, yes, this is some time ago, there was some unscheduled talk that introduced a suggestion of the World IPv6 Day, and there was actually Lorenzo at the time who had this idea and that is kind of minuted in the records, you can find it there. We will see at the end of the week what we can record what the highlights are from this meeting so we will see what we will find in the minutes after this week.

So, we currently have 966 registrations in total, that's both online and on‑site, you can see the distribution there. About, just almost 500 people have now checked in here on‑site, or have checked in in total for the meeting, and we should not forget, this is a reminder to myself and all the other session Chairs throughout the week, we do have quite a number of online participations, they are there behind the screen, on the screen you can see the queue of people following there and you can see online, the platform, the Meetecho platform and how to use it and how to interact also with the on‑line participants.

Another thing I think is really exciting is that we also have some local hubs, and what do we mean by that? We have all these people following remotely. There are some participants who took the initiative in six locations throughout the region to kind of organise themselves and get together in one location, in the university or one of the operators' offices, and they basically follow us remotely kind of as a group, so they kind of have a little mini RIPE meeting together so they don't have to sit home alone and they have a bit of the community feel that we have here also together.

So we are kind of experimenting with this, I am really excited we have so many of them. It kind of started with one and then the NCC sent out a call, anyone else who wants to take that initiative, and so we have all these people organising themselves. I don't know if you have an opportunity to see them on Meetecho right now but otherwise you might see them throughout the week and we include them a bit in this community meeting.

We will see how this goes and how this evolves over time, maybe we will have that again next time and I hope to see many of them come to the next RIPE meeting in person.

Please come in, we have some chairs in front, you don't have to stand in the back. I don't know if we have chairs on the sides but it's probably not ‑‑ it's not easy to see with the pillars there but there are some chairs here and here also in front.

Right, let's dive into the RIPE meeting plan. We made a slight change to the schedule, we usually had Monday and Tuesday plenary sessions and then Wednesday, Thursday Working Group sessions. We shifted some things around so this time all the Working Groups can have 90 minutes meeting slots again and, therefore, we also allowed for the RIPE NCC Services Working Group and the RIPE NCC members' meeting basically have the entire Wednesday afternoon. Therefore, the PC sacrifices 30 minutes in total. In the end we found a good compromise there. On Tuesday afternoon we would have had two Working Group sessions that would otherwise have taken place on Wednesday, they got a longer slot like it was in the past, pre‑Covid, basically.

So this is the new schedule for now; see how that goes. They are looking at the agenda, there are maybe some themes that stand out and so a number of topics related to sustainability, maybe continuation of a discussion we started last time, and also some RIPE meetings ago, and there is a theme that is probably not a ‑‑ a topic that's not going to go away, it's related to our engagement with governments and other stakeholders in this community. So there are a number of presentations on that. And then of course a whole bunch of different technical topics that we will be ‑‑ that will be covered and discussed during the week.

I would like to remind you of the RIPE Code of Conduct, you should have all seen it when you registered. Is my time already over?

Sorry, I am not done yet, Jan. Okay, I will speed up. You should have also seen the RIPE Code of Conduct. This is just a short version of it, there's a whole RIPE Code of Conduct when you register and you should have checked that. Just as a reminder, please treat each other with respect and tolerance and this is an open meeting, we have quite a diverse set of people. I would also remind you that sometimes when we speak to each other here in the room or make a comment or maybe even more so on the mailing lists it feels like you are just responding to one person and you have this dialogue with one person but obviously there are 100 of people listening in the background, and just keep that in mind when you make a comment. Also especially since we want to attract new people and don't want to turn them away, they all know each other, it's kind of intimidating, keep that in mind with the tone you have and when you communicate with each other.

If you think something is violating the Code of Conduct, you have experienced that you feel uncomfortable with, there is a Code of Conduct team and we have two new volunteers on the team, not all of them are here in person this time, it's kind of half and half, half are here in person during the week and the others are following remotely but you can contact them all on ‑‑ there's a contact form on the website or also send them an e‑mail, so you can find their contact detail on the website.

This is just ‑‑ you don't have to remember all these people but they are the people who are responsible for the Working Group sessions that I have mentioned earlier on on Tuesday and Wednesday and Thursday. Some of the Working Groups have selection processes going on for new co‑chairs this week, so at the end of the week you might see some new pictures and I am going to ask you to check the new pictures on the slide. But yeah, thanks to those we have an agendas for all the Working Groups during the week.

Then there's another group, that's the Programme Committee, that's responsible for the plenary talks, and then the Programme Committee Chair will have a more detailed presentation later on so I will skip down here.

Another highlight I think of the meeting is also the diversity and inclusion session, that's this time on Thursday afternoon, we have a number of lightning talks and a continuing discussion on how we can further, you know, increase diversity and make sure everybody feels included in our community. So I invite you to participate in that.

What would a RIPE meeting be without social events? There are a number of social events this week, one here on the site of the hotel in one of the buildings outside in the clubhouse where we will have some like, you know, some opportunity to see each other again and welcome the newcomers and have a good time, and then tomorrow there will be a social on the boat, where we will all go, go there by bus, and also on Thursday the traditional RIPE dinner is in a really beautiful venue that we all go to together on Thursday evening and you will find some more information on the website and also on your badges.

The meeting won't be possible without the sponsors, of course, so thanks to the sponsors and to the local host also, and I will also specifically, I don't have a slide here, I would specifically like to thank the RIPE meeting organisers and most notably Sander who took this over halfway through the organisation and then the whole meeting team has done a fantastic job to put this together, and so I hope you all have a great week and enjoy the RIPE meeting and I would like to hand over to Mauzizio Goretti who is going to give an introduction from the local host. So, Namex is our local host in Rome and he will tell you a bit more about that.


MAUZIZIO GORETTI: Thank you very much. Hello, everybody, welcome to Rome, I am the Namex CEO.

And who is the host this year? It is the local internet exchange point, Namex. This is a little bit of history. Some of us have been around for a while. This is my photo when I enter for the first time in the office, that was ‑‑ okay. Yes, we host ‑‑ we already was host in 2010. I have to skip this image because I look younger here so I have to skip this.

So today, we are not for profit neutral exchange point and we are an we are member‑based, that means our member count the same, even if they are big or small. Our main goal is not commercial, it's to provide useful services. We use a lot of the Roman Em(peer) communication stuff, so this slide shows we are growing a lot and we call ourselves the Roman Em(peer) and we have 232 connected ASs that show that we are growing.

We are, again, we use the Roman Em(peer) for our data centre places. Now we have problem. One of the next possible name is Nero, but Nero was the guy that burned Rome and for data centre is not the best name to give.

We are also present outside Rome, we are present in the south of Italy with a couple of regional exchange points ‑‑ yes, the drill is with us ‑‑ and we are present in nape else and we are also collaborating with the national network of Albania and we manage the local network exchange point.

How we use our profits because we have profits at the end of the year, yes, we invest in new equipment, infrastructure, stuff, people, but also training. We have this programme, it's been here some years now, very successful, at least it's very difficult to find very good training courses in our topics like BGP, MPLS, DNS. For this reason we organise courses, it's free courses for our members, last year we trained roughly 150 people, through the courses with final test. We also support projects, like mentioned just one, the keep Ukraine connected, because I think it was ‑‑ it was born here in the RIPE community.


Books: We published two books, and ‑‑ well, only two books so it's not so much but last one is about BGP, is the English version of and Italian version and two of the three authors are here at the RIPE meeting, one is Gavo, and Antonio Prado, and I think they are here in the audience.


Thank you so much.

So, we are eight people from Namex because it's ‑‑ we are the host, we have been around for the whole week, we have a desk at the entrance, if you have a problem with Roman taxi driver, too much money, whatever restaurant, we are there, so lets meet us over there.

The T‑shirts, I wear this T‑shirt, we did this T‑shirt, it's carbonara, request for comments is standard for the preparation of pasta ala carbonara.

And I hope that you will have your T‑shirt because we are going to have this afternoon a wonderful pasta BoF, it will be here in the hotel in the golf club that is the building close to the main one, so I hope to join you over there and thank you so much.


MIRJAM KUEHNE: Thanks. And next we will have from Ulka Athale the RIPE NCC who is going to talk a bit more about the meeting logistics and Meetecho and what the RIPE NCC is doing and give you an introduction to or an explanation how to vote for the NRO NC elections this week.

ULKA ATHALE: Thank you. So, good afternoon, everyone. And on behalf of all of my colleagues at the RIPE NCC, are a very warm welcome to RIPE 87.

In case you missed the newcomers introduction, let me just tell you who the RIPE NCC is and why I am standing here doing this. And the RIPE NCC was formalised in 1992 by the RIPE community. We are a membership organisation, it's run by RIPE NCC staff and we have an Executive Board, whom you can meet this evening at the pasta BoF, as well as the meet RIPE NCC Executive Board event, but more to the point for this presentation, we are the secretariat to the RIPE community and we are the meeting organisers. So let me walk you through some logistics.

We are using Meetecho as our platform for this event, for both online and on‑site participants. If you have already registered you have received the link to Meetecho. If you are in the room you have two links to Meetecho, one you can use through your laptop and a lighter version you can use through our phone. If you are following this through the live‑stream on the RIPE 87 website and you would like to participate, please keep in mind that you need to register for the meeting. If you are registering online it's free and then you will get a link to Meetecho.

Please note that we archive the sessions, are the video recordings and the chat and place it on our website.

If you are new to Meetecho and you would like to share your comments through audio or video, you can request the floor by clicking the mic icon or video, the session Chair will grant you the floor at the right comment and then you can make your moments. You can also use the Q&A to chat to ask your questions, sorry and please make sure you state your name and affiliation before making a comment or asking a question. You can also chat with other attendees and use the stenography and follow the stenography.

If you look at your badge booklets you have quite a lot of relevant information for the meeting in there. We have the floor plan for the ground floor, it's quite a confusing venue but you will get the hang of it, you do eventually figure out where the rooms are. There's one update, we have reassigned some of the rooms on the lower floor; the updated meeting plan, floor plan is on the website.

If you would like to go into Rome or to attend the social events you can take a shuttle bus that's arranged for all of you for free, and the timings are on the website. The timings are also up on the notice Board by the registration desk.

In case you are a bit camera shy and you prefer not to be photographed, you can go to the registration desk and ask for a yellow lanyard and our photographer will do their best to avoid photographing you. I would like to remind people who do like to take photos and videos to please be mindful of the people around them and their privacy wishes and to please respect everyone's choices in this regard.

I have quite a few staff members from the RIPE NCC. If you have any questions about the meeting organisation, you can go to the registration desk. If you have any issues with ID, the tech team will help you. For all members and all NCC related questions you can go to the NCC support desk and so on.

I also have quite a few colleagues who are here to collect feedback on our different services, some of whom are doing user testing, some want input for designing and training courses, you can see them on the slide and you will see them around the meeting venue. This is an invitation, please come talk to us and share your feedback.

With that, how am I doing on time? Great. In the interest of time I am going to say we are at the registration desk and at the RIPE NCC Services desk, so please come and find us there and I am going to move to my next presentation and catch my breath.

Great. I apologise in advance, this is some pretty serious admin but I would like to take you through this.

This is for the Number Resource Organisation Number Council which serves as the address‑supporting organisation Address Council, and we have an election at this RIPE meeting. There are three seats on the NRO NC, two of which are filled by‑election and one seat by an Executive Board appointment. We are having an election during RIPE 87 to fill the seat that for the term that was originally started by James Kennedy in January this year, but James has stepped down and we will fill James' seat with this election. There was also an Executive Board appointment and Erik Clemont has been appointed by the RIPE NCC Executive Board.

So for this election, we have three nominees, you can see their names on the slide. We have placed their bios, motivations and each of the candidates has submitted a video which you can watch on our website.

In order to be eligible, there are three criteria: You must have registered for RIPE 87, and to vote in the election you must check in for the meeting, even if you are an online attendee, ahead of the deadline, and you must have attended at least one of the previous eight RIPE meetings.

So, are if you forgot to register, to vote, you can go to the registration desk or go to your personal options page. Please note the deadline to register and to check in is tomorrow Tuesday 28th November at 2 p.m. If you have not checked in, please make sure you check in particularly for online attendees. If you are here in the room, the registration team should have checked you in when you picked up your batch, check the attendee list on RIPE 87, if there is a green tick mark next to your name, you have been checked in and you must have attended at least one of the previous eight RIPE meetings. If you are not eligible you should have received an e‑mail from the RIPE NCC, or you will very shortly receive one explaining that you are not eligible, and if you think you are eligible there's a link to a form and you can ask for a review and we will double‑check your information.

If you are not eligible at this RIPE meeting, we hold another NRO NC election two years out of every three, you might just be eligible next year.

The results will be announced during the closing plenary on Friday.

So, how do you vote?

You receive two e‑mails, one contains your personalised link, the other contains your one time voting PIN code. You need both.

All you have to do is click on "vote now", the link is personalised. When you click on the voting link, you will go to the voting platform, the voting code one is pre‑filled unless you are using Safari or a password manager and in that case you might need to copy and paste. This is what the e‑mail for one‑time PIN code looks like, it's not going to be 123456, that would not be a very good system, so you will need to copy and paste it. Here is what it's looks like. In this case Safari cooperated and it was pre‑filled, it doesn't always do this it, please be prepared to copy both voting codes into the right field. Once you have logged in, select the candidate of your choice, you can also choose to abstain. Click on " continue". And please make sure you click on "cast ballot" because your vote is only registered once you cast your ballot. And a reminder of the final timelines, and with that, I would like to wish our three nominees all the very best. And a reminder: Here is the link to their bios and videos and if you have any questions you can find me at the registration desk. Thank you.


MIRJAM KUEHNE: Thank you very much, Ulka. This sounds a little bit of admin and just to remind you this is really an important representation of our community, to the address supporting organisation within ICANN, it's not nothing, you might see this as not important but I think it's actually an important representation of the RIPE community. So thanks for explaining all this and I hope many of you will vote.

I will now hand over to Massimiliano Stucchi who is the Chair of the Programme Committee who will explain to you a little bit about what the Programme Committee does and who these people are and basically after that I will hand over to the Programme Committee to run the plenary from there on and you won't see me any more.


MASSIMILIANO STUCCHI: Good afternoon, everyone. I am Max from the Programme Committee. We are the little group that are responsible for compiling the programme. So what you see in the agenda has been ‑‑ has gone through a decision that has been taken by a group of people. What we do is we work with the presenters in some cases to improve the presentation or change some little details that the Programme Committee feels are not maybe appropriate for the audience, or we help the presenters go through the presentation again and look at it from a different point of view, so there's a little bit of work that goes behind what you see on the agenda. And then we prepare it, which also means juggling between people who say "I will not be here on Friday, so put me on a different day"; or someone who says "I will not be there on Monday." That takes a bit of juggling, and Jan is our juggler, king juggler. And what we do is also chair the plenary session. You see a clock there which is not aligned and I realised it this morning after I uploaded the slides that these are not really aligned, but that's okay, we will live with that. We will see somebody from the Programme Committee sitting in the front throughout almost the whole week and guide people with timing, and I see that Jan hasn't started the time for my presentation. There we go. Thank you, Jan. And this is what we do. We do it in the months before the event; we started early this time, the call for presentations went out early, it was a change from the previous years, it was decided at the end of the last meeting.
And who are we?

So please, stand up Jan and the other components of the Programme Committee, please stand up, see these people.


Now, you are clapping your hands but I want to see at the end of the weeks if you liked the agenda that we chose for you. But thank you for the ‑‑ thank you for clapping your hands. These people have put in some serious work. The role of the Chair is just to herd people towards taking decisions and we tend to do it collectively. So one of the goals of the Programme Committee for the next meeting, for example, that we decided is to try to be a bit more transparent because when you go through the statistics we have, we receive four different types of submissions:

Plenary talks, where we had 35 submissions and 15 were accepted. Some of them were taken and handed over to Working Groups because we felt they were too, maybe, specific as a topic for the plenary session. We received six submissions of BoFs, which you will see later today and tomorrow, and we accepted three of them.

Tutorials: 50% acceptance rate.

And then we have lightning talks, 12 submissions, and so far we have accepted five but there's an asterisk because we have two slots available for Friday. If you have an idea for a talk that is not 20 minutes, it's not 10, maybe something shorter than that, maybe have a chat with me, Jan, Brian, some other components of the Programme Committee, we can help you submit the idea and then we will take a decision, I think on Wednesday, usually we do it on Wednesday.

When you make a submission, and this is important for everyone, please include slides. One of the biggest issues we get is that we receive presentation proposals without slides, just with an idea, with a few words about it. And sometimes we see that the topic might be interesting but we can't see what the actual idea is behind the presentation and that gives us no way to evaluate it, so we tend to reject them pretty quickly. So, whenever you submit something, please include a little bit of slides.

Then, there are PC elections because we have terms, and we have two seats up, so if you think you want to be part of this group, the work is not that much, with only ‑‑ we have only done three meetings, three calls to decide the agenda for this event so it doesn't require live interaction, you can evaluate the talks in your own time, feel free to nominate yourself, you have time, until tomorrow, around this time. Voting takes place until Thursday and then Friday we will announce the results.

And then last: If you want to know more, let us know. Talk to the current members, check the charter but also send us an e‑mail, we are happy to answer any and all the questions we receive.

Having said this, Jan, it's time to get into the heart of our session today. So we have Romain Jacob. Romain is talking about how we think of networking a little bit different for the future to come.

ROMAIN JACOB: All right, thank you for the introduction and thank you everybody. So it's my opportunity to open this technical plenary and I would like to do that by starting with a question for you all:

So what do you think consumes most energy overall: data centres or telco networks? So think about that for a little bit and I want you to point, point this way for data centres and this way for telco networks. Be mindful of your neighbours. Don't be shy. The everybody is that everybody is cheating and showing both ways. It works much less than I thought it would work. Let's get the suspense, last year are estimates are slightly above for telco than data centres, the ballpark is slightly the same with a slight heads‑up for telco. How this evolved over time is interesting. If we look at seven years prior to this telco were already a bit ahead, and we see somewhat comparable improvement or increase in energy usage by both. What is more interesting in my opinion is the increase on use for work done by those systems. If you look at data centres, 300 plus percent, telco centres 600 percent increase in traffic. What does that really tell us? Both of those systems have significantly improved their energy efficiency in that time period. However it also tells us that this increase was not enough because the change in energy is still positive.

Now, here is the issue about this:

It is fairly easy to keep deploying additional network capacity and to build nor data centres, it is a lot harder to keep increasing the energy efficiency with which the systems operate. Here is what is unlikely to happen. If we going to keep doing those things and the total energy usage will keep increasing, and that is a problem because as of today, producing energy emits carbon even though there have been great up takes, move than half still come from carbon intensive sources. So this is why today I would like to pitch two ideas how we should make tomorrow's Internet more sustainable in order to reduce its carbon footprint and we will touch about two of the many ideas we have been discussing in my group since a while now, the energy usage while the network runs and its embedded footprint, the carbon ‑‑ well I will introduce that later.

So, let's start with the operational footprint.

Two decades ago, made this provocative claim that the Internet core consumes more energy per byte than wireless LAN and they made some rough calculation that showed con consuming quite a lot more, how can that be true? It's a combination of at least three facts. The first one is network devices are typically always on, okay?

The second is that network devices have an energy profile that is essentially independent of their load, that means you pay most of the power costs or the ‑‑ power costs to put the device on and as you keep loading in with more traffic the power does increase but not that much. Fine.

The issue with this profile is that network tends to be under‑utilised and that is kind of more of a feature than a bug, but they want to provision for peak traffic and they want to provide resiliency so that is from a good mindset. The problem we are spending most of our time operating in the least energy efficient region for most devices in our network.

Here is some example data from our partner at switch in Switzerland, if you look this, it's essentially all blue and green, that means utilisation below 20%. Other data sets show the same patterns, in France, 18% average over the two years of data we have looked at. So, essentially, you get the red curve for a typical network device and what you wanter energy efficiency is the proportional line. So how can we go from the red to more proportional line?

You can do that in essentially two ways. The first is to try to run your network more often at high utilisation regimes and the second is to try to reduce the low utilisation power usage. Ideally, you would do both.

The basic idea to do this is not rocket science, is turning things off when you don't need them, right? So, in router on a switch what could you turn off? The easy things are ports, eventually line cards if you are lucky, maybe entire devices but that seems a lot less likely to be possible but also things that are less obvious, if you partition your memory you don't need all of them and redundant power supplies and LEDs, as discussed at the last RIPE meeting. Things can be also less abrupt than on or off. You could consider reducing the rate at which you configure ports, you could maybe cache some very useful feed entries and turn off the rest of the memory for some time.

As I said, this is nothing new, academics have toyed with this ideas since 15 plus years and it was discussed by some of your colleagues six months ago at the last RIPE meeting. So what does the theory tells us? It tells us that we could save tens of energy percent in low utilisation networks. I will let that sink for a second, like two digits, multiple of them, if your average utilisation is below 30%, which we have seen to be fairly common in ISPs. How could you do this? Well, essentially the idea that was suggested by academics was to say if we tolerate a one time increase in delay of say 10 milliseconds for your traffic then you could buffer traffic for 10 milliseconds while you put it off, and you wake up in one millisecond and you send your burst of track and you will pay for the price for burst only once in your network so delay will be bonded for significant energy gains. The trick here is that this is theory, and theory does not align with practice.

So the key caveat is that as of today, if you take transceiver off, it will take seconds to turn it back on, right? So those are measurements that we have performed in the lab taking the transceiver we had and the routers we have, so but the ‑‑ are more likely to stay the same, whichever transceiver and device you take. So, essentially, the transceivers today are 1,000 times slower than we would need to do this buffer and save energy. Why am I mentioning this? Because I think we can still do these sort of things if we change a time scale. I showed this graph before and it should not be a surprising‑looking graph for many of you. We have strong daily patterns in most ISP networks means we have change and predictable change in capacity and traffic demand and between day and night‑time, it's fine to take 10, 15 seconds to turn something on and off.

We have been toying had this idea a bit in the lab and thinking how would we design a prototype protocol that would let us do this? You have essentially three questions that kind of you need answering to. How would you play with the control plane, the rest of the control plane so you don't trigger reconvergence all the time in order to use to put things to sleep and more importantly, to wake them back up, and what is the performance costs?

So, quick answer to those three questions. How do you play nice with routing, it's not that big of a deal. We are saying we cannot do this very fast, it's a couple of times a day, once or twice per hour, way faster than this, even if you do it in naive way. That's not really your problem any more for this sleeping use keys.

Which signal to use? We started with the simplest thing monitoring the link utilisation, which is already measured in many networks, and you can collect easily using standardised OSPF extensions. The more interesting is the third one: How much does that affect traffic? Essentially, not that much.

So, this graph here shows a number of TCP flows and when this start and when they end so we compare the same network in the same traffic demand on cases where we do and do not put links to sleep. So the green bars show the time the flows starts and end, where we have no impact when we do put things to sleep. And the bar stood red in the cases where some flow time is increased by the fact that we turn some things to sleep.

So there are two things to observe here. The first one is that we actually don't see a lot of red. There is some, it's there, but it's not that much, and it is located in time for ‑‑ or we observe some red parts where the flows would normally finish while the network is waking up. That means on those tiny portions of the time during the day where we would be waking up the network, it is possible to see some flow creation time increase. More importantly and what you don't see all that happens without any extra packet loss compared to the standard case with where you don't put anything to sleep. Why is that? Simply because congestion control is doing its thing. If we start building congestion. The congestion control protocols will scale back and take their share share and keep the network running. We are not in a link failure scenario, we are in a slowly increasing congestion scenario and we had to work hard to see those effects because in order to see that, you need to have just slight congestion event that are bad enough to see the increase but not so bad so that you would not have congestion if all your links were awake. So, it's actually quite subtle to make those things even happen.

In summary, playing this game, turning links to sleep at longer time scales is a traffic engineering problem. Slightly different objectives, it's not just about what flows goes where, but also about which links do we really need to serve those flows, and we have been solving those for a while and now how to do it within five minutes.

How comes the question: If we do this, how much can we really save? I am sorry to tell you that I cannot answer this question as of today because there are two key things we miss. We like measurement data and we like test cases. So, one key problem we are facing is that when you buy a switch or a router the data sheet will only tell you about the max power but as we discussed, the device is almost never used under full load so they don't consume the max power and often enough very far from this. So what is the typical power usage of a router? Well we don't really know. But we are trying to figure it out, right? So we are doing the simplest thing you could imagine: You take a power metre and put it between the power plug and supply unit and you apply different control loads and see what happens. We are starting building such models. They are pretty intuitive. They are combination of what we call static power, which is independent of the load but dependent on the device configuration. Then the traffic dependent part. And then things that are in direct consequence of the traffic: fan power and power conversion losses. The point here is we do have this approach of how we would model this so we can estimate the effective energy usage, but we need a common understanding of how we would initiate those models and that's part of the work we are doing with some IETF folks. We have an approach but don't have the devices which should be measured. What we have been working on is essentially a prototype box that we can send to you and then here is the Mac that needs access to the Internet, please plug this device in and we will start collating data that everybody can access. Eventually the vision we have is some sort of extension of RIPE Atlas or RIPEstat with power data we don't have currently have.

Second is that we lack test cases, I mean realistic ones. I showed this slide before that was maybe intricate and complex. It's complex because in simulation we can create anything we want, but what happens, what would happen in practice for that we need to know real network topology and traffic demands which we don't have.

So in summary, we can I think ‑‑ I think there are ways to improve the operational footprint of networks by putting things to sleep but we need your help in order to really quantify whether it's worth it to do it or not.

Now, shifting gear a little bit, I want to briefly mention something about embedded footprint of networks. The embedded carbon refers to the footprint of products in the rest of the lifecycle excluding their use phase. In consumer devices this tends to dominate the overall carbon footprint of a device. You can see here in dark, the embedded footprint versus the use phase. For network devices it typically tends to be the other way around, the use phase, the use phase operation or carbon emission dominates but this is not there are a bit of blocks or there is a bit of recycling. It is because they are on all the time and they operate all the time and least efficient operation point. Even though the bar looks small because there are far few user devices for more user devices that network devices, we have a real problem there as well in the embedded footprint.

How improve? It's pretty simple, keep using your device longer. When I made those first version a couple of years it was the standard standard three to five years at least for big, in big networks. I am glad to see since then it is starting to improve and people extend this, not always but still but you may wonder if we were to do this wouldn't the networks like less reliable and less secure or how did you manage? Not necessarily, I would argue. So, it is said that the vast majority of network hardware failure takes place in the first 30 days of installing new hardware. How could this be? It's a well understood thing and the reason is as shown on the graph here on the right side, the failure rate of a manufacturing product is a combination of three factors. On the red you see what is known as the burn in failures, that is essentially happen when you exercise a defect in manufacturing. Then, you have a plateau of random failures and eventually you have the wear out effects so the failures that come from ageing of the hardware.

But we argue that or we hypothesise it's going to start failing, we see two empirical evidence of this, the first is most vendors provides a five‑year window of any support for any devices that sell after they stop selling it. From day one they have at least seven to ten years of support window planned and other companies go even further and provide unlimited guarantees for refurbished hardware, hardware they bought secondhand, they are reselling and still confident it's not going to start failing. So we need to really understand better how network devices age. Essentially what we need to do is to get data so that we can plot those things and see where and when the ageing effect starts to appear.

And to do this, we need data that we don't have. We need data from the operators of the network. When do they rerun their hardwares? Why do you do it? Of course it's not about ageing, sometimes you need extra capacity and that's what drives buying your hardware. When? What type of figures have you seen in practice? Which failures are they? I don't have time to get into the last two points, so I want to wrap up this part. I think it is also possible to reduce the embedded footprint of networks. We have eight years of how to do this. It's simple. You should rerun only when you really need it, but it's quite hard to estimate when that is and we can help you trying to assess when it is really necessary.

In summary, we need your help in order to help your network. We need data, we need test cases for those energy‑saving ideas, we need access to measurement of devices in the network that you operate and we need better information about how networks are being managed, how hardware is being maintained and bought and replaced.

Academics have ideas, operators have the power to pay for at the end of the month and they have the power to change things in the network so I really, really think that we should be working together in order to make tomorrow's Internet more sustainable.


JAN ZORZ: Okay, thank you. I think we have two questions online.

MASSIMILIANO STUCCHI: We have three questions online. So, the first one is from Niall O'Reilly and it's: "Domestic networks are very numerous even if each consumes a small quantity of energy, I have a separate RCB for my home network equipment, is it worth considering instrumenting this?"

ROMAIN JACOB: The honest answer is I don't know. I'm not in the network operation and management business. It's really hard for me to understand what architecture, what infrastructure is really needed as of today. So, I don't want to make up an answer to which I don't know the answer to.

MASSIMILIANO STUCCHI: The next one is ‑‑

JAN ZORZ: I am cutting the queue, we don't have enough time.

MASSIMILIANO STUCCHI: Chris Buckridge: Curious Internet citizen. "Are device manufacturers currently prioritising the development of on‑off mechanisms, e.g. get closer to your theoretical predictions?"

ROMAIN JACOB: I certainly hope so. I have talked about manufacturers, chip manufacturers or assemblers and the feedback I got was like, it's hard to sell, it's complex numbers, it needs graphs because it's not just full load. So as of today, it seems still that the optimisation point, the selling point is we improve the efficiency and max power, but it's not in the slides but what you need to remember, when we start deploying 400 gig transceivers instead of 100 gig, it increases the power but also the energy efficiency because you can send so many bytes per second, but if you don't send them, you are losing.

BENEDIKT STOCKEBRAND: Two things. You want to distinguish between send and receive power consumption because from what other area I have been invovled with some time ago they have very different behaviour. You can turn off a sender but not receiver, it has all sorts of effects.

The other thing is, you want to make a distinction between a device failure and service failure. If you have proper redundancy, that's an important thing. I can run hardware until it falls apart and nobody cares except management because I can tell them we'll keep running that hardware and the life of them is like 3 or 5 years, but we run them for ten, so that means for the last three to seven years we make money out of it. That can really help until the hardware is obsolete. Other stuff is available, that really makes a difference and you sometimes get the management on your side but you have to build your stuff for that and not at the device level but at the service level at the very set‑up.

JAN ZORZ: In interests of time it, please be brief. Three minutes we have.

SPEAKER: Tim Wattenberg, DE‑CIX. Regarding your energy consumption model. I am not sure what exactly you are doing or trying to build obviously, but just to put it out, might it be interesting ‑‑ I mean, power consumption is metred already, we have to pay for it, does that data ‑‑ would that data help in any way as well, so would that be an option?

ROMAIN JACOB: Yes, it would help.

SPEAKER: Maria, developer of BIRD. I would like to ask whether you considered measuring IPv4 and IPv6 separately and notably, whether you were accounting for a CGNET consumption or the big IPv4 versus smaller IPv6 routing table?

ROMAIN JACOB: That's a good question. The answer is easy: We don't because we can't because doing this difference would require having more fine ring data that tells us what's in the packet header and we already struggle getting packet counter so going that level of granularity is beyond what we can dream of as of right now.

SPEAKER: Alexander: We are service provider and we are playing with some power‑saving criteria. First of all about this connection times, did it ‑‑ because we have times under second in with some tweaking so we may discuss this later. And we are ready to provide some power data if needed

ROMAIN JACOB: I would be happy to talk with you later.

SPEAKER: Janos Zsako from Hungary. I have a question. I understand you recommend somehow to use older equipment for a longer time which would be beneficial but my thought is that newer equipment has lower power usage. How do you compare these two things?

ROMAIN JACOB: I was starting to get desperate that somebody would mention this. You are totally right. That's something to take into account. Newer hardware comes with usually better efficiency, when you are making a decision of is it now worth to renew, it's not like a one‑off investment, you you need what you have to pay to old versus buying new, there are ways to quantify those things, not that hard, once you get a better understanding of what's embedded footprint and what is the operational footprint you can take those two things together and then you have a crossover point where now it's no longer worth it to keep running this old equipment because it consumes so much more and we should upgrade. This is what I meant to say was brief about rational update.

MASSIMILIANO STUCCHI: We have one comment from Rudolf van der Berg, who is on the same lines: "How do you explain that EU Telcos report increasing? In mobile networks the energy rises proportional with number of sites, and what do you think of DE‑CIX and AMS‑IX stating their new switches consume 50% and 95% less energy and that AMS‑IX used their gear for 12 years?"

ROMAIN JACOB: So, I will follow up with Rudolf because there are many discussion points to be had there, we need to differentiate fixed versus mobile networks. They are very different beasts and they behaviour differently, the energy efficiency has been improved because the end user device that takes a big part, patry powered, optimised, a lot more than core networks, they should not be combined and say mobile is so much better, it's kind of two different topics.

MASSIMILIANO STUCCHI: I guess it's something for the BoF.

ROMAIN JACOB: Yes, I hope to see many of you later tomorrow.


JAN ZORZ: So, should we talk about who we are as an RIR? Randy, should we? About the social contract. Thank you.

RANDY BUSH: So now we have the example of running on older equipment. Okay.

So, this is not going to be a technical academic talk. Going back thousands of years, there's the concept of the social contract and that's the idea of what's the relationship of we, the populous, with our governmental or political or whatever, organisations? And it's the question of the authority and legitimacy and communication and so on and so forth.

And so I ask ‑‑ I was ‑‑ people were trying to /TKPW* talk to me about the AFRINIC and the APNIC and the situation and I found myself not feeling that I was standing on ground I understood, because I didn't understand the model underneath it, so I thought about this for a while and I realised that what is the contract that we as the members, we as the operators and so on and so forth, have with the RIR system and with our other Internet organisational functions, what do we expect from them, what do they expect from us and who are we?

Surprise, I know this is different than you are thinking but RIPE is just not about IP allocation, and it's not because we are running out of it; it's because RIPE was formed for the cooperation of running the European ‑‑ coordinating the running of the European Internet, okay?

And here are our founders ‑‑ oops ‑‑ and Daniel is still here with us, I'm not sure who else is, I don't think so. But this is from the founding document, RIPE‑001, okay, you do not see allocation there, okay? The objective is to ensure administrative and technical coordination between the operators who are actually running the networks, and the basic concept under this is that we all feel the same, and I am going to use the same physics, we are all conscious of the speed of light, we are all conscious of the power our devices are consuming or more becoming that, right? We are conscious of allocating resources, of coordinating between us, of keeping traffic local, etc., okay? So, how do we coordinate this? Okay?

So RIPE is the forum for the exchange and it's promoting the coordination and the agreements and the services, okay? Nowhere in RIPE 001 is IP allocation mentioned. What it really was is that it set up the NCC as the secretariat of the community. The NCC's part of the community, but it is the community operational function, they don't operate the network, they operate the agreements, okay? And what this talk isn't about, isn't about the bureaucracy, it isn't about ICP 2 and that's the document that says how registries are created and it's not ‑‑ it's not that that is not important, it is that these are the thoughts that occurred to me as I wanted to think about these things and what I had to put under it. Okay?

So, the bureaucratic contract should derive from and be based on the social contract so I wanted to first understand the social contract and that's what this talk is about. And what do we expect from the RIR system, but who are we? And it's not just us geeks or us sellers of IP address space or even our direct customers and users; it's civil society, the governments and our great‑grandchildren, if the climate doesn't wipe them out.

So, there's a basic ‑‑ in the late eighties I think or about 1990, I saw, on the side of a bus, and I said, uh oh, we are in trouble, they have found us. And in the long run they are going to want a stake, and the Internet has become critical infrastructure. The government and civil society will play more and more of a role, and they have to, because what we have built is critical, okay? And they are justifiably worried and they are responsible, right? Routing security isn't just an interesting thing for silly people like me, right? Your government is scared as hell, and they are right to be, but just as we formed the RIPE community because we felt of common physics and we perceive the same technical and operational problems in the network and we have a common goal, those packets have to move, okay, the BGP has to work, all the way from ‑‑ well, maybe not Los Angeles, from San Francisco to Moscow, right? Just as that has to work, we have common goals, common language, common understanding, our governments don't. Our governments, damn them, are at high tension with each other. So government is not monolithic, right? It's a bit more better here, where you have cooperation of many national governments, the rest of the world tends not to be this way.

So, when we talk about dealing with the government and it's not dealing in an adversarial role, we are responsible for understanding their perspective of need, educating them as to what is technically achievable, and the problem is that there is no government we can talk to. Each of us have our own ‑‑ well, not this many governments, but close ‑‑ we each have to go home and help our governments, okay? And it's going to get more and more serious, the governments have a role to play, and instead of it's us and them, it's we are in this together, we are one humanity and so and see John Curran's NANOG talk on governance, but one of the attributes that I want to discuss that we as the community want from just our own level, from RIPE and from the RIRs, and I am going to discuss these various pieces a little more quickly, I hope.

Okay. We want fairness and openness, okay? RIPE is pretty good, but ARIN has been very bad but is improving. When I first looked at these numbers like ten years ago, ARIN had 17% of the resource holders were members, 17%, that's horrifying, okay? They are now 40% and 60 ‑‑ 67% of the address space and what happened was, an adversarial lawyer, what we call in America, litigators, people who go to court and fight, with the lawyer they have, instead of problem‑solving lawyers. There are two flavours of lawyers. Somewhere in this room is Athina and she is a problem and her team are problem‑solving lawyers, listen to them. So until very recently, APNIC and and I have conflicting input on this, was actually not a really open membership organisation, okay?

We want ‑‑

SPEAKER: I am a man!

RANDY BUSH: We won't ask you to prove it here. We want transparency, but in terms of finance, in terms of policy, and in terms of decision‑making, okay?

We want civility, brief it or not, I'm a known trouble maker so to try to keep me from making trouble they put me on this Code of Conduct committee so I have to try to be civil and it's how we treat each other and how we treat others outside. So, we kind of expect, nowadays, it's modern, but five years ago, and even just a few years ago, the idea of a Code of Conduct and how we deal with it, was socially difficult in our culture, and still people, today, worry about the ‑‑ that it's the thought police and I assure you as somebody working inside the committee, it's not. We'd rather not have any issues and not do anything, so be nice out there, so we don't have to; we are lazy, help us.


We want diversity. Gender, race, religion, etc., etc., I want diversity of opinion, we don't have to agree, we have to discuss civilly, but we don't have to agree. If we all agreed it would be very boring, we could do it with computers, right?

So, the thing is to be constructive. We want representation, but ‑‑ and this word "stakeholders" has turned funny on us, the people playing at layer 10, but operators have the different flavours, academic versus commercial, the education sector, the government, the users, civil society, all these things should be represented well in our culture.

We expect competence. We want, especially the pressures on the NCC, to operate efficiently, correctly. One of the hot buttons for me, and I have spoken about this for 20 years, is inter‑IRR, interoperability, why do the five IRRs if you are a big network, you have to deal differently with each one?

And this last slide to me is just a hot button and a joke: Why do I need a course to use the RIR's product? If I were a commercial service, if I had to give a course in how to buy and use my product, I wouldn't be in business very long, right? A monopoly has the luxury of being confusing but maybe some efficiency could be gained by making it a little easier to use, okay?

We want the governance to be representative of us, but not just the meetings and the general thingy, you know, to be able to go to the membership meeting and vote and stuff like that, but across the boards and committees, right? This is part of the transparency thing, that I want to ‑‑ I am on the Code of Conduct team. If you have input to how we are perceived, how we should be organised and how we should act, please tell us; we really ‑‑ we have two ears and one mouth. Okay?

So, we, as a community, and we expect of the RIR, to act in a social responsible fashion, right?

And this, I think, is being perceived more and more than it was 20 years ago, and this is good, okay? We just had a talk on sustainability, deconialisation is a hot button of mine, but ethics and justice are also important, okay?

We have a community that feels a common physics, as I said. We are the stewards of a critical resource. We have different sub‑cultures, we have the DNS Kebal, we have the BGP people, we have ‑‑ I confess ‑‑ we have the security people, to which I also confess, etc. But there's a Venn diagram of this and, at the operational level, we are cooperative, but this weird incident happened 20‑something years ago at ICANN, is when it was founded, it was driven by adversarial lawyers, and so it is, in its cultural base, competition and conflict between the different constituencies. This is badly broken. We should not fall into that trap here, right? We are all dealing with the same common physics, we are all responsible for running a service and an Internet for the world and we have to cooperate to do it, not because we are forced to, though there is the force, but because we perceive a common problem and a common physics and we cooperate every day to make it work, okay?

I want the RIRs to also be capture‑resistant and we have had some failures, and you know, AFRINIC is notorious and unfortunate but just as an example, ARIN was, again, had an adversarial lawyer at its founding and had barriers placed. In ARIN, you couldn't run for Board election unless the nominating committee approved you and they didn't approve everybody. There was three or four years in ARIN where, unless you were Canadian and liked Poutine you couldn't get on the board, okay?

And APNIC has had its problems. AFRINIC of course is notorious, but so when we think of the RIPE NCC executive committee, we should think of having it be diverse, having it be representative and be capture‑resistant.

Okay, we do this survey every year to, I don't know why, somewhere probably as a child I was thought to hate surveys. But how we evaluate and look at ourselves and how we hold up a mirror to ourselves, I think is important, and maybe we can be a little more creative in that area.

We do think the community should be nonprofit and financially transparent, okay? We should be prudent and not fancy. Maybe we should stop holding the dinners at castles right? Maybe we don't need so much marketing literature to sell us on the NCC. I mean it is a monopoly, they don't have to market to us, we don't have a choice but to use them. So, when we sit here and we complain about how expensive it is and oh, the fee structure and all that, well maybe we should ask for less fancy, maybe we shouldn't ask for all the free booze, maybe we shouldn't ask for castles, but we should ask for coffee. And maybe we need a coffee task force or something to have stability in this area.

And I am sure you have some other feelings and ideas too, and I'd be interested in hearing them, and so would other people here, especially people like my friend Mirjam.

But let's not reinvent the world and discuss the same thing again and let's not empire‑build, gate‑keep and all these nasty things.

So what do you do if you care about this stuff? Who do you call? This is one forum. The RIRs. The ASO, which is likely to be drafting a new policy, okay? And I will confess that I believe that when I talked about dealing with the governments, we have had, for years, some people who are in our governments within the RIPE community. We should be using them to deal with this stuff; they are ‑‑ actually, I move packets; they move policy, strategy, etc. So I nominated a government person for the ASO election because that's how I felt.

So, we have reached the end.


JAN ZORZ: Thank you, Randy, this was refreshing.

RANDY BUSH: No extra charge.

JAN ZORZ: No extra charge, thank you. Okay. Do we have anyone online?


JAN ZORZ: Rudiger is in the queue but let's go to the mic first.

RANDY BUSH: Let's hold a task force on how to choose from the queue.

JAN ZORZ: We have three queues now... four.

SPEAKER: Erik Clermont, chair of the ISO address. Thank you, Randy, to have given this view of our system of Internet governance system, etc., very, very interesting, and so you mentioned the ASO. The ASO is comprised of two legs so the ASO Address Council, first ‑‑

MASSIMILIANO STUCCHI: We can't hear you here.

SPEAKER: And so just for information. So you mentioned the ICP 2 which defines criteria for the creation of a new regional address registry and we were asked by John Curran who is Chair of the ‑‑ so the group of the four CEOs of the region, to work on that, so to implement these criteria, but we don't know how to use it for the creation and the ongoing activities of regional registry first.

And then, it's another task, longer, perhaps, to strengthen the ICP 2. So I suppose the first task, the NRO NC will give us guidance etc. And we will see in 2024 how we will work on that. Thank you.

RANDY BUSH: I have been a frenemy of John Curran for 30 ‑‑ more than 30 years. I would only have one difference with what you said. It is not just John Curran, it is we, the community, who ask you, as the ASO, to deal with making the RIR documents more current and modern.

SPEAKER: Of course I have absolutely no problem, so the mail came from John Curran per se but of course there will be ongoing discussion with the community in 2024 which will be ‑‑ no problem with that.

RANDY BUSH: No, no, and power to you.

SPEAKER: Thank you.

JAN ZORZ: We are cutting the queue.

SPEAKER: I have been to ARIN NOMCOM and I can confirm the statement you have to be allowed to be voted on, it's a bit of the Kebal and I have been on the NRO NC and I would say there were just 15 people and I don't think this delegates should be the only ones being the only people making such a decision and I do agree maybe it is a bit too harsh, but see, I got this T‑shirt from ICANN not because I like ICANN, because it's cold outside, I would say we don't need a hand‑me‑down from ICANN to give us a new policy and new guidance but we should start and I agree with you.

Now, as of the dissolution of RIR because it was very specifically, did you have something in mind or just an idea that it is good to have a way to create things as well as destroy them? I just wanted to point this out. Thanks for your statement, though. What do you think the next step should be after this great presentation is ‑‑

RANDY BUSH: I think the next step is, for me, personally, is I am now ‑‑ now that I have some feeling about how our culture works is to think about what I want for ICT P 3. I do not have a problem with ICANN or the ASO because if I feel that they are acting in other than our best interest, I will tell them, and I will act, and until then whining about them being there, doesn't get me anything.

JAN ZORZ: I know we will cut into the break but please be brief.

MASSIMILIANO STUCCHI: A comment online from Maria: "We, as a community, shall congratulate ourselves for delivering a product everybody really needs. I would call it great success. There comes a lot of responsibility with that power indeed and I'm happy that we are opening, discussing and moving the social responsibility topics. Thank you. Anyway, do you think that it's enough what we do?"

RANDY BUSH: I always think there's more work to do, I am a workaholic.

MASSIMILIANO STUCCHI: I would say let's go from one to another. We are running into the break.

RUEDIGER VOLK: Sure. One short, simple question regarding your pointers to transparency, is the fact that the members' meeting is essentially closed to a certain group, fitting your transparency demands.

RANDY BUSH: Interesting point.

SANDER STEFFANN: I am an NRO NC member. And as I said, NRO NC performs the function of the ASO‑AC which is the ICANN function, so yeah, the feedback I got, first of all I want to thank Randy a lot because while this ASO AC is very close to ICANN, I am starting to see all the politics and all the bureaucracy going on there and I am rushing really hard to make sure this is a bottomup process, so the others by the way, I am not taking credit here. But it's really important that this ‑‑ the discussion you started here has to be the foundation of whatever happens to IC approximate 2 and all the work we do. So thank you very much. If anybody has any feedback, there's a couple of NRO NC people here in the room, please contact us because your input is crucial in this. Thank you.

Tobias: Speaking for myself. I would like to challenge your point that we need blanket more ability to disagree because I think we also need strong values and framework for things where there is no opinions and no disagreement on, and where there cannot be multiple positions, which is personal freedom, like diversity, accepting everyone as they are and like being a place where people can be themselves. Things that are often also ensured by the Code of Conduct we do have in place, but I think that is needed as an additional framework to ensure that on matters where one can have different positions, we can actually do that as you propose.

SPEAKER: From University of London. I think you are spot on on quite a few of the things you say, in particular how to engage stakeholders including government and civil society and I would like to hear more about it. I was at the Internet global forum and I say one guy in a T‑shirt, he was from RIPE, there were many people in suits and I haven't seen many suits here, those were from the government. Very ‑‑ very difficult and complicated and I was telling them it's open, all the, at the they will me open doesn't many transparent, doesn't mean we can understand what the heck you are doing.

RANDY BUSH: We are not doing a good job educating, we are really not. And part of it is, indeed it's a little complex and part of it is we are not trained as educators. So, I think we need to step up there. But I think that is why, I think, we should put more weight on the people who come from the upper layers, who are already in our community and do understand it and do have an ear for the technology, but also understand the governmental side to use them to make the transition and I think this interface between us, civil society, the government and humanity, is going to become more and more critical and more and more work over the next few years if they don't bull us all up in the meantime.

JAN ZORZ: Okay. Thank you.



Before we go into the break, Jan, there's one last thing we need to do. We have to take a selfie.

(Coffee break)