RIPE 82
.
Plenary session
.
17 May 2021
.
16:00 (CEST)
WOLFGANG TREMMEL: So, hello, everybody, and welcome back to the four o'clock Plenary session today. I am Wolfgang and I will be chairing this, together with Franziska. As always, a few words of housekeeping before we get started.
.
If you want to ask questions, you can either use the question button or you can queue up for the virtual microphone queue and, new this time, you can also ask your question with the microphone and video. And as always, if you are asking a question, please state your name and affiliation in the question button; I think it's added automatically.
.
What else? The chat is a nice feature, but it is informal and please do not ask any questions to the speaker in the chat window; use the question button.
.
We are recording this session, as always, and I think that's it. Did I forget anything on housekeeping? No, I don't think so.
.
All right. And with that, I would like to welcome Alexander Asimov to the stage, the virtual stage, and you will present about self‑healing network and the magic of Flow Label.
ALEXANDER AZIMOV: Thank you, Wolfgang. So, let's start. Hello everyone, and I am working for Yandex. Today, I'm going to show you how to enrich TCP with self healing capability in case of network outage. I will pay special attention to data centre environment, but it's not only about data centres.
.
For those who are not familiar with what is Yandex, it's a huge ecosystem of systems that are supported by hyper scale data centre infrastructure. And before jumping to the problems that may give you have in such a big network, I'll spend a couple of minutes describing the architecture of modern data centres.
.
The minimum building block is a rack of servers ‑‑ connected to the top of the rack switch. This type of rack switch is connected to the first spines. So, on this slide, X 11 and S412 represent to first layer spines. The set of ToRs connected to the same set of first line spines is called SRC port.
.
First, line spines are selective port, belonging to different plane. Each plane consists of first line spines and second last spines or super spines refer cross‑connections between ports.
.
I will use letter X to represent spines during my slides.
.
And, of course, traffic is balanced in the fabric, and normally we are using common to build the label of top of rack switch and at the level of first layer spines.
On the other side, there is of course another top of rack switch, or switches, and it is believed that such kind of topology provide an easy way to scale and also provides false tolerance in the Internet network. Both statements are true to some extent.
.
For example, if we increase the number of planes, it will definitely increase the capacity of our network. It looks very easy on paper, but if you do not invest in fibre and the ports at day one, it will be really hard to make such expansion.
.
As for the false tolerance, modern data centres provide multiple paths between most servers. The single path between two servers exists only inside the rack. If we take a look at what happened inside the port, the number of paths will be equal to the number of planes. If we are speaking about connectivity between different ports, the number of paths will be a result of multiplication of number of planes and number of super spines in each port ‑‑ in each plane.
.
To make you feel the numbers, here is just an example from one of Yandex's data centres. It has 8 planes and 32 super spines in each plane, which results in 8 paths for the intraport connections, and 156 paths for interport connections.
.
So, let's get back to the main topic. Such topology provides escapability options and, for the majority of connections, there is multiple alternative paths. But does it provide for tolerance in the case of network outage? It's proved to be highly dependent on the type of the outage. Let's say we have a problem. The X 11 part of one of our super spines is broken and it starts to drop packets that are coming through it. If we are happy enough to have automatic tools that are able to detect it, for example, it drops all the packets and there is 15 places and it instantly drops the BGP session, everything is still fine and so the services ‑‑ and the services won't notice any effects. So the traffic will just be redirected through other super spines, and everything will be fine.
.
But what if the broken spine is losing packets, but losing only a subset of packets? So that's the contra plane is not disrupted but still there is constant connectivity issues between service in the SRC. Most of the transport in the data centre is still TCP‑based and TCP relies on the acknowledgment process.
So let's see how it works.
.
This will be a very oversimplified example of how it performs in case of loss with a focus on the timers. In Linux, the TCP stack will send an cumulative acknowledgment message for each two packets, it's a very old optimisation that is reducing the number of packets in the network. To further simplify, let's say that the condition is limited to two packets. It's not very realistic in general, but in the case of packet loss, that may really happen.
.
So, let's move forward. And once the sender will receive, it will send another two packets. From now, it's perfect, it's good. But what will happen if some of these packets are lost? So it highly depends on which packet is lost. For example, if we lose an intermediate packet, for example, the packet number 3, the receiver will respond with selective acknowledgment. It will clearly mark which packet is missing. And upon receiving the selected acknowledgment, the sender will just retransmit a specified packet and it will happen instantly.
.
But things become very different if we lose the last packet of the window, because in this case first, the receiver will start, wait until the delayed arc time expires. And finally it will send that I have received first three packets, if you want to send me something more, but, after that, the sender will start waiting. It has no idea about if the fourth packet is still in transmission or if it is lost, and it will wait until retransmission timeout expires, which is the minimum between measured RTT and what is terming ‑‑ we will get a few seconds later. And if we are unhappy to lose the fourth packet again, the retransmission timeout would grow two times. After each unsuccessful attempt, it will grow two times. And, of course, it's very important to know that basis, the basis of RTO compared with RTT.
.
And that's where the situation becomes crucial, because RTOmin in Linux has a default equal to 200 milliseconds. If we are unfortunate enough to lose SYN packet, it is even bigger, it is 1 second, compared to the delay that the common in the data centre environment, 1 millisecond.
So, how packet loss affects our sources? As we discussed, the selected acknowledgment will trigger a need for specified packets but compared to acknowledgment, it instantly creates service degradation and the nasty thing is that the TCP session with all its retransmit is still bound to the same path. So, we have a problem in the network, and all our retransmits are coming through the same path, and here the problem will be gone only when network engineer will find out who is ‑‑ what is the cause of the problem and shut down the device.
.
There are two types of actors, and both of them are trying to the reduce effect of the network outage. Trust factor is services of course. They are affected and they try to do what they can do. So they try to during TCP, some of them are heading software health checks on top of which the problem is that this solution are not scaleable. They may work in some environment, they may not work in another. There is some software defined checked can work for some services, for some services it's not appropriate, and so in cases of a situation where nothing else helps the services, the service maintainers, of course blame the network team. What can the network team do in response?
.
You know that I found that a lot of services really believe that these kind of troubleshooting network is quite common. Of course the reality a bit more complicated.
.
Network teams are using different monitoring tools to speed up detection process that they use. Black box monitoring tools, they use white box monitoring tools. They talk about black box monitoring tools will take another hour of talking. So let's focus on the timing.
.
It takes a couple of minutes to elect the data and process it. It stakes another couple of minutes to verify the results from the monitoring tools. And is a late the route cause and normally shut it down.
.
As a result, it takes from 5 to 20 minutes to resolve the issue. And what a surprise? It still doesn't sound good for the services. So what can we do to resolve this dependence, the dependency of network outage and service outage? So in an ideal world, we may think that if we can move TCP flows from to other alternative paths, because we have discussed, we have multiple alternative paths. If we can move TCP flows, these may save the day, so the services will not experience any effects, but the network engineers will have enough time for troubleshooting. And if we want to use multipaths, maybe a multipath TCP, that will be the solution.
.
Multipath TCP. It was created for very different environment. It was created for devices with multiple network interfaces and you can easily find such a device in your pocket. But still, it has multiple sub‑flows that can be used to balance traffic or is in a primary backup mode, and it has full transparency to the application, so applications doesn't need to change anything. It's just transport layer.
.
It works by establishing sub‑flows and it's very important that the first sub‑flow and, after that, you can establish master flows if you want.
.
The problem occurs that if the first sub‑flow is not established, you are still bound to the same path because they are not established simultaneously. First, you need to negotiate your first sub‑flow. After that, you can create a second, third, fourth and so on. So multiple path TCP can improve your full tolerance in case of for ‑‑ it's already established TCP sessions.
.
But for new sessions, it will have just same performance as regular TCP.
.
So, what other options do we have?
.
And we are moving to a very pick peculiar topic. We will now discuss the use of the Flow Label field. Let's start from the simple packet. Flow Label fields is 20 bits long. It is present in IPv6 header. It isn't present in IPv4 header, it's quite clear, and for years there was argument how to use this field.
.
The consensus ended with the next purpose of this field. It can be used for stateless load balancing in a company with 5‑ if it is available.
.
And what happened in the Linux Kernel? It went far beyond what was ‑‑ what is right and in the IETF documents and I will show you a quick recap of what was happening in the Linux Kernel.
.
So, in 2011, was published RFC 6438. It was about encapsulated traffic, and there was a finding that using Flow Label using encapsulated traffic where transport layer is not available, then it improved a load balancing of this kind of traffic and the idea was that if we put in the Flow Label field, the hash from the TCP circuit, we will get load balancing with higher properties, of course.
.
This idea was also expanded to other types of encapsulation; for example, to GRE, with GRE key to UDP encapsulation with a soft port, and so it was done in 2014, but next year, a very interesting thing happened. In the Linux Kernel was added hash a recalculation in the TCP circuit and it was done on a negative routing advice. What is negative routing advice? It is expiration of RTO timeout that we have already discussed. The next year, another big brand company strengthened the solution, and now the hash recalculation is applied not only for RTEs in the middle of a TCP session but also at the beginning of the session if we have seen a retransmit.
.
So ‑‑ and a small surprise. And this is the current Linux defaults. So it's not something that you are turning on. What is turned by default in signs, I think five years.
.
Unfortunately, there is a drawback. Normally, such changes require a lot of discussion in the community and lots of documentation. This was another area and there was a little discussion on the Linux mailing list and no documentation at all. But, I know what was done. I believe many of you have already guessed what was done. And for those who are still confused, I will show how it is affecting our problematic flows in data centres.
.
So, let's get back to our example. We will still have X 11 that is broken and it is losing both of the packets that are coming through it. In case that we have a selected acknowledgment, the situation is not changing at all. But the moment we have RTO timeout, we have a chance ‑‑ so if we have RTO timeout, the TCP hash will be repopulated, so will be Flow Label, and if we add a Flow Label to the hash function of our top of rack switch, we have a chance that the current packet will be redirected to another plane, in this case of two planes we have 50% chance after each attempt; the more planes we have, the highest chance the TCP flow without TCP session interruption will be redirected to unaffected part of the network.
.
The last problem is still timers. They are too high. It's several hundreds higher than the real RDT in the data centre. So how can we change the RTO timeouts?
.
The RTO mean that that is responsible for the timeouts in the middle of a TCP session can be changed at the euro space using the IP router. You can define it for selected prefixes and it works fine. But SYN RTO is very different; it is hard coded in the Linux Kernel and it is said one second, and cannot change it from the user space. The only way to change SYN RTO is to use EBPF. This is ‑‑ you can describe it as a custom programmes in C that can be uploaded in different parts of Linux, and, with EBPF, it resulted that you can change nearly every TCP options or effect for the timers that are ‑‑ otherwise can't be changed in the user space.
.
So here is an example of changing SYN RTO for TCP. It works fine. Maybe you can do it in a better way, for example, programme making a prefix lookups, but anyway, it works, and it also works for mean, so both timeless can be changed using EBPF. For example, in our data centres we set both values to 4 milliseconds.
.
And now how it works.
.
So, after we deployed EBPF agents to the hosts plus we fought with our vendors to support Flow Label at the top of rack switches, we decided not to wait for a next big outage, but to create small artificial. We took top of rack switch with 4 uplinks and just created a constant packet loss on one of its uplinks. On the left side, you can see the output of our data plane monitoring. It's UDP‑based, it knows nothing about any kind of retransmissions and so because one of our uplinks of our top of rack switches is failing, you see that it shows 25% of packet loss, so it's all correct.
.
On the right side is the traffic of services, and you can see that it is down for the volume of traffic has reduced four times. So, one uplink results already in huge disruption for the services.
.
Now, we enable the flow label on our top of rack switch. It doesn't affect the results of the data plane monitoring because it's not about TCP, it's not about retransmit; it just shows we are still losing 25% of packets, but services are not affected at all. So, I really believe that this is great. It gives us an opportunity of self‑healing in TCP.
.
So, in IPv6, and congratulations for all what have invested time and money in adopting IPv6, because you cannot do these in IPv4, it is possible to enrich TCP with self‑healing capability. If you are going to apply in a controlled environment, you may be also interested in tuning timeouts and EBPF gives you proper option to reduce it according to your real RTT values. And my thinking is that there was no documentation, or it was not minor, because lack of discussion may lead to some unforeseen problems. Unfortunately, this case wasn't an exception.
.
Let's see next example. We have a client and some anycast service, Stateful Anycast service; for example, it's a TCP proxy, and the client experienced maybe problems, maybe last mile, maybe some small network outage in the middle, but there is RTO timeout, and the client ‑‑ a client recalculates its TCP socket hash, thus it also changes the value of Flow Label. This results that the following packets may be redirected into another speed proxy without any state, and the result of had these will be, of course, TCP timeouts. So, if you see more timeouts during traffic ‑‑ during upload in IPv4 compared to IPv6, that is the reason. In our network, we had to switch off a Flow Label hashing at our border routers; it helped, but only of course in a subset of cases.
.
One may think that we need to roll out all of this functionality, but I don't think that it is a really valid option, because self‑healing capability is a really killer feature, it's especially compared to IPv4 where cannot do such things. The problem here that I just described is happening because the recalculation happens at the client side, and we know who is the client, who is the server. The client sends this in and we can restrict, by default, recalculation of the TCP hash at the client, and keeping its current mechanics for the server side. It will maybe reduce its qualities in data centre environment, but if we still have not switched it on, it will be fine and it will be working not Openflow in data centre environment but also it will be working in general.
.
So, this is my last slide. And I would like to summarise what I was trying to talk about.
.
So Flow Label and its current Linux implementations gives a way to jump from a failing path. It already works in controlled environments, in the data centre environment. I am pretty sure that in a couple of ‑‑ we have been using this feature for four years, in our network we are using it for a year. Unfortunately, a lack of previous discussion resulted in there is a missing part that can disrupt TCP sessions between end users and Stateful Anycast. So we need to change the defaults and I really believe that we need to properly document it this time.
.
Speaking about documentation, normally if you want to have some technology to move fast, it's not about IETF, of course, but unfortunately there is nothing better than IETF if you want to document behaviour of such important protocol like TCP.
.
So, if someone will be eager to volunteer to work on the Linux implementation or work on the document, please contact me, you are very welcome.
.
That's all from me. Thank you for listening.
FRANZISKA LICHTBLAU: Thank you. Maybe just a question. If somebody is ‑‑
ALEXANDER AZIMOV: I can hardly hear you.
FRANZISKA LICHTBLAU: A small question. If somebody, because you presented ‑‑
ALEXANDER AZIMOV: I think your microphone is working from the laptop. Once you are going ‑‑
FRANZISKA LICHTBLAU: Okay. I am very story ‑‑
WOLFGANG TREMMEL: Something wrong with your microphone. All right, taking over for the Q&A session. There is one question from Gregos, I cannot pronounce the last name, I am sorry Gregos, and the question is:
.
Do you think it would work with QUIC?
ALEXANDER AZIMOV: I don't see why it should not be working in QUIC. Of course you should be very careful when you are changing the Flow Label, because, for example, RTO timeout is the value when you are ‑‑ you should be sure that all packets have been and in the same time, it can be applied to the QUIC protocol.
WOLFGANG TREMMEL: Okay. Then I see no further questions, and nobody in the microphone queue. Then, thank you, Alexander, and the next one up is Christian. Franziska, would you like to try your microphone again.
FRANZISKA LICHTBLAU: I hope this is working now. I have no idea why it isn't. No? Okay.
WOLFGANG TREMMEL: We can hear you, it's better, but it falls down, so if you have some automatic gain control of.
FRANZISKA LICHTBLAU: Nothing I have control over, so, Wolfgang, please.
WOLFGANG TREMMEL: It's fine now.
FRANZISKA LICHTBLAU: The next speaker is Christian Teuschel and he is presenting the ten‑year anniversary of RIPEstat.
CHRISTIAN TEUSCHEL: Hello. And right now I am going to share my screen.
.
First of all, good afternoon from Amsterdam and welcome to this lightning talk on ten years of RIPEstat. I have the pleasure to present some of the highlights from the past ten years. And I will also give a bit of an outlook on what is coming up next.
.
So, before there was RIPEstat, there was something called REX, the resource explainer, and REX, according to the documentation, is a one‑stop shop for almost all information you ever wanted to know about Internet number resources, and, interestingly enough, REX was very tightly connected with database, which was called INRDB. According to the documentation, it's non‑conventional database. But for everyone who is developing information services, the features that you present in an information service are always very tightly connected to the back‑ends that you are using, and this is something that we had to learn over the past ten years, definitely.
.
Let's move to the beginning of RIPEstat. That was 2010, end of 2010 I joined the RIPE NCC, and RIPEstat was one of my first projects. I had to learn the problem statement, and that was that there was a lot of information for Internet number resources out there, but it was scattered all over different platforms, locations or tools.
.
The basic vision of the tool was to combine all information services as well as other public data sources into one easy‑to‑use interface. We didn't really manage to get everything into one user interface, but this is something that I am going to talk about a little bit later.
On the right side you are going to see a wire frame of that initial design of RIPEstat and you can already see the similarities to the RIPEstat as we have it right now.
.
Back then, and also still now, we had two focuses: one was to provide statistics and status of the network or parts of the network.
.
Then, if RIPEstat would have had a birth certificate, then it probably would be the 25th January of 2011, would be stated in there. That was when the tool was presented to a wider audience, and we had our first public demo.
.
I do remember that back then we had only 25 participants, but that was simply because we were using WebEx and that was limited to 25 people. Nowadays, I think that would not be state of the art any more.
.
So, 2011 was for us actually a very packed year, very eventful and also for RIPEstat, because just two days later, and this is if the Internet would have sensed that RIPEstat is out there, there was, for me, the first Internet outage that I experienced and that was in Egypt, and in the sense of being this one‑stop shop for all Internet information, we created a special page dedicated to this Internet outage. A few days later, there was this earthquake in Japan at the coast of Honshu, and we did the same. End of 2011, we added two very important features, one was the data AP and one was the introduction of widgets, and that basically formed these three layers as we still have it from the outwards‑facing perspective.
.
Internally, of course, a lot of things changed, as you will also see.
.
From a usage perspective back then, they were at around 10,000 requests per day, and I have to say that, since this is a lightning talk, I had to skip a couple of years, but don't you worry, because we will have extended version so you will get the full version of this presentation on Wednesday during the MAT Working Group session.
.
What I didn't skip was 2013, because this was the year when we added BGP Play to RIPEstat, and probably everybody knows about BGP Play. What's probably not so known about BGP Play is this was not the first implementation. The first implementation was a Java applet done by Roma University. Only later this year we joined forces with the Compunet Research Lab, which was also from Roma University, and implemented BGPlay as an open source tool and generated also as a widget.
.
In the same year we did also more. We integrated RIPEstat into RIPE Atlas. For example, if you are going to look right now at the probe traffic or at all of the building measurement graphs, that's all coming from RIPEstat.
.
Another very important widget that I think it's worth mentioning here was the country routing stats widget that we added in the same year, and country routing stats is a widget that has been numerously referenced when it came to Internet outages, monitoring of Internet outages.
.
From a usage perspective, in this year we hit the first 1 million requests per day. Then we are going to skip those years.
.
And I was almost about to skip 2017 as well, but not without to give you a small sneak preview on this wonderful piece of Internet art that was created by Job Snijders with one of the widgets that we have on RIPEstat, but you will hear all about that in the MAT Working Group session.
.
Then we are going to skip 2018 as well and we are going to arrive at a very important year for RIPEstat: 2019. We had a dedicated UI engineering joining the team and that created a foundation to fundamentally start a rework on our new user interface, but you can hear about that also a bit later.
.
In the same year, we also increased our outreach and we worked together with other RIRs in order to create regional representations of RIPEstat, the first one was done with APNIC. That resulted in the tool net objection in May and in a bit later we added info raters (?) with LACNIC. This was the first user interface of RIPEstat that was supporting three different language, so it was English, Portuguese and Spanish.
In the same year, we also hit this record number of 100 million daily requests, and it was basically at around the 19th September, and just two months later we were hitting 130 million requests. This year was really many records that we broke, but after that we also got less obsessed about talks, because they just kept increasing.
.
Then last year, in March, we added the collaboration project with AFRINIC and that was the African Internet registry and routing statistics. And then, in March, the pandemic hit and we could not directly travel as much as we did before and we focused more on features. Okay, that was the joke, but as a result of the work that we did on the user interface, we released the new user interface as we did at the last RIPE meeting.
.
Then we're going to arrive at 2021, we are obviously at the ten‑year anniversary of RIPEstat, and something that will come up during this RIPE meeting is that we're going to release the new user interface as a production ready and a full user interface. So there will be more about that on Wednesday with the session and also with parts that we are talking in the MAT Working Group session.
.
Then to provide a bit of an outlook of what we are planning to do in the next upcoming years.
.
So, first of all, at this RIPE meeting our focus is purely on the new user interface, and right now we want to shift the focus a bit more onto the infrastructure and also onto the data API. So that's why we are trying to extend into the Cloud and we are trying to improve the data API. At the same time, we also want to ‑‑ BGPlay I think after 80 years of service. And we would like to open source of widget API since we are switching over to the new user interface, and we also don't want to completely abandon the widget.
.
We will also look into machinery a little bit and we will focus more on collaborations as well.
.
Then, I am almost at the end of my presentation. There are three topics that are very dear to my heart. First of all, the spelling. For the obvious users, you probably have seen that there is RIPE space NCC, RIPE space database dB, RIPE space Atlas, and so on but there is RIPE no space stat. Although I don't have an explanation for that, that led to a proliferation of different spellings, and there are reasons to be confused about that. But just for the sake of clarity, that we really mean ‑‑ that we really see when you mean to reference the service, we would like you to be more mindful when you are using the spelling, because it's simply also easier for our users to identify that.
.
Talking about users. I think this is also a good point to thank our users for the ten years of sticking with us and also helping us to create such a user base. What you are going to see here is a selection of feedback that we got, and before you wonder this MPS is a measure, it's for RPKI that's been used in marketing, which is the net promoter score, and that's simply a measure on how likely that you would recommend the service to a friend or our colleagues.
.
And then I think a tool is only as good as the people that are working on that. At this point I would also like to thank the team. I am very proud on what was done in the past three years, and if you are going to look closely at these picture, then you are going to see that Olag, who was usually a very cheerful person, looks a little bit grim, that was also a reason because the team is not complete and we are looking for a full stack software engineer with an affinity for back‑end development and data sites. So we are hiring in the next few days, there will be an advertisement going out, please keep an eye on the chalk board if that is your calling or if you know someone that would fit into that.
.
And with that, I am done, and I could receive some questions.
WOLFGANG TREMMEL: Thank you. I do not see any questions, and we are a little bit pressed for time anyway. So thanks for the presentation. I am a user of RIPEstat as well and I also promote it if I'm talking to other engineers. So, you know that.
.
Next one up is Marco, also of the RIPE NCC, and he is going to talk about the NIS 2 status update.
MARCO HOGEWONING: Good afternoon, colleagues. Hello, my name is Marco, I work for the RIPE NCC, I manage a small team dealing with public policy and Internet governance, these days. I'm going to talk a bit about NIS 2, and I realise that I'm in between you and your fridge, so I'll try to keep it short today. If you want to know more about the history, you can actually look back and you'll find that the first presentation on this topic was done in RIPE 74 in the Anti‑Abuse Working Group where the Dutch government already presented a bit about it.
.
So, what is this about? What is the network information security directive? It came into force in 2018 and when it did, it was kind of presented as the first European cybersecurity law, and what it aims to do is to address cybersecurity issues with that might exist or could exist within critical infrastructure, and critical infrastructure, you are usually talking about the big five, so it's finance, energy, transport, healthcare and then telecoms. Not as much the Internet, but, of course, these days, everything relies on the Internet, and the main idea between ‑‑ behind the NIS directive is to make sure that small disruptions or small hacks don't lead to massive cascading effects that could lead to economic and societal effects. We saw this over the weekend again, where ransomware attacks basically disabled the whole healthcare system in Ireland, so this is really important.
.
Crucial to this is a directive. That means that national governments, the member states have to implement a national law, and also the national states, the member states can appoint what they see as operators of essential services. So, those people, for instance Internet exchange points or domain name registries where they say like Y, yeah, if these people have an outage, there is an effect on other larger players and that could cascade into large problems with the economy or with society.
.
When this came into force, the Dutch government approached us, we had a bit of a chat about whether the RIPE NCC, as the k.root operator, would be one of the essential service operators. The end of that discussion was that they felt it wasn't an added value to put us under this regulation and, so far, the decision has not been made that we are an operator of essential services, and therefore we are not in scope of this directive.
.
Then, last year, the new European Commission starting on a new five‑year mandate proposed an update, and with an update they basically came back and proposed a complete rewrite of the NIS directive. They argued that it was a bit of a scattered approach with all these national governments doing their own thing and they needed better alignment to make sure the internal market worked.
.
Several key changes there, but, most importantly, it said that the member states no longer have to decide who is essential and, instead, this new proposal comes through with a couple of annexes that define categories for essential and important entities. So if you are in, you are in. If you are out, you are out.
.
And that effect was very noticeable on the DNS, and paraphrasing a bit, but essentially if you operate a DNS server, you would be in scope of the proposed directive.
.
Then, of course, it also means that us, as the route server operator for k.root, would be in scope, and effectively it names route servers specifically, and it wouldn't only apply to us and Netnod as the European operators, this directive just is the BSA, just as DMA is designed to work extraterritorial, so it doesn't matter where you are, the crucial bit is, do you deliver services to the EU or to EU citizens?
.
So, yeah, our position on this too. Well, we don't like it. That's a natural response, nobody likes to be regulated. But we don't like it for a very specific reason, and that is that if you start legislating on something crucial, something core just as the DNS route, you are kind of undermining your hiring the multistakeholder model and you risk fragmenting the Internet, and by that we mean, like, yeah, if the EU now goes ahead and says, oh, yeah, we are going to legislate on the route, it might inspire other countries to do the same and, before you know it, we have got 190 or so slightly incompatible pieces of legislation that all say something about the route DNS, and, with that, you kind of create a patchwork of 190 slightly different Internets that may or may not be interoperable.
.
We took that view, we explained our view to the Commission, in direct conversations, we made contributions to the feedback process. The consultation is ongoing. We have also been talking to member states, and, more recently, also to members of the European Parliament, so, like, this, this is really a problem here, not only just because we're regulated, but, really, if you look at how this is done from a multistakeholder perspective, this isn't good.
.
Actually, lucky, talking to one of the lead MEPs on this dossier, he kind of understood our argument and with him and with his staff we worked on some amended text that addresses our concerns. And very much it would remove the root servers out of scope. It would also remove a lot of the small players out of scope that was a concern that was brought up by the RIPE community saying yeah I just run a DNS server for myself, why would I be regulated?
.
More importantly, not only do they take it out of scope, but the justification for taking the route servers out of scope also make is very clear that saying like yes, you are kind of going contrary to this issue of having a single open new free secure network. All these lovely things Europol say we stand for, we stand for the multistakeholder model.
So, where we are at now: This is a proposed amendment. It still has to be agreed within parliament, so we're currently trying to get hold of parliamentarians who can influence the decision and make sure that they understand why this is good. If that subcommittee agrees to this report, then it would go for formal vote. That's probably a formality once all the parties already agree to the amendments. If this comes true it's going back to the European Commission say hey we propose some changes.
.
Technically they could just say okay, sure, we'll accept it but more likely what this will then result in is a so‑called try log process where the submission, the parliament, but also the Council, the member states basically sit down and work out the remaining differences and find a compromise on all this.
.
With that, we came a long way, we have an alternative text. We have an understanding that the roots, shouldn't be legislated but we still need quite a bit of time with the Commission, with the member states, to support all those changes if parliament agrees. So that's what we're currently working on.
.
There will be another discussion, I believe, in the DNS Working Group on Wednesday. Unfortunately, I am not able to attend. We have also had discussions in routing and we have discussions in cooperation wording. And I believe we still have a few minutes for questions, so I'm happy to take them now or otherwise I would recommend taking them to the Cooperation Working Group, where me and my colleagues are watching and can answer the questions.
.
With that, are there any questions?
FRANZISKA LICHTBLAU: We actually have some questions in the queue. The first one is by Dmitry Kohmanyuk, Hostmaster. He says: "All too frightening, can you suggest any actions for non‑EU membership communities to take on this?"
MARCO HOGEWONING: That's a really good qustion. We have seen that also in the feedback process, the European Commission is open to views from all stakeholders. So, for instance, we also saw responses coming in from the Japanese route server operator and we also saw American companies comment. So if you really think this is a concern, please do reach out to the European Commission if you can and try to explain what the harm is that they are doing here, and I am saying especially if you are in the EU, please do reach out to your local MEP and say, like, hey, this is going the wrong direction.
.
But as far as is the process is concerned, this is now really a matter of the EU members and the European Parliament... this is not a European problem, this is a global problem and it needs to be solved on a global scale.
FRANZISKA LICHTBLAU: We have about three minutes left and already four questions in the queue, so I'm closing the queue as of now.
.
And we continue with Alexander Isavnin from Moscow University: "Does the RIPE NCC analyse other local and apparently Russian, Central Asian, Turkish or Arabic or remote US China legislations? Does the NCC expect issues from extraterritorially regulations from those legislations?"
.
MARCO HOGEWONING: Yes, we do keep track, and if you look at RIPEstat, you'll see my colleague Atina from our legal department has just published and article that the addresses some of these concerns, and again where indeed we echo to say like this needs to be done on a global scale, this needs to be done on a multistakeholder level, because, yes, with DOH see the threat of diverging legislative initiatives. It doesn't even have to be extraterritorial. We do see different laws applying to different members and we do have route servers in member states, not only in the EU, so this is definitely of concern and, yes, we are watching.
FRANZISKA LICHTBLAU: So if anyone is interested in that, they should go ahead and contact you about that.
.
Jan Zorz is asking what exactly they are trying to regulate and how do they envision this in real life?
.
This sounds to be like a longer conversation, maybe you have a short answer to that.
MARCO HOGEWONING: The short answer is, we don't know the details. Some high level, for instance, say that yes, the management body, aka the board and the C suite, should receive cybersecurity training. It also seems to be that they might want to look into your supply chain and, for instance, go down the path of saying you can't use equipment produced by certain vendors. But it's a very high level at this stage, if it comes into force, the details will be worked out with the competent authorities and that will probably be a custom job.
FRANZISKA LICHTBLAU: Let's tackle the last one. Carsten Schiefner is asking regarding DNS, so small DNS and route operators are likely to be off, hopefully, who is still in? I'm not entirely sure what he is referring to.
MARCO HOGEWONING: Yes, you can look up the actual text in my mail to the Cooperation Working Group, but it currently seems to be aimed at people who actually sell hosting DNS zones. So actually sell that as a service, would probably still be in, depending on the scale. But I am not a lawyer, and I really recommend, if you are in this business, talk to your lawyers and see what the actual amendment text would mean to you.
FRANZISKA LICHTBLAU: Okay. Daniel Karrenberg from the NCC is referring some comments from the chat. Some people in the chat were wondering what the timeline on NIS 2 was now, for example the trilogue, etc., when will it be passed? That was the last question.
MARCO HOGEWONING: Parliament is going to discuss these amendments within the ITRE committee on May 27. The Commission I think is still hopeful that they could have something hammered out in trilogue by the end of the year. I myself have less optimistic about the timeline. It could be next year, but, then again, we have seen, for instance, ePrivacy, which got stuck for five years, so we really don't know at this stage. It could well never happen.
FRANZISKA LICHTBLAU: Okay. So thank you, Marco, for that exhaustive update on a very, very important topic.
MARCO HOGEWONING: Thank you for having me here.
FRANZISKA LICHTBLAU: And with that, almost exactly on time, we conclude the Plenary sessions for this meeting. I hope you have enjoyed the presentations and you are motivated for a productive meeting week.
.
A couple of housekeeping items again.
.
You can still nominate yourself to work with us in the PC until tomorrow at 3:30. Just send a mail to pc [at] ripe [dot] net. You can also vote for the PC members starting tomorrow, so if you log in with the RIPE NCC access account, you can go to the meeting website and vote those people who have nominated themselves who I think, we have two seats open so you have two people you can vote n please rate the talks, again cannot emphasise this enough, we really need this ratings and we take the ratings into account for the next meeting.
.
I don't want to keep you from your coffee break. Next up is, in half an hour, the SCION BoF where they are actually proposing to form a SCION Working Group, so if you are interested in that general area, please join us there, listen what they have to tell us, let's engage into a discussion and with that. Thank you for attending today's Plenary session. Good‑bye.
.
(Coffee break)
