RIPE 91
20th October 2025
Main hall
Opening Plenary session
2 p.m.
.
MIRJAM KUHNE: Welcome, come in. I just noticed that we got our lift music back. I know a lot of you missed our, you know, intermission lift music over the last few meetings but after popular demands, apparently it's back:
.
Welcome to RIPE 91. I am Mirjam Kuhne, I am the Chair of the RIPE community and will see we have two Vice‑Chairs this week. We have Niall O'Reilly, Vice‑Chair, until Thursday. And then we also have Anna Wilson here who is going to be the Vice‑Chair. (Applause) As of this meeting, we'll be doing a proper handover ceremony on Thursday.
NIALL O'REILLY: You'll notice that the Irish mafia is still in control.
STENOGRAPHER: Yeah, go on the Paddies!!!
MIRJAM KUHNE: Let's dive into it. People are still coming in, but please find your seat, we have a packed agenda so I want to start. As of now we have 322 people checked in here. I saw a lot of people online also doing the newcomers session which is great. We have people from 48 countries at the moment, and quite a big delegation from Romania, which is fantastic, that's why we are coming to your country so, to allow you to participate.
And we have, this time, one local hub in Poland, we always promoting local hubs and the RIPE NCC is also helping, we have facilitated. So if you are interested next time to get together in your country, maybe in Romania next time, have a local hub to participate in the RIPE meetings together but remotely, I'd be happy to help you out there.
As I said, we have been here before before ten years ago, 20 meetings ago in this exact hotel. The church wasn't there then, I remember, when I looked out of the window there was this big square and then the palace on the other side, now there is a beautiful church.
We have looked at the minutes of the meeting reports from back then, we found a few nuggets there. You see there on the ‑‑ you can't see it really, but on the slide on top, the then RIPE Chair presenting understand standing there where I'm standing now, that was Hans Petter, and at the bottom, we have elections for the NRO numbers Council, we were still using paper ballots and a paper box at the time. We also are going to have an NRO NC elections this time, it's got a bit more sophisticated, we have a presentation later on to explain to you how to vote.
Then we had a few quotes there, there was actually a discussion how to move forward with the IPv6‑only network during RIPE meetings.
So, it was considered the most important goal.
Then also Geoff Huston was here, and gave a typically entertaining presentation and at the time he predicted that we won't have more than five laptops in the room by 2020 because everybody is going to be in other portable devices. I still see quite a number of laptops in here. But it's also fun to look back at people predicting the future.
So, we have a Code of Conduct, as you know. You can find it online. The bottom line is we treat each other with respect. You can find the details online.
We have a great Code of Conduct team here on site. I am happy to report that we also have new members on the team. I am always very pleased to see people volunteering for this important community task. So they are going to be here in the corridors. They have also a separate room, you'll find them there, and also online and by e‑mail.
The RIPE Code of Conduct team also issued a survey. They wrote a RIPE Labs article some time ago with a link to a survey and they would really like to hear from you, especially if you want to report something, or maybe if you don't report, why don't you report something, what you feel is your voice there and for the Code of Conduct team. Also, if you are a newcomer to this meeting we would also like to hear from you but maybe at the end of the meeting, so after you have had the experience for one meeting at least but we'd definitely like to hear your voice as well. Please don't be shy. I think the Code of Conduct team would really like to hear your experience in this community.
Some more faces here. This is the Programme Committee for this meeting, they are responsible for the Plenary programme. I think they put together a fantastic programme. It's going to start after this Opening Plenary, diving into some technical talks there. It's going on throughout the week. They are, I think I have a slide on that, there are elections also for the Programme Committee, so if you are interested in that, please go talk to any of those friendly faces you see on the slides.
More faces: You are not going to see them all, recognise them all. But these are all the Working Group Chairs for this meeting. There are some Working Groups will have elections going on at the moment, so, by the end of the week this might have changed slightly. But those people are responsible for the content and of course you are responsible telling the RIPE Working Group Chairs what you like to discuss in these Working Groups.
I am coming to sad news. I don't know, not many of you will remember Stefano Trumpy, but he died earlier this month, and most relevant for us in this community is actually that Stefano was a Chair of the, of EARN, which was the European academic and research network here in this region very early on, they then later merged with RIR, the Alto academic association and became TERENA and Stefano was on the Board there and was very supportive of setting up the RIPE NCC and he urged the academic community also to tribute financially to the RIPE NCC, so he was a big supporter of us, especially early on. So those of you who remember him, it's sad sad news that he died.
Another person who most of you probably do know, and as our community will also we found that he died earlier this month, is Fergus McKay, who was actually at the last RIPE meeting in Lisbon and then we heard like a few weeks ago that he died suddenly, so, he was very active in this community. He has been a working group Chair for many years, and he was also a very supportive or specifically of local network operators group all over the world. It's very sad to hear that he passed away. We have a book and a photo there for Fergus on the registration desk if you would like to leave a memory or some words that you remember about Fergus and we'll give that book to his family and friends after the meeting.
So it's hard to move on from this to the daily business.
As I mentioned earlier, we do have a number of elections, RIPE governance related topics this week. Theres a Programme Committee elections, two seats I think, and they are looking for candidates. If you are interested, please think about it and talk to them, and maybe find out what the task entails.
There are some Working Group Chairs selections as I mentioned. They will be announcing the results during their sessions. The NRO NC elections, we'll get to that in more detail. There is also a consultation later on in the BoF here today about the second version of this RIR governance document, or also called the ICP 2 in our ++ document, it's important for us as a community to also provide feedback there and make sure we'll get the RIR system that we need. So, they have another BoF to tell you about the second document.
As mentioned earlier, we'll have a handover session on Thursday, this meeting is the transition handover meeting from one RIPE Chair team to the next RIPE Chair team.
This is the meeting plan. You have all seen it online or in your app, there is, there are a couple of changes. The Address Policy Working Group is meeting on Thursday instead of Wednesday today. They'll have one BoF today and two BoFs on Thursday. The rest I think is pretty much the same.
As I said today just now, this is the BoF that we have today. So, it's important to follow that. Then we'll have two BoFs on Thursday, one more technical about DNS encryption, and then one more a strategic and that's the RIPE NCC organises this one and that's really important also, not only for the membership but also for us as a community to provide input to the RIPE NCC's strategy plan over the next five years, they would like to hear from us all.
Then tomorrow afternoon, we'll have again a diversity session, this timed chaired by Dinesh and we'll have some interesting talks there. Over the last few meetings I think we had some really widespread of focusing on various aspects of diversity and relevant to our industry, we'll have this time again lined up a number of interesting speakers and topics.
Last but not least of course, this wouldn't be a meeting without long enough coffee breaks, our former RIPE Chair also mentioned it's a feature, you have long coffee breaks and lunch breaks and social events where you talk to each other, get to know each other better. We have a welcome reception today, and then the networking social tomorrow, please bring your badge, other than that it's for free. It's hosted by the local host here in Romania. Then on Thursday we have the traditional dinner, there you will have to buy a ticket.
Then at the end, we couldn't do this without our sponsors. So I would like to thank our host InterLAN, and RIPE NCC as a diamond sponsor, the AWS as platinum sponsors and all the other sponsors who are helping us to put up the network here and organise the meeting. So a big applause.
(Applause) With that, that's my short opening and I have been told there would be a surprise by the local host now, so I'll make space.
.
(Applause)
.
MIRJAM KUHNE: Thank you so much. That was something different for a RIPE meeting. So... well maybe an Inns separation for the next host, who knows. Would I like to ask Erik who represents the local host InterLAN IXP to say a few words.
ERIC ANDREI BALEANU: Thank you Mirjam. I am Erik from InterLAN Internet Exchange, we're the host and we are welcoming you back in Bucharest after ten years. If you remember, we had the RIPE 71 here in Romania and now after ten years we have RIPE 91.
Bucharest is what it was first attested in 1459. It's a city of more than 2 million population. It's almost ten percent of the population of Romania. And it's also the eighth city in European Union in terms of number of population. And also it shares 25% of the Romanian economy.
And also Bucharest is, according in September 2025, it's the fifth city in the world for fixed broadband speeds. So we have a very fast connection Internet connection here.
InterLAN association is an association of Romanian Internet service providers. It was founded in 2005. It's a not‑for‑profit organisation. Its mission to promote collaboration, knowledge sharing and Internet infrastructure development in Romania. We have 55 members, Internet service providers based in Romania. Local Internet service providers and also the InterLAN association operates the Internet Exchange which is the largest Internet exchange platform.
InterLAN Internet Exchange has 140 networks connected out of which 90 networks are from Romania. Or local ASNs. It operates a distributed infrastructure across 15 points of presence in major Romanian cities and of course in Bucharest and the most important city in Romania and also we have two international points of present in Frankfurt and Sophia. One the most important services in our Internet Exchange platform is the TV exchange services which allows TV channels to deliver their streams.
We also have six DNS root server instances in the InterLAN Internet Exchange, and recently we implemented M root and M root node, which is the second M root node in Europe after Paris.
Of course we have route collectors and the auto DNS servers from the RIPE NCC.
Our daily traffic is 800 gigabits and we have ports very large range of ports available starting 1G, up to 400G.
This is our team here at RIPE 91. I will ask my colleagues to stand up so... please, my colleagues...
.
(Applause)
So, if you need anything, if you want to ask anything about the Romanian market, about the InterLAN, about Bucharest, about Romania, you can find them here at the RIPE meeting.
This was my short presentation. Thank you very much and enjoy.
(Applause)
MIRJAM KUHNE: Thank you. Next up we'll have a presentation by Hans Petter Holen the Managing Director of the RIPE NCC who is the diamond sponsor, I believe, of this meeting and also Hans Petter is going to explain some of the logistics for the meeting here.
HANS PETTER HOLEN: Thank you very much. For those that wonder diamond sponsor it means we pick up the rest of the bill.
I am Hans Petter Holen, Managing Director or CEO, if you want, of the RIPE NCC. Ten years ago I stood here as RIPE Chair, but five years ago I was convinced to take this job. So, there you go.
RIPE community as Mirjam is sharing was formed in 1989 to solve all problems of the Internet in Europe and they required a couple of meetings for that. We are still going on 91 meetings later.
Then RIPE NCC was set up as a secretariat for the community, a membership organisation run by RIPE NCC staff and an Executive Board. And we provide services and we implement policies.
So, since I am here I am expected to tell you about the logistics for the meetings. If you are remote, you also know that you use Meetecho or you can watch the live stream. If you are in the room you may also want to use Meetecho, on the phone so that you can get yourself in line or see the chat or the questions and so on. So that's a very useful way to interact even if you are in the room. And all the sessions will be recorded and posted publically afterwards.
If you have the Meetecho interface in front of you here is the queues that you need to know, the icons for audio and video queue, if you want to speak, the Q&A or the chat or the stenography. So we have stenographers here as well, and sometimes they also write down what I should have said not only what I say. So that can sometimes be interesting.
Your badge is important. If you wonder what the wi‑fi password is and other things. It's on the back here. Have a look at that. There are QR codes there as well.
Photography and yellow lanyards. There is a photographer, I think he is following me in particular this time, so if you don't want to get your picture taken, don't stand next to me. Or put on a yellow lanyard, then he will try to respect your privacy and we will definitely not publish your picture.
Meeting support, there is a meeting organisation, there is a tech team, a support desk. You can get your registry checked by an assisted registry check and please talk to any RIPE staff, you can recognise us by the black lanyard.
And you can also take a professional, certified professionals exam if you want to. We have the facilities to do that here.
Or, participate in our user testing, because we know before we implement stuff actually bringing it here so that you can have a look at the ideas we have and gave feedback on the prototypes before we put them in production.
RIPE NCC: Speak to us. You can see the pictures here of my colleagues, Leah, Pedro, Antonella, Stephen, Fallon and Adonis. As I mentioned, you can hear come and give feedback on the academy, assisted registry checks, ASPA, registry portal and RIPE Atlas.
General Meeting: There is also a members meeting here on Wednesday. You need to register specifically for that one because only members get in. So you can do that in the LIR portal. And then you need to pick up a special badge that you get on your name tag to be let in. If you don't register and don't have one, you will not be let in.
Strategy: Will we are working on a next five year strategy from '27 to '31. It's still being discussed. Please join the BoF on Thursday to discuss what we have published so far and there is a survey. Please take the survey so I expect everybody to take out their phones now and take this QR code. Nobody is listening to me today. It's not a malicious link, I promise.
30 years of training we will celebrate 30 years of training here at RIPE 91. Our first training course was in 95, ‑ actually, it's my 30 years anniversary as a participant in RIPE meetings as well by accident. So...
.
Thanks to everybody, there will be a celebration then on Thursday.
Any questions or comments? I don't think we have time to do that now because you want to see the next presentation, right?
.
(Applause)
MIRJAM KUHNE: There is always time for questions of course. I don't see anyone... no. So next up, we will have another presentation by Ulka from the RIPE NCC communications staff about the NRO NC elections that I mentioned earlier.
ULKA ATHALE: Hi everyone. My name is Ulka, I am part of the RIPE NCC communications team. This is a highly adminstrative presentation, apologies in advance.
.
The NRO NC stands for the number resource organisation Number Council which serves as the Address Supporting Organisation Address Council at ICANN. (There might be a quiz)
.
We have three members, two is elected, one is appointed by the RIPE NCC Executive Board.
The election we're having here is to fill one seat for a three‑year term starting in January '26 and ending in December 2028. We have three representatives currently, Herve, who is appointed by the Board, Constanze Burger, Ondrej Robachevsky, they are in the room here. And it's Constanze's seat that's up for election.
We have three candidates running in this election. Constanze, Alexander Timokhin and Tiago Felipe Goncalves. You can find the information about the people. They have made videos.
In order to be eligible to vote, there are some criteria. We updated these a couple of years ago. You need to have registered for RIPE 91 and selected the option to vote in the NRO NC election. Additionally, you need to have attended any one out of the previous eight RIPE meetings. So not regional meetings or general meetings, but specifically RIPE meetings. And by attended we mean you must have registered and checked in even if you have an online participant. For this election it's RIPE 83 to RIPE 90. Additionally, you had to check in for RIPE 91 before the deadline.
If you have forgotten to register to vote, if you are on site you can go to the registration desk. You can also do exactly what the online participants can do, which is to use your personal options link you received it this morning in the e‑mail from the meeting team, and select the option to vote in the election, and if you are participating online, please remember to click on the check in button, you will automatically be disqualified if you have not been checked in. I am repeating this a lot because that's typically what people forget.
You can go to the desk. How do you know you have been checked in, go to the attendee list. If you see the green tick mark next to your name, you have been checked in. This is normally done when you are handed your badge but please double‑check, and if you don't see the tick mark you might not be checked in. If you are not eligible to vote, you get an e‑mail from the election team informing you that you are not eligible. If you think we have made a mistake, you can ask for a review using the form. The review team reviews your information and we'll send you the decision. The deadline to request a review is Wednesday 22nd October UTC plus 3 at local time Bucharest.
Voting is simple. You receive two e‑mails from assembly voting. One contains your voting code 1, which should be pre‑filled unless you are using Safari and the other contains your one time pin code. You need both codes. You select and CA date of your choice and submit your vote. If you abstain, we count that ‑‑ we count you as a voter but your vote doesn't count. But that I mean your vote doesn't count towards the result.
This is what the first e‑mail looks like. Click on vote now. This is what the second e‑mail looks like with your voter code. It will not be that. Please copy, paste that in. If you are on Safari, I repeat you may need to copy voting code 1 as well.
There are three candidates. Select the candidate of your choice, or you can also choose to abstain. The platform also allows you to verify that your vote has been registered accurately.
Some deadlines because it's not administration if you don't have deadlines. We'd be doing it wrong.
Tuesday, that's tomorrow, at 2 p.m., 1400 UTC plus 3, that's the deadline to register to vote. That's also the deadline to check in to be eligible to vote. Voting opens tomorrow at 5 p.m. And voting closes on Friday at 9 a.m. And the results will be announced in the Closing Plenary.
If you need help, my colleague Boris is supporting the election online, you can send and e‑mail to nominations@ripe.net. It's confusing Ulka and Ilkay but we are both here and if you need any help, the registration desk will find me and I'll come to the desk and help you out.
And that's it. If you are celebrating the Devali this week, a very happy Devali to you. Thank you.
(Applause)
MIRJAM KUHNE: Thank you Ulka. And last but not least, as part of this opening presentation, opening session, we'll have Max Stucchi the Chair of the Programme Committee who is going to present to you something about the Programme Committee and also then take it over straight away into the PC owned Plenary session.
MASSIMILLIANO STUCCHI: Thank you Mirjam. So, good afternoon everyone. I am Max from the RIPE Programme Committee. I am chairing it. What do we do? We basically get submissions, we review them and we prepare the agenda based on that. So, we not only recently, not only we look at what's incoming and review it and give it a yes or no, but we also tart providing small reviews for people to understand what they could improve in their presentation. So based on that, then we prepare the agenda, we Chair the sessions. You will see some of the members of the Programme Committee chairing the sessions during the week. And we make sure everything runs on time. Or we at least try for it because we are actually late now in the agenda. But that's fine, we can live with that.
So, who is on the RIPE PC? Mirjam already presented this, so there is a different order here. The change from previous meetings, actually from the last presentation I did which was two meetings ago is that we now have a different MENOG representative, which is Osama, and I would ask Osama to stand, together with the rest of the PC members that are here.
(Members stand up)
.
We have a new member also, thank you everyone. We have a new member, Amadeo, who is not here, he will be here later in the week. The rest are members that have been on for a few meetings as well.
We have two seats that are open for election. I'll say it later as well, but keep in mind your picture could be here in one of the next meetings.
So, what are the acceptance rates for the talks? We have, you can see for the Plenary talks we have about 50%. We had 31 submissions and we accepted 15, because that's the number of slots we have available. Four submissions for BoFs and we accepted three. Just one of them was suggested that it would be integrated into another BoF as part of it because the two topics overlapped. And then tutorials, we only had two submissions, one is the one you saw this morning. And then for lightning talks we had eight submissions and so far we have accepted three, although this is a reminder for the Programme Committee members to go and rate those that have been submitted recently. The five that are still in the not accepted stage to give us more data to do that.
And it should be in the end we have nine slots for lightning talks, so there is still space and that's why there is an asterisk next to it.
Lightning talks, we are still accepting them until Wednesday, so if you have an idea for a talk that's about seven minutes, with three minutes for questions and answers, please talk to one of us and even submit that. One important thing is when you submit, please give us at least a bit of draft slides to we get an idea of what your talk would be about. They don't have to be the final ones, but at least give us an idea because we are interested in understanding how you would present it as well. Not just the idea.
What are the changes we have from RIPE 90? We moved to a new submission system Pretalx, that meant changing some of the ways we worked, and that created a few bumps in the road because you have to adapt, for example when we do our online meetings to decide which talks are accepted or not, it changed the work flow for us because we went ‑‑ we moved to Pretalx. It changed the way the talks need to be submitted, so you now need a RIPE NCC access account and then you need to go through a different procedure. But it's nothing too complicated. Then if you need any help, there is the tech team that has a table outside and then you can go and ask for information. But we try to adapt our procedures to new Pretalx. It went generally smoothly but we did have some bumps in the road. If you had any issue dealing with the Programme Committee for this meeting, I apologise, but we were also in a learning curve. So, we also used Pretalx for generating the agenda, which is something we didn't do in previous times, so that also changed how we can do changes to the agenda as we get closer to the meeting.
Then one thing that we still continue to do, though, is to provide feedback. So we always have two submission deadlines, and if you submit at the first deadline, then what you do is if your talk gets rejected we give a reason for it. We spend a bit of time. It's not an academic review. We tend to write a couple of paragraphs about the reasons, and maybe we can help you also resubmit, improve your presentation, resubmit it and then in the following session, the following deadline maybe like we accept it, which is something that happened to a couple of talks in this session. They did a submission initially, we suggested some improvements, they went back, did the, did some changes to the presentation and then in the second deadline, after a second deadline, it was accepted. So, we have seen that this brings some positive returns to what we do. So it's nice that we spend time doing that.
Last but not least, we have PC elections coming up. We have two seats. You can nominate yourself until 3:30 tomorrow. And if you would like to understand what kind of work it involves being on the PC, just approach one of us. It's not ‑‑ it's not too much work. We tend to only do relatively low number of meetings for every RIPE meeting we tend to organise, so we do two, maybe three. And the rest is time that you have to spend reviewing the submissions.
Then if you want to know more, we have a Charter, RIPE‑829, you can go and have a look at what the RIPE PC is supposed to be doing and then come to us and tell us we are not doing the job right for now maybe.
After this, if there are any questions, I am happy to take them. But we are also a bit late. So...
Happy to take any questions if you have any, or you can approach us later. Mirjam.
MIRJAM KUHNE: I don't have a question for you, but just using that opportunity, I was asked to mention to you that in the chocolates that were just handed out, there is one ‑‑ some of you might not want or might specially want them, it's up to you but this is a warning because it's not clear on the label I think, just to note there is alcohol in the chocolates.
Then I would move on to ‑‑ I would take ownership now of the session from the PC side, and I would introduce you to the first talk of this meeting that is from Matsuzaki Yoshinobu from IHA and he will talk about scanning IPv6.
MATSUZAKI YOSHINOBU: Hi everybody. I'm working for an ISP as an engineer named IIJ, also I am serving the executive Council of APNIC, it's basically a Board member of APNIC. Today I will talk about a day in the life of IPv6 scanning.
It's a story about how people scan, how I observed, and sometimes how we get scanned.
Let's start with where we are today. So, here we have a familiar diagram. So, IP adaption is a story but gradually increasing. It's around 48 percent growing, so congratulations so far. So it's getting more popular nowadays, we have many IPv6 hosts in the Internet. The IPv6 addresses are long. 128 bits. So the 128 bits divided into a prefix and then interface ID. Usually a /64 is defined to each sub‑net. So with IPv4 space is very small compared to IPv6, right? It
Scanning all of IPv6 space it's like trying to find like one cat in the RIPE region. It's very tough. Very challenging.
IPv6 has configured themselves using DHCP v6 and SLAAC and with SLAAC the host generates the last 64 beats, the IID, that IID can tell you a lot about the host, depending on how it's made. For example, old EUI 64 based IID has a MAC address. It fits within the 48 bits range, or even a smaller range if the vendor is considered. The red ones are are RFC 7217 and RFC 8981, more privacy friendly, harder to scan. Some implementation like your MacBooks have already adapted the privacy conscious IID methods, but many devices including the latest gaming console, still use EUI 64 based IID.
The scanning all of IPv6 network is almost impossible. Almost. Technically it's feasible but if you send one packet per micro second it will take a large amount of time. So to scan an IPv6 network, you need some crew beforehand. We have DNS name. We have TLS certificate or a measurement like RIPE Atlas. Will
.
This things cannot assume which addresses are alive or in use. Researchers started target generation algorithms, TGA, to generate smart guesses. There are a bench of different starters, maybe it's a good topic for students or Ph.D. candidates. These methods take a list of known reachable IPv6 hosts as input, and from there, guess as an IPv6 host. The goal is to find IPv6 host and make scanning more efficient. Most of them use the IPv6 at their input. The IPv6 is hit list is a reasonable IPv6 host currently around the 3.6 billion addresses. Will so if you are online and they are responding, there is a good chance you are already on the list.
So, that's a theory. I decided to use my home Internet work to see what actually come into my network. I prefer to use OpenSource source project so, here is my choice. PF and nftables to use it. Both use a packet programme implementations.
Here is my setup. I used PF for L3 routing segment and nftables for L2 bridge segment.
So, I set up some processing there to monitor the incoming packet. At Layer2, I can only see packets to existing hosts. Packet 2 unused addresses don't even reach you. The larger on the segment dropped them after NDP fails, right. So, you have a very limited visibility on the Layer2 bridging.
At Layer3 I see more, including packets to unused network or non‑existing addresses if routed. The routing matters here.
Here is my configuration. Because this is a matter for the record, it's a bit on the safer side. If applied in it, it will block most of the scanning so you will not see them much. If we want to see scanning packets, you will need to configure the system to respond to all probes to attract scanning traffic.
This is a configuration. So it's a result. When I compared what I saw to the IPv6 hit list on the Layer2 observation, actually I found one host is actually listed on the hit list, but I didn't see the packet to this host. Instead, I saw a packet of 4 host. 1 CLAT probe in my network, other two hosts with TLS certificates. And the last one, this is a bit interesting, I nearly installed a Ubuntu host in my network and after installing some packages and updating the system, the host started to receive packets from the Internet. I don't know why. Just I installed. Then it received the packet from the Internet. No idea. On the Layer3, 9 hosts are actually listed and 8 out of the 9 were receiving packets. Atlas probe was one of those and others as well. As I mentioned before, I observed the many packets to non‑existing hosts as well on Layer3 observation. Again you need to respond probe packet to be scanned, right.
What do people scan for? Most he is TCP, especially these numbers. UDP packets and SMTP, DNS, IPPen cap and TCP. I saw something on the ICMP IPv6, that's a story of its own.
One host from faraway cloud kept pinging my host every so two seconds. I don't know why. Like someone forgot to stop a ping command. I imagined it opened somewhere, but I don't know the intention here. And this is an observation by Layer3, the result and it's almost the same. Those destination property trends are pretty much similar to the IPv4s, right. So, they are scanning numbers. Once they decided to scan.
I also looked at the destination IID patterns. Mainly were EUI‑64 based, or had the simple patterns like what you see here: : A: A. 2, and so on. Some were totally random, but not many. So scanners often start with obvious addresses.
Prefixes that have never been reachable get almost no traffic. So, in IPv6, at this moment, if nobody knows you exist, you are invisible. In IPv4, you could receive a scanning packet just by announcing the prefix by BGP, right. However, that does not work in IPv6. So, the old style IPv4 DarkNet moth to observe those scanning a packet doesn't work anymore.
I also saw some interesting packets, sometimes I saw ICMPv6 packet messages with embedded like SS 80 style port number but in UDP insight. Like tunnel probes with this. Some of them are scanning packets had the distinctive IPv6 header structure like that.
Distribution is mostly from entities related. Like research project or Cloud providers, maybe they are using Cloud to scan your network.
Scanning often comes from specific hub but sometimes same scanning pattern came from dinner /64 segments. Maybe they are load sharing among the networks or maybe just creative scanning style.
If your host requires to probe, it's added to the IPv6 hit list, okay. If your host stays silent, it's eventually removed from the list he. Usually after two weeks. So if you want to disappear from the list, just go quietly, but some scanners are very patient, even though I removed the host from the network after one year, still I am observing the packet towards this nonexistent address. They still keep scanning the address. Very patient.
If you want to be scanned for some reason like for example to study scanner's behaviour like me, I want to have more scanning packets towards my network to monitor their behaviour. Here is how. Make your /64 look alive or in use. Issue TLS certificates using host names. Publish AAAA records in DNS and put the URL under some website. Use EUI 64 based IIDs. Then sit back, wait. You will soon have many new friends from the Internet.
But most people want not to be scanned. So here is how. Don't list sensitive host publically. Segment your prefixes based on your needs or based on your purpose. Don't respond to unknown probes. And if you are on the hit list, make it silent for two weeks, right. This usually works.
So to summarise:
.
IPv6 scanning is already happening actively. IPv6 hit list is widely used by researchers and companies.
Being reachable may cause your neighbouring address to be scanned too.
IPv4 style DarkNet methods doesn't work anymore, as I said. And access control still matters.
And if we you subscribe to Shadowservers notification, you should be getting reports about IPv6 host in your network on a daily basis.
IPv6 may be huge, but then someone somewhere is always watching.
Scanners are trying to tell success from reasons that are less remote. This is my thinking. But what if we change the problem? For example, if every IPv6 address responded but then only a few are LIR host, what method would the scanners need to use? I hope someone will try it and share the result here in the future.
.
Thank you very much. That's my talk.
(Applause)
JAN ZORZ: Thank you very much for this talk, are there any any questions?
AUDIENCE SPEAKER: Not a question but a comment, if you want to attract attention of scanners you can also announce more specific prefixes in BGP. So if you study maybe the connects it shows exactly this, so scanners do not actually only monitor hit list but also BGP announcements.
AUDIENCE SPEAKER: Really interesting talks. I was wondering if you kept a time frame list of how long it takes for an IPv6 host to become alive and then how long it takes to get scanning traffic. Because that's one the things you notice very clearly with v4 host, if you bring a v4 host online and 30 minutes later you get scan traffic. Do you have an idea of the time frame that it is for IPv6?
MATSUZAKI YOSHINOBU: Sorry, I don't have the number here but as I said, and I have the newly installed Ubuntu host and it immediately scanned after upgrading the system so somehow it could get the scan packet immediately, like IPv4, but sometimes you don't get any scanning packet at all sometimes. It totally depends.
JAN ZORZ: All right? Any more questions? Thank you.
(Applause)
.
And Tom, you are going to talk about SNMP gNMI. Thank you very much.
TOM STRICKX: Good afternoon none everyone, it's great to be back in Bucharest. It's been ten years engine it was definitely after the next one. I am here to talk to you about gNMI, SNMP and everything around it. Maybe talk a bit about, you know, the implementations and methods that you use as an operator or a newcomer person can run gNMI.
So, who am I? I have done a couple of RIPE talks at this point, so I hope that some of you at least recognise me and no who I am. For those of you who don't I am a principal engineer at CloudFlare. I think the easiest way to describe my job is I am a professional shit poster for most parts. You can find me on blue sky at ECMP dot network, I am generally surprised that I managed to get that DNS...
So, what am I going to talk about? Like I said, it's going to be about gNMI. Basic introduction to gNMI, what is it? What does it do, what you see do it the name stand for. Talk a bit about gNMI versus SNMP, SNMP everyone knows what that is, at least I hope you know what it is. Compared to two bit, talk about the up sides and down sides of the protocols. And then the way that we implement gNMI at CloudFlare, how we're using it internal, to make numbers go BRRRR.
First of all, gNMI 101, why do I need to pay attention to it?
.
Very simple. GNMI is the gRPC remote network management interface. What does RPC stand for, remote procedure calling, and G stands for G, it used to be Google, then Google made it open source or public or got it going into more community‑based side of things. So, the G no longer stands for Google, it stands for FRPC:
.
So, what is a network management interface? Three core components here is it allows to retrieve configuration, modify it and pushes be telemetry. The rest of the conversation or talk here is primarily about telemetry, we don't use it for retrieving configuration or modifying configuration. An conf is entirely such because it's XML and it doesn't want to make me kill myself.
So, base component, super important for gNMI, for everything is it relies heavily on open configure. What is open configure? It's a cross vendor unified data models in YANG. I'll go into what YANG is in a bit. But open configure is basically you have a group of people primarily Google engineers, there is a theme here, that will dictate or will kind of agree upon a standardised set of multiples on how do we talk about network configuration. That can ranges of how do we define a DHCP client, a DHCP server. How do we define a BGP speaker. Those all get standardised. These are the components or a attributes that sets configuration needs to have and that gets published in the OpenConfig organisation. As we progress in our automation journey, for network engineers, you'll see more and more vendors supporting OpenConfig models. Some of them are going to be the open source ones, some of them are vendor specific ones. One of the worse things that exists is the open source models but not fully, which is dreadful to work with, because then for 90% that work with all of your vendors and then for the 10% of subset they don't work with any of them except one.
What's YANG? It's yet another next generation. As I said, network engineers are dreadful at naming things. This is what it looks like. It's very simple. It's basically a dictionary side of things with a bunch of metadata, it's here, including what the revision, time is, need space, this is the notation, and at the end of the day what your dictionary looks like. That's it. Right. It's very simple. It's pretty trivial to work it. This is the modelling language that's used for the final models that we have.
Like I said, it's a very simple modelling language nor network management. Back to the agenda. Back to the initial point of gNMI, I just told what you gNMI is, right. Let's talk about gNMI versus SNMP is. What's SNMP? Very simple, it's old and slow. It is primarily insecure. At least if you have SNMP 1 and SNMP 2. SNMP 3 does support encryption and authentication but it's a mare to set up. Here we are, also I don't think anyone really uses it in production all that much. We do, but it's not fun.
Also, last but not least it uses ASN.1 extensively. That's insanity tee as a language. It's all of to use, it's completely incomprehensible for people that don't use it on a day‑to‑day basis, and you just need translation layers upon layers to make it make sense in any way or form.
The biggest problem that we ran into and why we started exploring our gNMI journey is the old and slow method. Specifically the slow. BGP is also old that seems to be working pretty well. But unfortunately SNMP not as much. Specifically what you are seeing here is one of our most heavily loaded routers that we had in our network, you see all of these gaps at the SNMP here. The way it's implemented over the majority of vendors is it's getting all of the counts for all the interfaces, dumping that through your control plane and then from that you push that to whatever system you have. If you have too many interfaces, that bowling is going to take a very long time, and if you are scraping or trying to scrape faster than your router is going to return your data, you get gaps, which is suboptimal because if there is any congestion events in these gaps, then we would know about it because if we don't have a visibility, we can't say where it is congesting. Unfortunately, but fortunately, our customers seem to care about uncongested ones.
Very quick comparison, or gNMI versus SNMP it, gNMI it is pretty simple. It's standardised resource path all using OpenConfig with protocol encoded. It's secured by default. DLS is required. We can't even spit up a gNMI server or gNMI client without running TLS. That's neat. It's using HTTP 2 by default and it's a publish subscribed architecture. That means it's used for a pool based counter fetching, sorry, the pool based counter fetching. You can do push with traps but again it's a bit of issue in this case. What you do with pub sub is that as a client that is interested in metrics or is in interested in configuration, I will tell the router hey, you can send me data to this endpoint and that router will then start sending you data and at a specified interval or just a one‑off, but it's published and subscribed. You basically publish the intent or the interest in metrics and then the router will keep sending you kind of refreshes all the time.
SNMP, instead of protocols we get OIDs. At one point when I did this talk as a trial in London, Ben was nice enough to remind me that Protobuf in this specific use case is new OIDs, so it's like YANG but worse, so, it's OIDs everywhere. The fun thing of setting up a SNMP scraping host is first figures out with bips do I need and which W package do I need to get all the bips. Is any of them conflicting and do any of them work?
If you want it's plane test. You can run P3 with encryption on top of it, but it's entirely optional. It's not something that metadated, it's not something that's coded in the protocol spec.
It's also pure UDP. The joys of UDP are infinity I am sure. But the bigger problem is if you have MTU mismatches really your time is figuring out why you are not getting the data you are getting. Not fun.
Now, let's talk about the elephant in the room. Just purely from that kind of comparison generally gNMI is the superior monitoring system but yet we're not there. I think for the vast majority of you folks here, lets raise hands. How many of you have heard of gNMI? And how many of you run gNMI? There we go. That's about 5 percent of the room I would say give or take. So, we're not there yet.
There is a vast, a wide variety of reasons why that's not the case. One of the things is if it works, don't fix it, right. And SNMP for the majority of us works and it does the job.
GNMI also has its own problems. Vendor adoption is a really big one. Your fridge probably once SNMP. Your often probably does as well. Whether you want to or not is obviously a different conversation. But it's not going to start running gNMI any time soon. I am not sure how visible this is, but the vendor consistent of gNMI is all of.
The key component here that indicating is here we have a thing to delineate the words. So you have laser underscore power underscore low underscore whatever. Then we have carrier dash transitions. The consistency issue is not there. Which means certainly vendor will do carrier dash transitions, okay, which I think is the correct OpenConfig annotation. Then other vendors do carry underscore transitions at the same point depending on which kind of gNMI consumer that you are using, that's going to turn into a different metric, which is not great if you want to compare different devices or compare different network traffic.
Also last but not least, SNMP well documented. There is a variety of ecosystem available of SNMP clients and SNMP servers, all of them are pretty well documented. The MIBs, pretty much well documented. GNMI, not as much.
One good example here is from a specific vendor that may or may not have been a acquired last year by an even bigger vendor has, you know, their documentation for the majority of their gNMI counters are not available on their website. It's actually available on this PDF. And that PDF is basically 300 pages of here is headers, do something with it. And it's dreadful because that means because it's a PDF you can't search it on the web, you need to find a PDF, download a PDF and start searching through it. Last but not least they did this thing of here is our documentation all the way up to 23.2 R1 because if you want to use anything after that, here is a different web page that contains all that documentation. Will why they did this, I don't know. Will it just means I now have two web pages book marked instead of one. It works, I guess.
Like I said earlier, Protobuf OID, it's basically the same thing, we replaced one pain in the ass for another. Fine. I guess. The gRPC mandates the use of Protobufs, but that's okay. It just not the easiest thing to read. If you find a Protobuf on the wire, good luck trying to understand or decode or figure out what you are looking at. So that's not happening, but that's the same thing I guess. That's not really a big change anyway.
An addition they added to the gNMI spec after the initial gNMI specification came out was GM extensions. In the same way that SNMP allows vendors to put to get reservations or arbitrary, why these? GNMI has a similar concept. It is gNMI extensions. What does an extension look like? It's basically this. It allows a vendor to put arbitrary metadata on top of any given path that you want. This is specifically from Juniper. They are also, as far as I know, the only ones that currently a officered extension identifier which is also their ID registered extension is 1. But you can put arbitrary metadata in that path. It's helpful to make that work. You do need an arbitrator Protobuf. So what the vendor is supposed to do in the same with a we have vendor megabits, it's vendor Protobufs now. It's the same statement but different. I'm not going to say one or the other is better. At least in mibs I can download to my .
Let's talk a bit about how can you get gNMI data from your network devices in something that you care about, like a metrics pipeline in one way or another? There is a variety of tools available. Not all of them are as as well maintained or as available. The first one, I think this was kind of the original gangster of the gNMI tools out there. It's GM gateway. It was developed by Netflix in the late 2010s. It's quite configured. Like I mention it, configure is is basically a rag tag group of hosts that go back OpenConfig side of things. Quite a bit of Google folks in there, but there is a bunch of others as well. It is no longer maintained. I think the last push I saw the public rebuild was from 2020, 2021, it's not seen active development for a while. It works though, if you are a vendor, does anything weird or anything specific like JSON encoding everything that it dumps out, it's not going to work. But other than that, it's fine. It's a good kind of initial avenue into I want to get some metrics or I want to get some data out of my router, how do I make that work. The gNMI gateway is a good option.
Second component here is the exa ring streaming telemetry exporter. Smaller than the gateway. It doesn't try to support everything. It's very easy or tightly scoped to getting metrics for a specific thing. As far as I know it's also not maintained. But just like the gNMI exporter, it works for the most part.
And I want to kind of two of the actively maintained gNMI supporters that you can use. The first one is Telegraph. Telegraph is kind of fits one the influx dB ecosystems. You already have a metrics pipeline that uses influx dB, then the only thing I would recommend is use Telegraph is the easiest basically plug and play component out there. The cool thing with Telegraph is it's M IM O architecture and it supports plug‑ins. For the most part it exists. There is a plug infor it. It's even the case for gNMI, there is a plug in for t it also has active Juniper contributions for the gNMI extension which is primarily, and thanks to David for that. Will that's been really helpful to get us off the ground, CloudFlare is a Juniper‑ish shop, so there where we're at.
If you already have influx dB in your environment, Telegraph obviously is the easiest choice.
Then you have gNMIc is developed by the good folks at Nokia, it is now also widely open configured. It's micro architecture, multiple inputs and outputs. Multiple routers, just through the single gNMIc steam. It can also collect from other gNMIc explorers. So you can have this chained together architecture, you can dump things through Kafka and stuff like that. It's also just like Telegraph, it's actively maintained there is active contributions happening there.
That's what the ecosystem looks like. I am aware of two very actively pretty wide separate good community maintained implementations. That's good. I prefer to have a third, you know, variety is the spice of life and variety makes the ecosystem healthy but we're at two and that's them.
Now to the fun bit. The production. Making numbering go BRRRRR. You how do we at CloudFlare use gNMI? This is our production architecture. The tiny bits here aren't super relevant so don't try to decode any of this as much. But what we have here is per data centre we have multiple metrics collection nodes. All of these metric collection nodes will subscribe to the exact same data monitor pass of the router. Be mindful most vendor implementations will have a limit to the amount of subscribers they support. Juniper specifically supports five sub‑subscribers at a maximum. If you run six clients, that's sixth entity is not going to get anything. Just going to get a 403 from the collecting agent and tell it to go away. What we then on top of gNMIc deployments is a built in tool or an in‑house tool called net watcher. This is magic proxy that metrics proxy is scraped by Prometheus and that's our go to database. That's what we use.
.
The main reason why we went for gNMIc instead of Telegraph is the existence of the gNMIc processes. Processors allow you to kind of data manual your metrics before they get inserted into your time series database. It's neat as a bunch of available options that you can use including a subset of Python or Python dialect that allows you to basically run Python functions across your metrics to skew them in the sway that you want them to.
One of them the example of this one, it's purely a.m. I will, it's not great but here we are, we decided as an industry to have Yaml as our chosen anything, but we're we are. It allows me to draw any of the interface metrics for a bunch of the cases I am interested in. If I'm not interested in these cases, not interested in the management interface or any of this, so I could just drop those. There is some ‑‑ I have used some interfaces on the Juniper box, they get exported that I'm not interested in. I can replace or change some of the tags on the metrics that are being exported. I can do that within gNMIc easily, just using Yaml or Python if I were a bit more advanced.
So, I talked about the gNMI extensions earlier. So, there is an internal fork that we use for gNMIc that we are trying to upstream into the public code base, but I need to have time more than anything else. But you can find a full request on GitHub on implementing this, but this allows us to do is it allows us to specify a Protobuf at one time to decode the Protobuf passages that we get from the gNMI extensions. For those of you not familiar with developer with Protobufs, most of the time you use Protobuf to do code generation and then that code generation goes into your programme or your tool or your system. But you can't do that with gNMI extensions because depending on what the vendor, you might have different Protobufs that you need and you don't have to recompile gNMIc every time a Protobuf came through. What this PR, the GitHub request does is allow you to define a proto file at one time and it uses the sub‑reflection capabilities to make that work. It is absolutely dreadful. Please don't judge me on that quality of decode, but it works, so that's all that matters.
Then, net watcher I mentioned is basically an in‑house built data processor and aggregation layer. It allows us to do some things like aggregating everything for an interface, and. I'll explain why we need to do that now basically.
But, this is what it looked like for us. It allows us to make our numbers go BRRRR. I built an entire dashboard which was a replication of our SNMP dashboard. It worked. This is for the Singapore router that wasn't showing a metrics when I wanted it to. And it's working now with gNMIc. So that was a great choice.
Unfortunately, this wasn't, you know, without trouble. There were definitely some problems. Primarily because gNMI isn't always the most mature protocol. Specifically what we were seeing was that our interface was doing ahead of its work to traffic, we're not as an industry, we're not at pedestrian bit scale individual routers yet. So, me seeing like an IRB on a single chassis doing, I think it was 3 something per cent worth of traffic is usually an indicator that something has gone wrong pretty badly.
The thing that we then started looking at is okay what is the actual counter that I am deploying at? I saw this thing, which is a pattern on a bike counter. Counters are supposed to go up, not down, so when you see a counter go down you know that something has gone who arefully wrong. So why is this? How did that happen? Very quick detour which was I have 8 seconds left. So I am sorry.
This is the gNMI architecture, very, very bereavement gNMI architecture on a Juniper box. You have gNMI subscribe, that goes to the routing engine, the routing engine then goes to the MQTT topic for a subscribe and then you get messages for whatever things that you are subscribed to. This is a message plus protocol, it's heavily use d in Internet of Things architectures. It is pretty low weight, low anything. But it mostly just works. So, what you can get is a chassis based switch or chassis based router so you have multiple line cards. You get MQTT messages. That goes back to the routing engine and that pumps it back as a gNMI subscriber.
What we were seeing with this pattern was, either on interface on the Juniper boxes is... top line was like our line card zero and the bottom line was 1. Will this was identical for line card 1 and zero. The gNMI deduper will say whatever ranks first is the run that I am going to report it on. You get a race between the two and trying to report the metric which is why you have got that pattern.
Specifically, within Prometheus what it does for the counter is it needs some increase in value. If it doesn't, it adjusts for it automatically. Will what that means or what Prometheus specifically will do it will assume that the counter has reset and it will sub the previous value with the current value. So that's why we got pedestrian a bits worth of traffic is basically because Prometheus was trying to compensate for what it's trying to think is a counter set. That's where we're at. The way that we fixed this problem by the way is by using the gNMI extensions, the gNMI extensions added the line card metadata which was sufficient for us in duplicating the duplicate metadata or the duplicate counters, and that was sufficient for us to prevent that and make that problem go away.
I want to apologise for putting this on you. Will you are now cursed with knowledge such as the bane of the network engineer but if you have any further questions I am more than happy to answer them.
(Applause)
.
AUDIENCE SPEAKER: You have brought back several flashbacks for me, it's been fun. I had a question, two questions I think in particular. In terms of intervals, ‑‑ how are you handling the replacement for SNMP traps.
SPEAKER: We do a 15 seconds interval. From the router, and we do a scrape from Prometheus every seven and a half seconds because basic sampling, we need to get two or whatever value and that works pretty well. Routers seem to be able to keep up with that pretty well. And for us, that is like that 150 second‑ish delay is perfectly fine.
AUDIENCE SPEAKER: The bigger question is, there are obviously a lot of problems with vendors implementing open models with their own flair or just deciding to use their own models and coming up with random stuff, dinners in selling a counter out that's got bytes versus one that's got megabytes in and all of niece things versioning one ever buy biggest bugbears with this whole problem. How are you handling versioning of modules? Are you doing normalisation?
SPEAKER: That's where the network watcher component comes into play. The main reason why we have it in the first place, is ‑‑ one the things that we had is obviously kind of the default metrics that are produced by gNMI, the gNMIc specifically are very verbose and they didn't map to the metrics that we had nor SNMP. To be able to do kind of an incline with placement R metrics we have learning and everything else set up we needed to do swapovers. That's where net watcher comes into play. It will give them the same standardised naming to make sure that everything is equity consider. From a versioning perspective, we will rely heavily on gNMIc in having the Protobufs and be there and working so that's not working, then I get to do some... and figure out what isn't working properly. The gNMI extensions are there as a fix. I am just not really seeing vendors implement them besides Juniper. Arista is nice enough to sit on the config models. I have not had the pleasure or the pain of dealing with Cisco yet, but that's coming soon. Ask me again in six months.
AUDIENCE SPEAKER: Don't worry we, are going to have a conversation.
MASSIMILLIANO STUCCHI: Can I ask you to be quick because we are already over time.
JEN LINKOVA: Thank you very much. Regarding your point about frees not running gNMI, from my experience no vendor ever implements until a customer asks. I wonder if you just confirm my suspicion that when you start it, your feature is SNMP and open config path was much better than it is now. So I guess as an early adopter help everyone in the room who is not running it to start thinking about it.
TOM STRICKX: If you are a vendor just not have a gNMI implementation. Go yell at them. Strangle them until they agree to do it. Please say I want to get rid of my SNMP implementations, a hundred percent.
AUDIENCE SPEAKER: I first think I looked inside Google for gNMI RFC and I did not find any, it's not standardised.
TOM STRICKX: It's not an IETF standard, it's OpenConfig, they have their own kind of Working Group and that's ‑‑ but it's a standard.
AUDIENCE SPEAKER: It's proprietary so it's standardised.
TOM STRICKX: It is not a proprietary solution. It's a open source community in the same we have wi‑fi other Open Sources communities out here. Just the protocol is not standardised through the IETF but there is a standardisation system in place for gNMI that works within the OpenConfig route.
AUDIENCE SPEAKER: Hi. So, thank you for bringing more love to gNMI. We are on the same path. So I am curious how hard and difficult it was for change from SNMP to gNMI at the moment? And is the road finished yet?
TOM STRICKX: I used to have lovely brown hair, it is now luscious brown and grey hair. I think that is indicative enough. It's a in PA. There is massive up sides. There is significantly more metrics that we can get out of gNMI than we can get out of SNMP. Just the consistency isn't there yet. We are trying. We're not finished. We are slowly rolling things over. But what we're doing is, when we're rolling over we are also adding a bunch of new counters in gNMI that we weren't getting out of SNMP. So it's a multi‑prong effort in trying to get things going. But I suspect that it's going to be at least another year or two before we can get rid of SNMP entirely.
AUDIENCE SPEAKER: Same.
AUDIENCE SPEAKER: Rudiger Volk, retired. When did you start to use gNMI?
TOM STRICKX: So we did a first evaluation of gNMI in 2019. It was not mature enough at that point in time as an ecosystem to use it. We then started rerouting in 2023, which is when we noticed that there was significantly more kind of options and community support out there. That's when we decided to pick it up and actively start engaging with the community and engaging with gNMI as a solution.
RUDIGER VOLK: My understanding is that the part that was used in the MIPs, OIDs, and so on, is essentially replaced by YANG models, you are using it, kind of IETF thinking about programme away from SNMP which started very much 20 years in RF 33535, was actually first to the access protocol part, which means net conf and rest conflater and the YANG part actually came later. I wonder whether you can make any explanation of what you are looking for or not on the NetFlow conf part. Because that has been evolved over the past few years a lot and my understanding that when you started to use gNMI actually net conf and rest conf were actually already quite solid.
TOM STRICKX: Yeah, net conf is very solid, we use it. Just I wasn't involved in the developing of gNMI given that my employer wasn't Google, and they built it. So... why they picked YANG instead of net conf, I can't answer. The big thing with YANG that you don't have in net conf is standardisation of what something should look like. Net conf does not prescribe you what BGP configuration needs to look like for example. That's kind of entirely separate from net conf. That's your summation ‑‑
RUDIGER VOLK: Net conf does not define the model. The model is done in YANG and that is kind of pretty hard thing and will take take sometime I'm sure it will deliver.
TOM STRICKX: We'll get there, it's just going to take 20 years, easily, but that's fine. Like, it's like IPv6 all over again.
MASSIMILLIANO STUCCHI: We have a quick question here from...
JAN ZORZ: There is a question for Sayid Najeep. Is the R vendors are support work with this protocol?
TOM STRICKX: So the major vendors out of there, right, from the big four, they all support gNMI, one way or another. Like I said, Juniper is the only one that I know that does gNMI extensions. Micro deek, I don't know, and I know that's an important platform, so I don't know if they support gNMI. There we go. The answer is no. But, you know, if there anyone from micro deek around, please let us know, the vendor support is significantly lower than SNMP. Like I said, fridges support SNMP and they are not going to be gNMI any time soon.
MASSIMILLIANO STUCCHI: Okay. Thank you Tom. We are way over time but this was interesting.
Now, before going to the break, please remember to rate the talks, because that's your way to let us know if you liked this, or if you didn't. And give us a way to improve for the next meetings. So, at the top of the hour, there is the next session. See you then.
(Applause)
.