RIPE 92
Plenary session,
Main hall.
Tuesday, 19 May 2026
9 a.m.
OSAMA AL‑DOSARY: Good morning everyone. Thank you for showing up so early. Welcome back. Today we have a group of sessions, before that we have a few announcements.
The first announcement is that the PC elections nominations will close today at 3:30 p.m. So, please remember to send it in.
Also, the second announcement is that the deadline to register to attend and vote in the NCC General Meeting is Wednesday at 2 p.m.
And with that, we will start with our first session. I'd like to welcome Thomas Weible from Flexoptix.
THOMAS WEIBLE: Thank you very much. Good morning everyone. I am your yoga instructor for this morning agency session. So we do some morning yoga, to wake up.
No... actually, I am not the yoga instructor. I am pretty sure everyone of you already made an experience, you meet someone you have a great conversation about a certain topic, then later on you think hey, this is something I want to know more about, and then you dig into that topic and you figure out that's not so trivial or easy, but I really want to know why is this to critically important whatever.
Actually, this happened to me last year at the RIPE meeting in Lisbon. I had a great conversation with Blake Willis, who is sitting here, it was really a great conversation in the evening at the social.and the topic we were talking about was about coherent transceivers, coherent detection, colourless, all those buzzwords. I thought hey, that's something I need to know more about and I took it back to the company, I am the CTO and co‑founder of Flexoptix and discussed this with our engineering. And we came up with this topic today about, we call it channelmania, because we thought hey, this is coherent detection is something which is also helpful for you guys when you plan and design your network, especially in the area of DWDM beyond 400 gig and the path. For the next 25 minutes, I will show you a little bit what we discussed there and what we figured out and we did some research on it and it turned out at the beginning it was a real brainfuck but then later on it turned to something else.
First of all a transceiver in general I am pretty sure you are familiar with those components so far in the last year since you know me. The inside is straightforward, we have a transmitter and a receiver. There is a digital processor which basically does a couple of functions, modulation, forward error correction, etc., so there is a little bit of electronics involved but now let's focus on those two golden boxes where all the magic is going to happen. We start first with the transmitter, in general when we look a bit back in history the transmitter, we all rely on lasers but they have been around for a long time, in the sixties they were evolving but those were big boxes, he had into a a lot of power and cooling to keep the frequency stable. And the interesting ones which are important for us in telecommunications have been developed in the 70s because these lasers were capable to operate at room temperature. I assume you don't want to cool your router with liquid nitrogen so you want to use fans or upcoming years maybe some water.
.
So the goal was to make them small, to make them efficient and operate them at a certain proper temperature.
And for sure to make them reliable and last for a long time and keep the wavelength very stable because that's one main characteristic of a laser.
When we look now at different type of lasers, we have seen in the last 15, 20 years coming up for transceivers for transmitting. On the top one, the purple one is a typical spectrum of an LED. It's roughly 100 nanometre wide, the spectrum, it's a very broad curve.
Now with 10 gig the laser characteristics are those two peaks next to the centre peak there the line width got down to 10. The green one, the lower one, the distributor, we cut down to 1 nanometre. Really important for 100 gig and so on. But when we go beyond 100 gig, let's say 400 or 800, especially when we want to do some coherent transmission, the internal cavity layer is important. We don't talk in nanometres any longer because the line is so narrow we are talking now frequency. So it's only a frequency of 1 megahertz which is very, very sharp. Compare it now with the 1245 gigahertz of the distributed back laser, this is like a factor of 1,250. That's very, very narrow.
But again, when weapon also look how you want to achieve more traffic or more bandwidth within your fiber, there are basically two approaches. When we look at the top 1, this is the typical way how we encode content or how you do transmission.
So you have a ‑‑ an optical carrier in the middle, next to that we have with the optical bandwidth where you put the information content in there. There are two ways to separate this. On the left side, there is the typical approach we have done so far in DWDM, or in CWDM networks, we separated the different colours, we sliced them down we used the filters to separate the colours. The drawback on this separation is the more you slice down you will always have a loss spectrum which you can't use especially when there is overlap. So there is always lost spectrum or lost information content which you could use but you can't.
So the other approach is, well, just increase the overall information content you feed into one optical carrier, just make it broader, use more bandwidth. That's actually later done with coherent transmission.
Now, that's so far the easy part. Now let's get a bit back to where we have been last year, my talk about complex numbers and general coherent transmission.
We have to look again a little bit in the modulation. The traditional approach is on off keying, quite simple and straightforward. We have light, we turn it on and in the middle you see a receiver, when diode gets hit by light. The current is going through we get a one, when there is no light the diad is closing and we get a zero. That's basically on slash off keying is working in traditional up to 100 gig let's say, or 40 gig how we detect a signal.
When we look inside of our on zero and one light level, there is way more information in there. We have phase information, we have frequency information. But for the diad itself this is transparent it can't detect it. It's information we want to pull out which makes coherent to take care of all the light parameters, so, efficient actually.
So, we want to pull that out. For that, we have to go back again to the constellation diagram, no worries, I won't dig too much into details. But we have those 16 cons instillation points and each can code up to 4 bits. The great thing that those points is when you look at the diagram they are located somehow in space to they also a direction or a position or what we call a phase information because when we remember our high school time, when you have this circle where we have 360 degrees, so we can actually identify every single dot with its phase with this angle where it's located.
Looking now on the right side when we pick out two dots in particular, there are two approaches to identify the position of such a dot. Either we use the phase information, the angle and the vector in general, so we can identify the dot or again this is a little bit geometry, we use the INQ component, in other words the X and Y to calculate a rectangular triangle. And the Q and I component that's something we are look to look at later, it's basically the foundation for the DSP to calculate then the position of that dot.
So, let's move on.
So, how does this receiver in general look like? Because I said at the beginning, the coherent receiver or also balanced receiver is something which is very specific and very important for the coherent detection.
Let's start easy on the top one you see a single ended receiver and how is the setup done? The central opponent is in the middle, it's the optical coupler. This is quite straightforward. It has two ingress ports and two out egress ports. So, on the incoming ports we feed in two singles. The first one is our optical carrier with the information content which we get from the counter part transmitter, that's encoded in there with our optical carrier in combination and then on the second incoming port of the coupler, we also feed in a second signal, the local oscillator. For the local oscillator we'll mention later on some words, but, so we fit in both singles into the coupler and it has a couple of great characteristics.
The first which is quite helpful, when we combine two singles and especially the optical carrier on the local oscillator, they will eliminate themselves and just the information content or the optical bandwidth is the outcome and that's something which we put, so combine the orange and the green arrow, we feed that to our receiver diad and can detect it. We call this a down converted signal because we got rid of the carrier on very high frequency, and we're getting down to gigahertz and that's something we can detect.
That's a single ended receiver in general. As you can see this coupler has two outgoing ports and when we look on the balanced solution on the lower one, it looks pretty much the same on the incoming ports, we got both signals, we combine it, then on the outgoing ports we have two receiver diads. And the coupler has another character stack because we have phase information in the light. It does a face shift of the cross port. So, the lower port on the left side from the local oscillator is phase shifted by 90 degrees for the upper right port and the same happens to the optical carrier on the top left port down to the right lower port, it's also phase shifted by 90 degrees.
When we have two times 90 degrees of phase shift we have 180 degrees in total and the great thing there is back to physics in school, when you have two waves which are both at the same peak and they overlap they are going to accelerate them to a higher level. That's amazing, and that's actually happening to our down converted signal as well. So we boost it up so it's basically amplified just because of the fact that we have a phase shift of the local oscillator and the optical carrier.
And we get more output and less noise and that's something very, very helpful when we want to detect signals. The drawback is you need two receivers to do this. But this is not the end.
Now, we detected so far the signal in general but as I said at the beginning, we have more information in there like phase, polarization in the light and we also want to get around that information. Now we are coming back to the ING component which I showed at the constellation diagram where we do the position of the dot where does it belong to.
And that's pretty straightforward so we have now instead of one coupler we have two couplers, and on the income side the signal is split up to the I coupler and the Q coupler and the local oscillator, one leg is fed straight into the coupler on the top one but the lower one is phase shifted by 90 degrees as well. The local oscillator, and with that, we couple is, we can now distinguish now the I and the Q component and with that we get the phase information out and can identify the dot within the constellation diagram where it belongs to. We have now four receiver diads, that's important. But we got the INQ component and get some matix for the DSP to calculate. With that we call this an optical hybrid. As we have polarization as well, polarization in general when you put on the sun glasses we typically, it filters out one polarization direction to filter, protect your eyes. The same does with the transceiver, we take the signal and now we split it with a polarization beam splitter and rotator and split it in two optical hybrids and each hybrid identifies one polarization direction. So, that's how we basically do it so in total, we end up with 8 receiver diads, and here we go we got phase information, got polarization out, and we basically did our constellation diagram properly calculated.
So, with that, we then figured out okay, this Brainfuck now mainly turned into somehow rocket science, this is getting very, very interesting. So let's build a rocket with that because when we have this information now we can do really, really interesting things looking in our DWDM network again.
First of all, a little bit of recap. When we look at the optical bandwidth, what we consume so far and what we need. So on the top left diagram, you see a typical curve for 400 gigabit signal, it assumes roughly 75 gigahertz of optical bandwidth and looking in the upcoming standards for 800 gig, it's basically double the amount of optical bandwidth, we need 150 gNMIc hertz, or we stick to the modulation of dual polarization, 60 qam, and for 1.4 terabit we need roughly 300 gigahertz of optical bandwidth to encode in there.
The great thing is we all feed into a filter scheme and, we figured out, together also with Blake, that the 400 gigahertz is somehow a proper filter to do so to get all the 75, with 400 gig, 150 gigahertz, so even 300 gigahertz with 1.3 into a single filter. How would that look like?
.
On the left side you see the traditional approach when you did slice down with a couple of 50 gigahertz filters in your 10 gig bet network so far. So, and he up ended up roughly with the maximum and the C bend of 96 channels, quite a lot when we look at 400 gigahertz channels we only get 12 is channels in the C band, which is not a lot. The insertion loss of such a simpler is very, very low, we're talking about roughly 2 dB, or 2 decibel for the insertion loss of such a filter. When we dot MAT and squeeze in 1.6 terabit in a 400 gigahertz slice, you end up with roughly 15 terabit for a single pair of fiber which you can put on those two efficiency. Which is pretty sufficient in these days, I assume so.
And maybe some words about COTS. That's commercial off‑the‑shelf. That's what we say, well this is commercially available. For sure you could also say we do a 350 gigahertz filter, but this is more expensive. The other one is straightforward to build a filter like that. That's basically what our approach was, to say that's more efficient. For sure we lose a bit of spectrum, but you will see later on we are going to use that anyway.
Now, coming back to the down converted signal because there is some magic happening in there. And also it's helpful to understand how this down converted signal has been achieved because we want to understand the colourless.
First of all, there are a couple of approaches. The first one is called heterodyne. You have the local oscillator on a frequency. In this example it's 192.7 terahertz. The optical carrier is running a lit bit with an offset of roughly 600 gigahertz offset. Or in nanometres, 1350 nanometres.
Went we bind them together, we get a down converted signal because you basically deduct the local oscillator from the optical airier, the terahertz minus the terahertz. You get an intermediate frequency of 622 gigahertz. This is just an example. Looking at those figures, this is a very high frequency and especially when you want to detect this on the electronical path with the diad running at 622 gigahertz is not impossible, but in a small form factor on a transceiver it's very tricky to detect 622 gigahertz and it's costly or way too big to do so. So the heterodyne approach is not very helpful.
There is another draw back, when we combine in the coupler the local oscillator together with our optical carrier, we also get a mirror frequency and in the negative path, we don't want that mirror frequency because the bigger the intermediate frequency is the more the probabilities is way higher that the mirror frequency is going to be in the neighbouring channel and there it will be interfere with the signal on the neighbouring channel. So we don't want to have to mirror frequency or we want to have it as close as possible to our actual information content.
So, that's the second approach.
Looking at the homedyne one. Take the local oscillator being exactly on the same frequency like the optical carrier and when we deduct them, the numbers, then we get an intermediate frequency of zero gigahertz. Detecting zero gigahertz for a diad and electronic behind that is simple and easy. Getting such a precise local oscillator matching exactly the optical carrier is not impossible but it's again costly and not feasible to build into a transceiver. You need something like an OPLL, an optical face loop, and this is not what you want to build into a transceiver. Now you can imagine there is a third way to do. It's called the Intradyne detection.
We say well the local oscillator, we bring it it is lows as possible to the optical carrier and the mirror frequency within our band of our 75 gigahertz bandwidth, so it doesn't disturb the neighbouring channel, and then when we do the calculation for our interred frequency like in this example, 193.4095 terahertz and we deduct the optical carrier with .4145, then we get an intermediate frequency of roughly 5 gigahertz. And that's something very easy to detect, small to build and cheap to build.
And even further, so, now you can tune your receiver on the electronical path you can either tune it to 5 gigahertz or say do some offset going to 4.5 gigahertz, and with that you have the capability or the receiver of the capability only to see the signal which you actually want to see and that's very, very helpful when we talk about colourless so the receiver can filter out in an electronical way which signal is intent for me. And which is not part and can discard a signal which is not intended for him.
With that we can build a rocket and go to the moon and beyond the moon there is a little bit more and I want to show you what's happening in the Union verse out there.
We call this DIN super channels. On the left side you still have this traditional approach doing slicing down the 50 gigahertz grid for your on‑off key. You can squeeze that into a 400 gigahertz filter. You can cascade this for sure you can have way more insertion loss. But the interesting part is happening now on the 400 gigahertz filter on the right side. Instead of just feeding in one 400 gigabit with 75 gigahertz, you can feed in four of those channels without separating the filter. You basically can put them into one simpler, you can add four signals because your receiver will grab the signal which is intended for him because you can tune to receive it to the desired colour, in this example for the blue or for the green. How do you want to separate? Again, later on on the physical layer, well, pretty simple, you use a splitter, a splitter known from the pun environment, it's a very are straightforward device, you feed in one signal and it distributes the same signal to all four legs, in this example you see this on the lower path where we have four different transceivers or coherent transceivers, and the blue coherent transceiver gets light, all four colours, but he only picks the blue light because he is tuned to that colour, to that frequency. The same happens to the green one, the green transceiver or receiver only grabs the green information content, and yellow and red, so on, as well.
On the top part, well this would be the traditional approach where we not use splitters, where we use filters to separate the different frequencies, but the lower one is quite helpful.
For sure there are limitations for that, you should do this only on your own fiber because you distribute the signal to all outgoing ports and maybe you don't want that your competitor or whatever gets the signal from, so you don't want the green one showing up at the port of the blue one for example.
And it's quite helpful as we are talking now in frequencies and when you talk to the radio guys as we have a shared media behind the splitter, it's better to make a frequency plan because then when you know on which line which frequency is popping out. There is other ideas where you can even build redundancy for example. When you think on the left side you have your core network with one transit provider or one transceiver in general and behind the splitter, you have two edge routers as an example. So, we have the blue edge router and the green one, and they are the blue one is tuned to the blue furnishing and the green one is more an idle and is not not connected on the blue wavelength but in the case where it's failing or having an issue and it's dropping the link you can tune in the green receiver into the blue colour. That's possible, you can just change the tuning on the command line interface, and then the green receiver gets actually the blue one and can pull out the information from the blue path in this example.
.
And with that, I am almost through. For me, this research was very, very interesting because it opened up a whole new universe when you design a DWDM network because so far, people were thinking in filters. Now, with splitters also in place, this makes it way more flexible, or in other words, you have built your own flex script basically with that legislature in a small way, or internally we also call this the roadmap for the poor people. This is a very efficient way to do it.
An important finding as well was for our self, do not think any longer in channel numbers, especially when it comes to ITU number, it's really a mess. It doesn't fit to the coherent transmission. Think in terahertz and gigahertz. It's way more helpful when you talk to your counterpart in terahertz around the gigahertz and not in nanometres any longer or even the weird channel numbers.
And with that, I'm pretty much through. And for the future also, what we see now for the next think coming up, we see also liquid cool transceivers where the liquid is going not only on the main board of the router or switch but also going, the liquid is going through the transceiver itself. Will they are coming up now with 12.8 terabit and with some interesting fancy connecters for the incoming and out coming liquid port to actually get the heat out of those transceivers. They are rated up to 40, 50 watts for a transceiver, and the current idea is to call them an XPO.
With that, I'm very happy to have been here and let's see what's happening tonight on the next social. I'm really open for discussion. Thank you very much.
OSAMA AL‑DOSARY: We have our first question.
AUDIENCE SPEAKER: Blake Willis, speaking for myself. This has been really helpful and an excellent discussion, I wanted to ask you if you had any other customers using fixed MUXs with a channel bandwidth higher than 100 gigahertz or if I am the only geek out there doing this.
THOMAS WEIBLE: Thank you very much for the question. So far, what we see when we talk to customers when we talk to their traditional WDM provider or transmission systems they are currently going up to 200 gigahertz, but so are that the 400 gigahertz solution we haven't seen in the plot set. So, the state of the art is 200, 250, somehow.
AUDIENCE SPEAKER: The 300 is the limit and it will just stop with 1.6 T there so that we don't have to keep getting bigger and bigger. Thanks. This is great
OSAMA AL‑DOSARY: Anymore questions. Next we have Saleem.
SALEEM BHATTI: Good morning to you all. My name is Saleem, I work at the university of St. Andrews, I am going to be talking to you today about some work we have been doing to change the way addressing is used to try and reduce some of the exposure of privacy you have might get through looking at address values. This work was originally started with my Ph.D. student, and the ongoing work is with these guys. With support from the ICANN grant programme.
Okay, so what problem am I trying to solve? A bit of background which I can imagine lots of people are familiar with.
So, for a long time over 20 years we have had guidance, if we are writing new protocols from the IETF on writing text about security considerations, but really I think it wasn't until the Snowden leaks in the middle of 2013 that people started getting more serious about privacy. And at that time it was flagged that perhaps address values that you can't hide as they go across the network can reveal something about users. So, there is the potential to know about a user or a nodes identity and its topological location from looking at these address values.
So, there are tomorrow potential threats from address visibility. You can correlate flows, so multiple flows with, for example, the same source address, you can assume are coming from the same sender, and that helps you perhaps build up a profile of the kind of things that user is doing.
Also, if there are some bits in the address value that get reused, as I say your phone, a mobile node, connects at different points in the network, well those bits, if they don't change you can track a user. So there is this general problem of identifying and at least topological location privacy with respect to what happens with address values.
Where are we today? Well we do have guidance now from the IETF about putting privacy consideration text into RFCs, which is great. Of course a lot of content is protected, so that is good. The privacy of the content at least is protected. And there is some work on trying to protect the address values as well. So RFC 8981 has some specification how to generate temporary address values that last from between a few hours to a couple of days and use the default being a day. But nevertheless, if you do follow that default for that day, you still have that same exposure. You can still have flow correlation for anybody using the same address using that day, you still have the potential to identify people's identity and their topological location.
Now you may say well that's okay, I'll just use my VPN provider, they can take care of all that for me. I don't use my real address, if you like. But it's a case of can you really trust your VPN provider? If you can, great. Stop reading now and you're done. But if you think you would like an option that's different, then this is what we're working on with my team at St. Andrews.
We're really looking at how you can change packet addressing to improve privacy. Of course we want to do without impacting routing and forwarding, without having to reengineer the applications and what we're really aiming for is another option to have a different model, and end‑to‑end model so your trust domain just is the sender and receiver, you don't have to rely on let's say a VPN provider to try and give you this identity and location privacy.
So, how have we gone about this? Well the work we're doing is part of a bigger project that's I have been working on for a while. I am not going to go through all that. But it's called the identifier location network protocol. It's a different approach so networking by changing the way that addressing works and at the moment we're building that directly on IPv6, so, if you like, you can think of it as a Superset of IPv6, it's IPv6 with a few bits added on.
So, how does this work? So, this is kind of ILNP in a nutshell but also specific to chaps with the privacy features we have been working on.
If you look at how addressing is used in the communications stack today, you have an IP address, an IP address is assigned to an interface, it's used at the network layer for routing and forwarding and of course it forms part of the end system state for a transport protocol.
So that means you have this entanglement between the layers and it means, for example, a transport flow is fixed to a particular network and so you have this binding between the transport flow and the address in a way that exposes this identity and topological location. So it would be nice to try and break that so you can that still have some end‑to‑end state for the transport protocol but you can have the forwarding state related to how the packet gets across the network separate from that that's what ILNP does. It introduces some data types for addressing. So instead of having an address, it has an identifier located vector, it consists of two data types, an identifier, a node identifier at the transport layer and this is for a node for a whole, it isn't attached to a particular interface. And then it has a locator. And I have labelled this a locator 64 L, you'll see later 64, that it's a 64 bit value when used with IPv6, so, that's why that label is there at the moment.
What we're aiming for is for this node identity to be stable for the duration of a single transport layer flow. And that means the end‑to‑end stays stable for the duration of the flow so the transport layer is happy.
And the locator, we're aiming to have end‑to‑end semantically aligned with whatever the network is expecting to be able to forward packets are properly. And then we have a dynamic binding between the node identifier and the locator, in fact it can be done per packet if you want. And we have a dynamic binding between a locator and a particular interface. That all happens at the end system. You don't see that, the user does not see that at all.
Okay so, this is what it looks like in terms of transport state. Here are two nodes, X and Y and they have got some processes running. You have AX and AY. If you look at the TCP state it looks like this. At X you have the local and remote port numbers. And then as part of the state, you have the local and remote addresses. So if you like, the forwarding state, what the network needs in order to forward those TCP segments is part of the end system state. You have to keep that stable, but at the same time, you are exposing some identity and location information.
So what happens with ILNP is you have identities, node identifiers, and a node can have many of these at any one time. And you have locaters, and again a node can have many of these at any one time. And the locaters are learned dynamically.
The node identifier has to stay stable for a transport flow, as I said, but the locator, you can change as you like for a flow in the middle of a flow. You could change it if you wanted for every packet.
So, the end system state looks like this for ILNP. The transport layer state still has a stable value to which it can bind its state at the end points, which is the identifier, then there is a dynamic binding to the forwarding state, the locator value which the network needs in order to get packets across the network.
So, how do these new data types get across the network? How does this fit into IPv6?
Well as good fortune would have it, you can just use the existing address space within IPv6 and in this diagram in the top, we have the normal layout of a global Unicast address for IPv6 and in the bottom of that diagram, we have what an identifier locator vector looks like for ILNP. So this is the combination of the locator and an identifier.
The top 64 bits have the exact same syntax and semantics as an address prefix. So, routers are happy. That's what they need to get your packets across the network. So they are not worried at all.
The lower 64 bits however, are not assigned to a particular interface, they use differently at the end system, and that's through modified code in the stack and that's what we have been working on at the end systems.
.
So, we're really using the IPv6 address field to carry the values for these new data types and the bindings between them change at the end systems to reduce this exposure of privacy.
.
In terms of what the network sees, if you were to put those addresses into packets, well on the left is the typical view that an IPv6 router has of a packet and that hand changed, it's just going to us auto the top 64 bits in the destination address to forward the packet and that is the same but when that packet gets to the ILNP system, it treaties those address fields differently.
So, that's how you have compatibility with what's happening in the network but you can change what's happening at the end systems to change the way that those address bits are used.
A couple of other features are required in the protocol so make it work. So a couple of protocol features. I am not going so spend too much time on them but you need to be able to tell the difference between a normal IPv6 packet and an ILNP packet. Will so there is an extension header in IPv6, a destination option header, it's eight bytes that that goes into every ILNP packet so that receiver knows this is an ILNP packet not an IPv6 packet. So it identifies it. It also provides some protection for some off path attacks. That's a subject for a different talk, but its main purpose is really for us there to say this is an ILNP packet.
Eight 8 bit value in there is a pseudo generated value which is unique for every flow.
And in order that two communicating parties can synchronise on the locaters they are using you need a handshake, so we come to the control plane and we have an ICMP V6 message, it's called a locator update where node A is talking to node B and it has a new net of locator values it wants to use, it just sends those values in a message across to node B and tells it, here are the locaters I am using now. So, A and B can synchronise on the locate values they are using and so B knows which sources to expect the packets to come from when they are coming from node A.
So, those are all the bits and pieces that you need, and a little bit of explanation of the plumbing.
Let's have a look at it actually working.
So this is on a lab test bed is what you are going to see. I have got a couple of videos coming up but we have tried this from IETF hackathons from different destinations around the world back to St. Andrews, which is just about 60 km north from here. Things do seem to work, but for the purpose of this used a lab test bed. This is what it looks like. You have two nodes. H1 and H2. They are running the ILNP implementation over IPv6 on FreeBSD 14, I am going to show you two experiments.
Both experiments use standard IPv6 applications. So they haven't been reengineered, they are just standard IPv6 binaries. Node 2, H2 doesn't do anything. It just sits there, it's going to act as the receiver. It's on a different IP v6 network to node 1.
For the first experiment we're going to keep the locator value, the address prefix the same but we're going to use ephemeral node IDs, we're going to generate a new fresh node ID for every single flow that we generate. We're going to generate eight flows just a TCP handshake so you can see that a new address effectively is used for each run, then just close the connection. So Netcat is going to be used to connect to the SSH server: You'll see eight connections go up and then I do a TCP dump, I look at the PCAP file, look at the source addresses and you'll see there are different addresses.
This gives you identity privacy. You can't now do flow correlation as easily because each address is effectively different. Yes in this case you can see that they have all come from the same network, with some other information you might infer that they are from the same node but just looking at the addresses you can't tell that at all. The node ID being different for each flow also protects the user's identity, because you don't have one identity for that user.
The second experiment I am using iperf as the tool. In this case I am keeping the lower 64 bits the same. This is for the ease of the demonstration. So this is retain the value 1A, B, C, D, and the locator value will change. So basically a flow will start up, after it's started up I'll change the locator value, so it will be transmitting over different networks. Now this is all in a single lab. So, I have a /56 which I have then broken down into some subnets and so you can see that the subnets only differ a little bit by value at that, the highlighted part of the IPv6 address there. So you'll see four networks, 1A, B, C, D, however in a real scenario those could be from different providers so they could be very, very different networks. It doesn't matter for the purpose of the test bed, these are the values that we have.
So, this provides location privacy. In fact, the configuration I am showing you again for ease of demonstration is just one thing you can do, but there is a lot of other things you can do now that the state for forwarding a packet is detached from the identity of the end system state.
So the L 64 could change for every packet. You could imagine two nodes who out of band have negotiated multiple paths between them and they have multiple L 64s and they have some sort of sequence of use. So you might have an equivalent thing that you have with something like frequency hopping spread spectrum where you go and spend packets in a predetermined sequence across different parts. That kind of thing now becomes possible.
Where you'll see is a flow is set up on one interface on a machine that's connected to one network. Then I turn on another one and it's connected to two networks and the packets go across both of those networks. Will then I turn off the first interface, and the packets are only on the second network. Then I turn on a third interface to connect to a third network and the packets will go across those two networks. I turn off the second interface so the flow is only on the third network, then I turn on a fourth interface that's going across the fort network. The flow has drifted across multiple networks. You can do this at whatever granularity of time that you really want to do.
.
Okay, so let's have a look at the first demonstration. So, these are just the two hosts. Host 1 and host 2, and so what I'm going to show you first of all in this video is just the little shell script I use. So this machine has four interfaces in this first experiment I only use one. It's just a simple use that uses Netcat to connect to the SSH server remotely, just sends, waits for one second an then closes down the connection. It only does the TCP handshake it doesn't do the full SSH handshake, that's enough for it to set up a connection and for us to see the address.
On host 2 I am also going to capture the packets and then look at the PCAP afterwards to show the addresses. I start the TCP dump running on host 2, then I start the script running on host 1, so there are the connections to the SSH server, and that's the script ended, and then I go and I stop the TCP dump and then I look at the SYN packets and the source address and you can see there are eight different addresses there, eight different NID values. Each of those flows looks like it's come from a different node even though it's come from the same node.
Next experiment is with iperf. Again there is a little script. I am going to quickly show you the script in the video. Again you are four interfaces, you only start with one so you sleep for 10 seconds after you have started the flow, then you bring up the next interface, you take down the first interface, you wait 10 seconds you bring up the next interface and so on. So you get the flow drifting across these different networks and I'll show you what that looks like in terms of throughput on a graph that's going to come up on the next slide.
Again I want to capture the data it hosts to so I am going to start a TCP dump just to capture the packets. Then I start the Iperf server on host 2 and then I'll start the Iperf client. Now if you are use to Iperf you'll know it reports the data rate. I have deliberately constrained this to 4 megabits per second just to keep the TCP dump capture small. You'll see there is the column with the data rate and the retransmission column as well right next to it, I keep an eye on that. There is a burst of retransmissions. So I'll say a little bit about that while this is running.
This particular mechanism for drifting the flow across different networks is not specifically for privacy, it's how ILNP does mobility and multihoming and multipath. As I say ILNP is a bigger project, it's looking at a different architecture for networking, so, in a way, you can think of this privacy mechanism as a side effect from being able to do mobility and multipath transmission.
.
But the TCP connection here is just the default TCP in 3 BSD 14 which is cubic running over ILNP so. It isn't aware that it's going over multiple paths. That's because of course with disconnecting the forwarding state from the end system identity. That's the flow finished.
So, I'll stop the TCP dump. Then I'll look at the addresses that are used, and what you should see are four addresses there, the bottom 64 bits are the same as I said for ease, it's the same node that is being used and we can see that the top 64 bits have changed as the flow has come across different networks.
How does this look like in terms of data rates on a graph? Here is a very simple graph. At the bottom you have the aggregate data rate that's measured at the receiver. As I said I set this at 4 megabits per second using Iperf. The four graphs above that are the different data rates that are seen by looking at the PCAP and looking at the transmissions on each of those separate networks. Right at the end there, you have got this little burst of retransmissions and that's because this is standard TCP, it isn't aware that it's running over multiple paths. There is a little bit of misrecording as the network change happens you move from one network to the other, and that triggers the TCP congestion control.
So, that's something else we're looking at with my team is to look at how we can do congestion control when you have multiple paths for a single flow and lots of other people in the community, research community are looking at that problem as well.
So, that's it from me for now. What we have here is the use of a different form of addressing using a ephemeral nodes identifiers and dynamic multipath flows. This gives improved packet level privacy because you don't see a single identity and you have multiple networks. Will so it makes the attacker's job harder. For example if they want to monitor a flow and you are sending it across multinetworks they now need multiple monitoring points and they have to collate the results. This can be used on IPv6 today with IPv6 applications. There are other possibilities, I have shown you the simplest thing for demonstration purposes but there are some examples of other things that are possible with this locator value, for example rewriting locaters within the network, if you want to. And that you'll see some details of that in section 7 of our RFC 6748. Lots of technical details in a couple of journal papers. The URLs are there for you, if you want to know more about in or about ILNP in general, lots on the website, but I am around all week, so I'd be delighted to talk to you. For now, thank you very much for your attention and I think I have some time for questions.
(Applause)
OSAMA AL‑DOSARY: Affiliation is just to give us a background of where you are from. Or your organisation.
AUDIENCE SPEAKER: I am from Sky UK. And yeah, it feels like all of this presumes there are no stateful firewalls in the path.
SALEEM BHATTI: Okay if a firewall decides it doesn't want to look ‑‑ it doesn't want to let the extension header through, then it's not going to get through. The places we have tried it mostly gets through I have a partner in India that's having a problem with a firewall upstream.
AUDIENCE SPEAKER: Not because of the extension headers but because of the state, you are not seeing a SYN come through, the SYN is already gone through and you are changing the location ID pathway through the flow and...
SALEEM BHATTI: That could happen, yes. Are.
AUDIENCE SPEAKER: Jen Linkova. Nobody paying for me being here. Just myself. No affiliation. I don't want to ‑‑ anyway, I am curious if first of all, if a host has a host /64 for example right, like mobile networks do and not just mobile, it might make your life even easier, you can change your bits for identifier on‑the‑fly, right? Okay, and the question I might have just missed it, you are saying you signal the change with ICMP?
SALEEM BHATTI: Yes.
JEN LINKOVA: What happens in it does not get through? Can we make before break or something like...
SALEEM BHATTI: Yes. So effectively, and you saw this in a little video, you have got a make before break. You have got effectively an IP layer soft handover.
JEN LINKOVA: If you are not getting confirmation, ou are not changing ‑‑ you need to make sure it was properly signalled and received.
SALEEM BHATTI: Yes, but if you lose the network, you lose the network. There is nothing you can do.
AUDIENCE SPEAKER: Okay. Thank you.
AUDIENCE SPEAKER: Greg Duals, IFC. The examples you are showing is using a transport like TCP but what about something like UDP and very short duration connections like DNS for example? And also, you know, it may be the case that there are policies in the DNS server that pretty queries from some users and not other users or want to treat them in a different manner or whatever they want to do. But it's based on the assumption that the source address for a given user is going to be the same.
SALEEM BHATTI: Right. So, we have not tried this for DNS. We have tried this for UDP flows but again longer lived UDP flows. Let's say you have got to a point where people thought we would like to use this, it would then mean that other things would have to change as well. So, if you have a service that is expects certain address values and will only serve those, this is going to break those. But then you also then perhaps don't have privacy.
AUDIENCE SPEAKER: Chicken and egg.
AUDIENCE SPEAKER: Lukasz from the university in Dusseldorf and I was wondering in what situations do you need to change these ICMP v6 packets to update the locaters? Is it always required or are there just certain situations?
SALEEM BHATTI: Yeah, any time the locator values change, you need to have that handshake so that the corresponding nodes where it's expectation the packets from.
AUDIENCE SPEAKER: In the example we have just seen there have been like every time you brought an interface up or down there was an ICMP IPv6 change in the background.
SALEEM BHATTI: Yes.
AUDIENCE SPEAKER: The other question I had is probably had the networks you were use for the locaters pre‑assigned to the interfaces you brought up and down. Will
SALEEM BHATTI: No. We waited for route investment to come in.
AUDIENCE SPEAKER: Okay. This means via route advertisement you can also dynamically assign these 64s, okay.
SALEEM BHATTI: Yes.
AUDIENCE SPEAKER: Thank you.
AUDIENCE SPEAKER: So, Saleem, regarding ‑‑ could you say in a few words the advantage of your solution as opposed to multipath TCP or QUIC?
SALEEM BHATTI: For multipath TCP is only works for TCP. Because this is done at the network layer it will work for UDP and anything else you want to build at the transport layer. For multipath QUIC, on my to do list to see how the new multipath QUIC spec compares with doing the multipath for UDP over ILNP. So I have a student project defined for that, I am waiting for a student, a suitable student victim to come along and try that out.
AUDIENCE SPEAKER: A suitable student. Okay.
AUDIENCE SPEAKER: Niall O'Reilly. Tolerant Networks. I am wondering what size of ‑‑ how big a population or how big a pool do you need to get the privacy advantage that you have been telling us about?
SALEEM BHATTI: Great question. Will if you look in that paper, the paper you propably want to look at is the second one, it tells you. But things start get getting pretty good at 4 different networks. And they start getting to the point where it's very difficult even for a hidden mark off model approach to analysis for things like inter package arrival times and packet profiles to work once you get beyond about five flows. So it gets to the point where, well the more paths you have, the better. But there is an analysis of this in that second paper.
NIALL O'REILLY: When you say four networks, you are talking of something the size of a /62.
SALEEM BHATTI: Yeah, yeah.
NIALL O'REILLY: The contrast I am thinking about is the difference between something on a campus network scale where that's clearly going to be doable on the one hand, and on the other the scale of my home where, you know, there are four of us in the house, we're all tied to the same /56, there is not a lot of anonymity going on.
SALEEM BHATTI: No. If ‑‑ if somebody wants to monitor your house or they know the network that's, that you are using at your house and they know it's your house, and they know there are only four people there, that's some additional information that they can then merge even with the use of ILNP to give them some further insight. If you have somebody just monitoring things on the network, and picking stuff up in the blind as it were without that extra secondary information, they can't get much further. So this isn't a total solution, it's making the attacker's job harder.
NIALL O'REILLY: What I'm taking away from that is at the scale of maybe a medium sized enterprise or a small university, it's already advantageous.
SALEEM BHATTI: Yes.
(Applause)
OSAMA AL‑DOSARY: As we heard yesterday from Hans Petter that the objective of stating your affiliation is for us to know you, it has nothing to do with who you are representing when you are asking, we all assume that you are representing yourself when you are asking a question. So it's just for us to understand you and your background. Thank you.
Now our next speaker was not able to come physically but will be joining us remotely, welcome Fredrik from Meta.
FREDRIK KORSBACK: Hello everyone: I hope you can see my screen as well. So, first thing I have to send my excuse for not being there in person and also on behalf of the company, we are a silver sponsor but we have nobody on site unfortunately but this has to do with some company policy that we will have layoffs this week, and when there is layoffs, nobody is allowed any business travel at all. So, it's a bit weird sponsoring an event where you can't be there in person.
Anyway, enough of that.
So today I want to speak about edge and backbone evolution. I am calling from Stockholm Sweden and I am the network strategy manager and tech lead for Europe.
To set the stage a bit. The Meta network consists of 32 origin data centre regions, one of them being close to where you guys are in Clonee outside of Dublin. We are active in roughly 90 POP markets. We place something called network appliances and today we are serving about 3.56 billion users or active people rather.
There will be three themes in this presentation. The first will be backbone and to set the stage a bit on what the backbone is. We have to talk about our two major backbones.
We have something called CBB or classic backbone, which is the data centre to POP, right, so that is where you upload a cat picture 15 years ago, they are stored somewhere in a data centre, when they will be served from a POP to you from there. This backbone is optimised the server up print it has diverse capacity requirements. Traditional network and it's a single plane architecture and it's built for to fit for scale. Which means that, you know, a small POP like Brussels maybe, would have a pretty small POP but a very big POP like Ashburn or Dallas would be very big. The the other network we have is express backbone which is the one that goes data centre to data centre. This is the big scale‑up backbone the one you maybe see in the news sometimes and when we go and build new cables and these things, it's typically for the EPP use case.
This backbone is very different because this is a multiplain architecture. It consists only of Meta software components. We use our own operating systems, our own protocols, and this is typically deployed inside the data centres and in some of the mid‑points. Mid‑points is a bit of a Meta word I guess, but it's backbone only sites. Good example could be Lyon maybe or ESBA in Denmark which is there is really no edge presence but we have a big backbone presence.
Looking at traffic growth over the years, it has been more or less flat or used a very small percentage of growth. However the EBB, which is the data centre to data centre has been growing exponentially over the last couple of years. It has a little bit it do with the AI world we currently live in but also other things is kind of pushing down the lower peer.
And in the next seven slides I will talk about how we scale up and the various methods of being able to scale a backbone of this type.
So, one of the ways you could do it is to build larger chassises, you go from an 8 slot to a 12 slot chassis. You could also increase the interface speed. Thomas talked about 400 and 800 gig optics on the presentation before had he and we are very much in this business that if we can change out 400 gig interface to say 800 gig we get essentially a hundred percent increase.
There is also this idea of scaling out. When we talk about planes, the easiest way to look at this is essentially another backbone. It's like when your first backbone is full you add another identical backbone next to it. And we have done this a couple of times. . We are already today up to eight planes, and have been for a couple of years actually. The reason for this is the boxes cannot get big enough. So, instead of just trying to make them bigger which we are also trying, we can just add more and more on the same side.
And if we're applying this to how we think about the network, over the years, we have been seeing this type of growth, where certain backbone paths had to be scaled 192 X for the last seven years, which is crazy to think about and one of the key methodologies that we use to be able to achieve this was ZR technology, primarily on the 400,800 gig type interfaces. Before we had ZR technologies with we were use traditional transponders, you have a router and you connect it to a transponder that converts the ethernet signal into an OTM signal or something like that. These require a lot of space and require a lot of power and also require all of the software stacks, all of the stuff that goes around it.
With ZR, which is the main technology we use in our backbone we put the DWDM optics directly into the routers as well and we can make the optical network pretty dumb. And to showcase this a bit better, we could take an example.
So this is a mid‑point or a backbone only site, quite typical for how we have traditionally built it, so rails it's a fiber pair basically so this is a big backbone site, fiber pairs, we do about 20 per fiber pair, a total system capacity here is roughly 1 terabit. In the good old days, this required roughly 58 racks. 50 being optical and 8 being routers.
When we swapped out to 4100 gig ZR we could trim this down to 13 optical racks and 8 routing racks. So 21. Now that 800 gig ZR is becoming commonplace we are down to six optical racks and down to 14. This of course saves space, power and money and basically, and ease of operation of building this way instead of traditional way with traditional optical vendors.
If you are looking at the metro. So it's very interesting. When we define a metro, it is at least in the data centre space we're talking about maybe hundreds of kilometres or something like that. Because today, especially in this new AI data centre world where we're talking about gigawatts, we cannot get all of this data centre space adjacent to each other. Like we can't put every data centre in Ashburn, that would be a bad idea. Between those data centres we had to come up with a new thing. Today that new thing has a name, it's called RBB, ring backbone network, but at the time these slides were produced it didn't really have a name. It was called AI backbone.
So when we go and build fiber for this type of networks, they look like this. You might think that this is a plumbing system for Amsterdam or something, but this is actually fiber trenches that goes between these AI backbone pairs, because in most cases we require hundreds of thousands of fiber pairs between these data centres to be able to build what we want built.
So, if the connectivity or in the data centre, if they are in a 10 km envelope we can use regular grey optics and we can use fiber instead. Then we can deploy a single 4100 gig or 800 gig link per fiber pair and we can reconcile with fiber it goes into these vaults because these data centres especially the AI ones, they require hundreds of thousands of 400 gig links between each other to fully operate.
If the activity is larger ‑‑ sorry, the range is larger than that, then we need to deploy DWDM. And then we're using the same methodology, but we're using still a lot of fiber pairs. And if we need ILAs, those ILA sites are becoming pretty huge. There is some interesting things or our public blog on how redesigned no ILA sites. As you can imagine if you ever build a DWDM network, if you are suddenly lighting up let's say 2 thousand fiber pairs with optics, that gets to require a lot amplifiers, you are going to need a data centre for the amplifiers. That's what's happening on there.
Just to give a perspective here. One site pair of these AI data centres, they consume about twice as much as our ‑‑ as all of the other backbone combined. So these AI data centres are consuming a lot of black hole for sure.
It's pretty crazy.
Okay, let's switch over and look a bit at the edge, that's what's happening there. This is closer to all of you.
What does the edge really do? It's one of the large Internet serving Internet structures on the planet. With thousands of peering partners, we are coming ‑‑ I hope you can see it ‑‑ we are in most places in the world. This is multi‑tier caching architecture which means that not all of these POPs are created equally. They are also serving each other from each other and we use pretty advanced both targeting and global load balancing to be able to pin users to the right hops so that everyone involved is happy. So we are happy, the ISPs are happy and the users are happy. And we try to optimise for latency.
And if we look under the hood of an edge metro it starts with the peering layer. The peer layering is more or less as you would imagine. It's a couple of peering routers, four, six eight or something like that, in a common facility that we all typically have our routers on. Hardware Exchange in London, or Size Park in Amsterdam, etc., and with this, we connect two major compute things in essentially every POP there is a caching layer so a CDN layer, that's where the videos come from and the images and embarrassing things you uploaded ten years ago to your Facebook profile, all of this comes from the caching layer which then of course gets it from the origin, one the data centres.
More recently, a lot of these POPs also have an Edge Cloud or a compute layer that is connected to it. It all kind of started with the gaming experiences and the Meta verse things but now, it's really all about the AI, in combination with those previous things of course, where at least the larger sites get one or multiple of these edge clouds connected to it.
And all of this sits together from an aggregation layer, to this is basically a least bind type of deployment. What's interesting here is the last three years, most of these things were sitting in one site, let's take Telehouse in London as an example. All of that was in a single cache but with the recent growth and with the recent kind of capabilities with GB use and stuff, most of these layers are breaking out into multiple sites because they all need different things. The peering layer obviously needs people to peer with. So putting the peering layer in a data centre somewhere out in the woods where maybe space and power is cheap and we can get the rack scaleability we want but there is no one to peer with so we can't really do anything. Same thing with the Edge Cloud, the Edge Cloud is, go through aggregation layer but it doesn't really need to be very close to anything else. It needs space and power and high density on racks, right.
So, what we're seeing in a lot of metros, especially Europe, is that these are breaking out into multiple data centres and we connect them together with DWDM and fiber.
And of course the backbone need access to wherever the large backbone paths are.
So, if we're talking about the hierarchy then. The data centre, that's the big thing, in Europe we have three, so we have Clonee in Ireland, and we have Odensee in Denmark and Lulio in Sweden where I am. And this is where we store all the information, stable images and do all of the data processing but the RTT users is very high, we don't want to search stuff from there if we can avoid it that's where the edge metro comes in, it sits in, in Europe it's in 32 or something like that. And that can, you know, cache 80, 90% of all content that people use, the popular reels, the popular images, the popular ads, whatever it is. And we have something called and MNA, now it's a Meta network appliance. These are deployed inside the ISPs. They cache the most popular stuff, WhatsApp call relays, all the new Tayor Swift videos obviously get published there so this typically takes out a lot of load and regularised peering points and networks because these can do 80% of the traffic give or take, depending on the market. So these are highly popular. These clusters could go anything from a 3 times one rack units to several racks of servers, depending on the scale you need.
So, really what's happening here, the evolution part is first, of course we have ‑‑ we call them multi‑peer MNAs, this is where we can deploy, it's been very popular in Africa where we can send an MNA into a country where we are not currently planning on building an edge metro. We can build these multipeer MNAs, it's like a micro POP but that sits in someone else's facility.
Lately, though, with AI and everything else happening, there is plenty of new use cases for us, like obviously you have probably seen the Rayban glasses, or the glasses that have a cameras that can do lots of things. There is metaverse use cases, augmented reality use cases and many many more things come from the team that requires us to put compute in the edge metros. And with compute here, that typically means a GPU or an accelerator is a new fancy word to use for this, where these are moving into the edge metro.
And really, what I want to say about that is edge metros are going to get more important for us going forward, because with these forward deployed MNAs the one that sits inside the IP networks, probably a lot of people in the room currently has this inside their network, they don't want to host GPUs because they are power hungry, so a lot of these AI use cases will be the edge metros. The latency required for a lot of these AI use cases it's not as high as people think. Looking at it from a European perspective, I foresee that we can serve 99% of our use cases from five to eight locations in Europe, at least for what we know now. The because there isn't any needs really for 10, 15, 20 millisecond, that type of low latency, for the AI use cases today because the compute latency is much higher anyway, so going, to trying to optimise for super low latency for this is at least today not very much needed.
To finish this off, I promise to talk about peering policy as well. I know not everyone in the room is super into this, but we'll go through it anyway.
So, the big takeaway from this is that we're moving away from route server peering, truth be told in most of Europe we are, since a few months, already out of the route servers, but this is not a changing peering policy though. We are still peering with basically anyone that wants to peer. And we want to reaffirm that smaller networks matter to us. And we want to explain how to easily peer with us as an IXP or however you want to peer with us and we are submitted to our network strategy to support the open Internet despite there are some spin doctors trying to make it look the other way because we're leading route servers.
So, the why. Why do we have an IXP strategy? We want to enable one to one connections with long tail networks because that's the primary use case for us with IXPs. And we want to make it secure, scalable and well managed. We want to maximise the value both for us and for everyone to peer with us.
So, typically, we operate two ASNs. So, our big ASN 32934, that's the big Meta network and for these appliances, so the MNAs, they typically peer with 63293. Our target is to have revel two IXPs per metro location in you're. We are look to go get a few more as the year goes online. If we had less than one IXP in a metro, we are typically looking to explore if there is a growth option, if the market is ready for it, and if people actually request it.
If there is more than two, we are probably looking to consolidate, which has been happening all over the world for the last year or so. I mean I think at one point we were connected to I think nine IXPs or something in Amsterdam which was quite cumbersome.
What we're looking for in an IXP is good governance and stability attributes. We want them to be relevant for the market and have some kind of growth and interesting network for us to peer with of course. We want it to participate as a customer as far as possible, we are members of 150 or so IXs globally, so and we are just a handful of people that does all this. We really don't have time or bandwidth to be able to participate very actively in the IXP and ports and these kind of things.
We are looking at 100 or 400 gig physical presentation. 10 gig is more or less sunset across the network. A 10 gig port is almost worse than having no ports at all unfortunately.
And we also don't want to have an obligation to establish route server sessions. For for the long tail then. We want to maximise the opportunity to peer with anyone. We want to empower thousands of smaller networks globally. It doesn't matter the size, right. Like if you are a mom and pop shop or a WIS that covers small little street or something in a rural area in England, we are happy to peer with you. We want to make it cost effective for everyone. We want to connect, one to one in many more place for more networks and bilateral enable the secure the performance and benefits for the both of us.
How to make it simple then.
We have an automated peering portal that does not require a Facebook account or an Instagram account or anything like that. The only thing that it needs is a PeeringDB account. You can go yourself to meta.com/peering, the requirements here is that you do have a PeeringDB record. And you can essentially follow the link, log in with your credentials and you will get all the automated work flows do the job. It's not really more cumbersome to have a route server session.
Just to show case how it looks like. This is the peering portal. You have a peering BD on off button at the top right. You can click that. Will and you do your thing on PeeringDB. And you authorise Facebook or Meta to be able to read your e‑mail for example, and to be able to do the sync on which comms you have. And you click here, you can request the public peering, you can request a private peering or you can request join the MNA programme which is the metric application programme, and it could look like this. Here we are trying to peer with 375 the 99 and it seems we are sharing a couple of joint IXs, so you select the IXs you want and you click start public peering and in a day or so, all those session also come up and we'll be able to exchange traffic.
So the takeaways here is that essentially, most IX sessions will be approved by automated work flows, there is no humans involved, it will just come up and everyone one will be happy. It does rely on PeeringDB, so if you are not there, you do not exist, right.
And this is not Facebook, right, you don't need to have any type of affiliation with any of our services at all to be able to use this.
We cover the update to the IXP policy, we can confirm the importance of the of long tail and we share to peer with Meta IXPs. We are around ‑‑ technically for this time is not true but in most cases you know that we're around, we are happy to talk and we are happy to drink a beer at any social of course.
Thanks for why are time ‑‑ yeah, just before we finish off, IPv6.
IPv6 of course very important for RIPE but also very important for us. We are an IPv6 first company and we will always try to serve over v6 if possible.
Since RIPE is in the UK, right now, I'm happy to show that, these our public stats by the way, that the UK is on the 11th slot here on global adoption. Still a bit a way to go up to India, which is absolutely amazing in running v6. And then to the left there you can see there is some countries that has 100 perspective IPv6 adoption and for antarctic lands, I am not sure, I think that has more to do with perhaps low sample quality other than that. But India is at least a real behemoth when coming to IPv6 deployment. With that I believe I have some time for questions. I'll try and stop the screen sharing so I can see all of you.
(Applause)
AUDIENCE SPEAKER: Mick O'Donovan. You referenced very early ‑‑ thank you for the presentation by the way, it was very good. You reference in your slides earlier around the power consumption of optical transponders versus ZR transceivers, have you done actual measurements on that in terms of the swapout and the power usage? Because obviously the routers that these ZRs are going into are still consuming more power as well so have you done a direct comparison at any stage?
FREDRIK KORSBACK: Yeah, I don't have the data off the top of my head now. But of course there's been a lot of ‑‑ because, in reality, with this, you are cutting away one type of link, otherwise you need to run grey optics between a router and the transponder be, so at least that part is going away then the transponder chassis consumes power in itself. So I can't give you a number off the top of my head exactly what it is but it's not only about power, it's also about space. Like these traditional DWDM kits take up racks and racks and racks, which we don't really have in these backbone sites.
AUDIENCE SPEAKER: I'm Will. I was wondering what is your consideration to go and connect to an IXP size wise because I am representing the small IXPs there, like the one that have like probably less than 100 gigs or 500 gigs of traffic so I am just wondering if you would why having devices in those small places in towns where you are not yet. Will
FREDRIK KORSBACK: We do have a couple of examples of that already. Mostly these multi‑peer MNAs, they go into emerging markets bike Botswana, things like that. In Europe, I think we have like five or six of them, where we have been able to find markets where first there is an IXP, there is somewhere where we can put it so there is some kind of data centre space and there is enough interesting networks that is local to that mark that can do it. I mean in terms of traffic volume, it's like 100 gigs, that's probably fine. I mean just for reference, the smallest cache we can deploy today is roughly in the 50 gig range. So, that's where we go like cost neutral more or less. So, we always look at basically everything on the IXP is who are they, what type of traffic do we have with them? We have excellent data, right, so we can see per ASN level how much combined traffic would this be and we're happy to evaluate that all the time and hopefully you can see my e‑mail in the PDF on the website and you can just give me an e‑mail and we can look at it.
AUDIENCE SPEAKER: Thank you very much.
OSAMA AL‑DOSARY: We have time for one last question.
AUDIENCE SPEAKER: Blake Willis. Thanks very much. Great insight into what goes in the back‑end sausage making. Would you say that your route server withdrawal is mostly due to quality reasons and not very useful prefixes in flapping an so on and so forth?
FREDRIK KORSBACK: Do you want the spicy answer or do you want the well published answer.
AUDIENCE SPEAKER: Rock and roll.
FREDRIK KORSBACK: There is a whole bunch of weird things going on with route servers. So the first thing is that nowadays we have route servers and route servers connecting our route servers to other route servers. And some operators are also using these route servers to artificially create something that isn't true. For example creating a very large AS code, and so that's one thing which I really don't want to motivate that type of behaviour. The second thing is also security related. There is a lot of spoofing going on on these route servers and there is a lot of weird hobby networks that tries to establish sessions and even though if we have firewall rules and ACLs, because, you know, there is whole IXs that are just filled a virtual networks that are just people's Cubernates machines peering with each other over virtual fabric and it is a lot of noise to keep track of all of this. Even if we have pretty good I would say traffic targeting where we're trying to figure out where people actually are, it's like when you are peering with us in Amsterdam, are you a Dutch network or are you at least close enough that we don't have any other better way to serve you? Then that's great. But today, with these network of route servers, it could be someone in, you know, southern Brazil, suddenly appearing in an IXP in Bulgaria, right. And that's not really productive and while we are trying with other methods to try to distinguish that right and try to serve them from the right place because in my mind if you are a network in southern Brazil, and you are only peering in an IXP in Bulgaria, then you should probably be sort of a transit in or your upstream in Brazil right and not necessarily from the other side of the world over some wet tunnel over seven networks. That's a rock and roll answer.
But I think a lot of people actually know, already knew this kind of in the back of their head.
OSAMA AL‑DOSARY: Thank you Frederic.
(Applause)
OSAMA AL‑DOSARY: For those that were not around earlier today, we have a couple of announcements. The deadline to register and attend and vote for the RIPE NCC General Meeting is Wednesday at 2 p.m.
Also, the RIPE PC election nominations will close today at 3:30. I'd like to just mention that the Programme Committee, we are always striving to improve. We appreciate anyone who comes up to us and tells us how things are going, and what they think of the programme. So anyone that has this kind of red‑ish pink‑ish colour on their tag, come up to us and tell us if you have any feedback. And thank you very much.
We will restart in about 30 minutes. Thank you.
(Coffee break)