RIPE 88
Plenary session
Main hall
20th May 2024
2 p.m.
MIRJAM KUHNE: Welcome everybody I see there are still people coming in, find a seat, there is still enough space to sit. It's a big room.
Welcome to RIPE 88. We are actually here for the second time in Poland, we were here in, exactly ten years ago I think for RIPE 48 in Warsaw, so I'm happy to be back in Poland, I am the RIPE Chair and we also have Niall O'Reilly, the Vice‑Chair in the room. He might still be talking to people outside. But, you'll find us later.
So, welcome everyone to this meeting here. It looks like we are going to have great weather, I heard there was a storm warning but apparently it's passing under us, so we are not going to be bothered by that.
We have here a number of statistics already. We had roughly 600 people are registered for the meeting from 49 countries and 100 people, newcomers are on site, and we also had I think roughly 300 people online, we are still going to update the statistics during the week and obviously at the end of the week we'll have some more data, but I'm very pleased to see so many of you come to RIPE 88, and I also saw quite a number of registrations from Poland, which is great, which is one reason why we are coming and to a country and why we are trying to move around the region also, to allow people to participate that maybe otherwise wouldn't participate.
I am also pleased to see that we have local hubs again. That was an experiment that we did last time, or like a pilot, not an experiment, so we are continuing to do this. So this time we have four local hubs which basically means that people got together in one location and have a little mini RIPE meeting and have the community feel and following the meeting remotely together, rather than just sitting at home kind of behind a screen. And I hope we'll hear more from them during the week, they might not all be there all the time but I might see them online.
Unfortunately, I also have to say again, you know, there is a lot of conflicts and wars going on in our service region, our region here, and I'm afraid this will undoubtedly have an impact on our communications and our community, our emotions, so just a reminder to treat yourself professionally and with respect, and be gentle to each other, and obviously we have a Code of Conduct that is in a very small basically says please treat each other with respect and tolerance, we want to have everybody feel safe and feel included, and we don't accept any imbalance, intimidation. So there is a longer Code of Conduct that you should all have signed up to or ticked the box or read when you registered.
Should you experience any, anything you don't like, any bad behaviour or something you think is violating the Code of Conduct, or you just feel uncomfortable with, we have a professional team of ‑‑ a professional Code of Conduct team in place for the RIPE community, and not all of them are here this week in person but they are, they communicate with each other and there are posters out in the halls so you can find them, and there is information you can also obviously contact them online. There is information on the RIPE 88 website on how to contact them, and they can also set‑up some secure communication channels with you if you need that.
This is the page of all the faces of all the wonderful Working Group Chairs that we have in place that are responsible for a bit more than half of this week also, all the Working Groups they have put together great agendas and I'm looking forward to some interesting discussions there.
Most of them will be here I think this week on site in person. And I'm looking forward to their sessions.
We also have the RIPE Programme Committee and they are mostly responsible for the Plenary Sessions that all take place today and tomorrow and then a bit on Friday as well.
Just to quickly go over some of the sessions here on the meeting plan, this is the meeting plan you'll see online. As I said today and tomorrow, they are mostly Plenary Sessions, and then there is tomorrow afternoon there is two Working Groups and then Wednesday and Thursday Working Groups and then Friday more Plenary Sessions and the Closing Plenary.
We'll also have two BoF sessions, one today and one tomorrow. All the information is accessible through the meeting plan, so if you click through there, you will find a lot more details also about these BoFs, and about all the other sessions for the week.
On Thursday, we have our, like traditional, when I say diversity and inclusion session again after the community session, Community Plenary, there is also a Community Plenary on Thursday, I didn't point that out but you'll see that on the meeting plan, and I'll get back to that in a bit. There is diversity and inclusion session is, it's different every time, sometimes we have lightning talks, we have presentations but we also have some great discussions, so please come and participate and help us to make this meeting more, or this community more diverse and inclusive over time.
So, maybe quickly going back to the meeting plan.
There are some discussions going on during the week, if you look at the Plenary and also the Working Group sessions, obviously there are topics related to routing, there are some presentations on IPv4, the end of IPv4, the deployment of IPv6. There is some policy discussions also related to IPv6 policies. There are some best current practices being prepared, and some of the Working Groups are being worked on which I think is really good development, we see more best current practices, because that's of course one of the product, the community can produce and can be ‑‑ have some useful output.
As a research in some other topics, you will find them on the agenda.
So, one topic that might pop up throughout the week is the relationship between the RIPE community and the RIPE NCC and the RIPE NCC Services, the RIPE NCC membership structure, and how the services are funded and so forth, and it might pop up in various places so one of the BoFs tomorrow is related to that. The second one here on Tuesday, building a stable future for the RIPE NCC. Then there is of course the membership, the General Meeting here on Wednesday, that green square, where this topic will be discussed, and then we also have sometime in the Community Plenary to maybe go over some of the details and what we can do as the, as a community, as a RIPE community.
Of course even you are not a member of the RIPE NCC, I mean we all, as a community, benefit greatly from the services that the RIPE NCC provides to us as a community, I mean they organise this meeting, you wouldn't have these meetings without the RIPE NCC organising them and sponsoring them also for a great part and they also provide a lot of services to the wider community.
And in fact, we have actually created the RIPE NCC some exactly 35 years ‑‑ well not, that's not true, 35 years ago the RIPE community started. In fact Wednesday, this week, 35 years ago RIPE 1 took place. So, we have a 35th anniversary this year, we might have some cake later in the week, who knows?
.
But one the things the RIPE community did quite early on is to create the RIPE NCC as its secretariat to provide some secretariat services like organising these meetings for instance and then later on it became also the regional Internet registry. And many of you know this but I think over the years we became a little the bit complacent and took it for granted, the NCC provides all these service that is we benefit from, and I think we as a community have to also think about how we appreciate that and support the RIPE NCC and support each other because obviously we are here as mutual supporters and dependents between us and the RIPE NCC.
But before we just dive into some of those serious discussions about routing and membership structures and IPv4 run‑out. I want to remind us all, maybe especially in this birthday event, this birthday edition of the RIPE community so also maybe stand still from time to time and think about all the great achievements that we have accomplished throughout the years. We have these two meetings a year, in the beginning three, now two meetings a year where we all come together. It's open to anybody who has an interest in networking infrastructure, and we have a common goal, that we work on together, and have some ‑‑ you know, take every coordination that is necessary to keep the Internet running, and then of course obviously we also have the community in order to build trust and social contacts and get to know each other and that's of course also important so that we can rely on each other in case of crises like for instance the pandemic or projects like keep Ukraine connected that could not take place or happen if you wouldn't, you know, have contacts with each other and people could just call and say do you have some equipment or some, you know, help us out. So that's one important aspect of course to ‑‑ the social aspect of this community.
But I want us to be kind of proud also of what we have achieved and not kind of, the world around us is becoming complex and hostile and polarised and I think we might sometimes forget to also be positive and proud. We have build this stable environment community, people look at us actually with envy sometimes for the self‑governance that we have set up over the years and also the tremendous source of resources that we combine and that we can also make available to others who are maybe joining the Internet today.
So while we further evolve and have these discussions during the week obviously let's continue our constructive discussions and our traditions of consensus building and finding the best solution for problems that arise.
And then of course also, amongst all this, don't forget to have some fun. Fun is important. And we actually have social events scheduled for this to facilitate the fun. But obviously you can also have fun without social events and can just hang out with each other. I had great fun already today. We had the newcomers tutorial. It's fun to see new people come in but just as a summary, there's a welcoming reception today and then there is networking event tomorrow afternoon, tomorrow evening, a great part tomorrow evening. And on Thursday, we have the RIPE dinner.
And then last but not least, I want to actually thank all the sponsors that helped us out here. And that's Akamai is the host and right after me you will actually hear Patrick Bussmann, the representative of the local host, say a few words, and the RIPE NCC is the diamond sponsor again, and we have AWS platinum sponsor, we have a number of silver sponsors, the list is here. And then the Internet Society is here. And we also have S‑net as connectivity sponsor, last but not least I am pleased to see PLNOG, it's the Polish network operators group. So thank you all for helping us out to organise this meeting.
I skipped over this because I think this is important to show. I want to show it again. 35 years connecting people and networks as the RIPE community obviously. And that's it. Thank you very much.
I hope you have a great week.
(Applause)
.
I didn't ask for questions but you can ask me anyway, any questions if we have time? No.
PATRICK BUSSMAN: Thank you, welcome to Krakow. That's about as far as my Polish goes, so don't try it over the next coming weeks.
Akamai is very happy to welcome you to Krakow. In case you don't know us, we are this tiny neighbourhood CDN security and Cloud company that has distribution halfway incidentally around the world.
We are highly engaged in RIPE, we are highly engaged in the operator communities all around the world, and with our new investments into Cloud areas, we are also giving back to the open source communities. So therefore we thought bringing RIPE to Krakow would be a very interesting adventure. We love the city and we have a good history here. So you might ask why Akamai as an American company bring everyone to Krakow. We have about more than 12 years of history here in Krakow and more than 1,000 employees, it actually is the third biggest office that we have globally and just in case you are interested, we have more than 60 jobs open at the moment.
I have got to do a tiny bit of promotion here so I can claim afterwards.
Two or three highlights that I wanted to spot because I think they fit very nicely and represent how we are looking towards the community as well.
Akamai, for the last nine consecutive years, has been called a great place to work in Poland, we are very proud on that. We are starting our seventh iteration of female chief, the leadership programme for women in Krakow in Poland, with the Akamai technical academy, we have two cooperations with the local universities where we are bringing newcomers in, we actually have a good amount of them here throughout the week. And we have opportunities for job changes where we enable people who want to join the industry to get educated to be able to join jobs in the IT sector regardless of whether they then join us or other companies. Obviously we have an opinion on that.
On top of that, as everyone else knows, the majority of the world, we're flex and remote for these things.
So, that's about it. As one does, going into a conference that we host, we thought about, we haven't had stickers for a long time so we thought we'll go in and is have a fresh exciting happy new thing. Everyone being excited. I was sincerely happy and looking at this, and then give the opinions. If you go back and look at the stickers throughout the week, we had debates on which animal family this is closest to, and we couldn't agree on anything. It's like we have separated groups, we thought about creating work streams, sub‑work streams, task forces, at some point I was like we have a group of 600 people who are highly qualified to debate a topic over a longer extended time of work and get to a solution coming to Krakow and I have an opportunity to talk to them. So I thought that's too good to be true not to use it. So here is your challenge from me for the week.
Find an Akamai representative, acquire a sticker, debate amongst yourself, debate on social media and then vote which family this one is closest to. You can see the QR code there. You can see the Slido number down there, we'll post it on social media and you can ask every Akamai employee for the links.
In case you are wondering who that is. We have a good number of them around here. They are here to help you, give you stickers, and talk to you. A good amount of them is Polish so they can help you with restaurant ideas, recommendations for whether to go in Krakow, what to avoid in Krakow and what interesting sites and ideas to have. I can, by experience tell you, they have good ideas.
And with that, thank you for being here, thank you for giving us the opportunity to host you, enjoy Krakow, enjoy the conference, have a good week. Thank you.
(Applause)
MIRJAM KUHNE: Thanks again.
Next up on stage, as you can see, Hans Petter Holen, the Managing Director of the RIPE NCC to give you some more information about the meeting and about the RIPE NCC.
HANS PETTER HOLEN: Thank you very much, Mirjam.
So my name is Hans Petter Holen and I am the Managing Director of the RIPE NCC. I have been so for four years now, but as many of, you know, I have been part of this community for a long time.
So, just to repeat to all of you why we are here in the first place.
The RIPE community set up the RIPE NCC in 1992 because they needed somebody to organise practical things between the volunteer work in the community. It's a membership organisation from '97, it's run by my staff, and I have an Executive Board that supervises me and the Board is elected by the members and many of you are members to please come to the GM and exercise your right there to vote on future Board members.
We provide services and we implement the policies, but we need you to be engaged and give us input in the Working Groups on how the services are performing and what features you would like to see in the future, and to develop policies for us.
And as Mirjam said, we should be proud of what we have achieved together. We have, as the RIPE NCC, supported the community for 32 out of the 35 years this community has existed. And we have done great things together, and let's continue to do great things together in the future.
A number of challenges are ahead of us. We have talked about political challenges in the years past us, and we know also, we are facing challenges of how we are going to finance the RIPE NCC in the future. The Services Working Group and the GM, on Wednesday, this will be discussed and there is a BoF tomorrow also to look at how to build a stable future for the RIPE NCC, because we have done great work for 32 years, let's figure out how to do great work for the next 32 years as well.
And it's not that I think that change isn't needed but I am very mindful that we should review what we are doing and have been doing with respect for those who are doing it, but we should also be self critical and take input and see how can we do better together. That's really important for me.
And all changes that we do, we need to be really mindful that we don't break anything that shouldn't break. We all want the Internet to work and all of us need to work together to make sure that it continues to do so. And that's why the RIPE NCC, the Network Coordination Centre, is here.
Logistics:
Meetecho is the main platform for remote participation, but also for on site participation. You can log into this on site and enter the speaker queue or add your Q&A questions to be read out if you don't want to go to the microphone. There is a live transcript available there, so if the field on the screen here is not big enough for you, you can get it on your device in front of you to follow the transcript there.
And there is also a live stream on the RIPE NCC webstream if you want to have it on your big living room TV if you are not here.
And then all the sessions will be recorded and chat archives are published afterwards.
In Meetecho, you can click on the audio or video queue if you want to line up to ask a question, you can type in the questions, if you want that, or you can chat in the chat room. The questions in the chat room will not be read out as questions obviously.
And then again, stenography. It's a really good tool for those of who who are not native English speakers or if we don't get all the dialects of the native English speakers. (I don't get them either)
So it's one of the things that I have learned to appreciate myself over the years here. Maybe in the future we will have some AI robot that is translate us into our all our languages as well, the bubble fish thing from the hitchhikers guide comes to mind but we are not quite there yet. (I'll be out of a job!)
.
We have gone digital or partly digital, there is QR code on the back instead of paper that will be wasted afterwards. Please scan your QR codes for the meeting plan, on site information or the wi‑fi.
If you do not want your picture taken, and I see some of you have already gotten the yellow lanyard, so that's the signal to our photographer or any of us that takes pictures, put on a yellow lanyard and our photographer will do his best to not take pictures of you and we will also be mindful to each other on this.
Here is also a picture of our photographer that is running around here so that you know who he is when he puts a big camera in front of your face.
The RIPE NCC at RIPE 88. So we're here as the diamond sponsor, but we're also organising the meeting. We have a meeting organisation team for all times RIPE 88 related. Please contact them and they are happy to assist you. We have a tech team that makes all these wonderful technology like the Internet that we take for granted and so on to work. We have support desk. We can do assisted regulatory checks if you want to have a check on your registry, and please speak to any of the RIPE NCC staffer.
We are also giving a lot of presentations here, and I have added pointers here to where you can find us. Jad has already talked about RPKI in a tutorial this morning. Tomorrow, Robert will talk about SLAs and Maria will talk about illegal content on the Internet and the RIPE NCC's role in that. Angela and Marco in Address Policy will talk about policies and how the RIPE registry works. Martin will talk about DNS and in particular the future of ns.ripe.net the secondary service for ENR.ARPA. There will be several presentations in the Services Working Group. As usual, also, on RPKI this time. And then Romain will talk about EU regulations and the status there in cooperation. And Ondrej will talk about how to map v4 addresses into v6 addresses in the IPv6 Working Group.
And Vesna and Natasha are presenting in the BoF regarding the diversity and inclusion session on Thursday.
Then was course we will know the best and exciting presentations is the tech team report at the end of this session, because you know all the things that happened in the network or behind the scenes is always interesting to hear.
If you have an interest in our website our meeting site, please talk to Philip, he would love to hear you from, your thoughts on how to develop those. Evelien is here and is doing user testing on our academy training courses, webinars and certified professionals. Stephen has done a lot of work together with his team on the user experience and user interface of Atlas, so he would love to hear you from through testing of the new user interface. And Michela is also really interested to hear about you and ‑‑ hear from you about your use of RIPE Atlas.
And that was me. Questions, take them to my colleagues. Thank you.
(Applause)
MIRJAM KUHNE: Thank you. And now we start with the actual meeting. I'd like to hand over to Max who is the Chair of the Plenary ‑‑ of the Programme Committee that is responsible for the Plenary programme and Max has the old slide deck still. We have a new logo.
MASSIMILLIANO STUCCHI: I took it from last year, and I have to be honest, everyone on the Programme Committee looked at the slides and they didn't say anything. So we didn't catch anything as the Programme Committee.
First of all, let me start with a selfie, because this has become a tradition. So.
Now, on to more serious things.
I'm the Chair of the RIPE Programme Committee which is the team that decides what you will see during the next few days, or part of it actually, not all of it.
So what do we do? We compile the programme Plenary, the BoFs and the tutorials. We prepare the agenda. So there is a well oiled machine that goes on and looks at what the content is and thinks okay, when is this best placed? We sometimes work with the submitters to adjust or improve their presentations. We have tried to do it more and more over the last couple of meetings. And then last, this is what we do with me and Jan, but you will see many of us during the week, we Chair the sessions, so we make sure that the presentations are uploaded, the speakers are here, they know how to present, they know how to look at the time and we keep track of the time and the questions.
Now, who are we? There was already a, Mirjam already presented it. I didn't have the picture from Pavel, I am sorry about that. But it's a nice group. We have worked together in the last few months to bring you the agenda you see these days.
And what did we get? Is you see that we got for Plenary talks we got 31 submissions which means about 15% of them were accepted only. But a hundred percent of the BoFs were accepted. We had two submissions and two passed. We had a little bit less for the tutorials because only two were accepted out of three submissions, and we still have space for the lightning talks.
Now, what were the main challenges and issues? Because this is where it gets funny.
We had time zones problems. So for the first time I decided to send out invitations for the calls earlier in the year so that everyone could organise to be there, and we missed it completely in the end because we ‑‑ when I booked the meetings, DST was not ‑‑ was up, and people joined at different times for the calls. But we managed to get everything done.
And then the second part was scheduling. This is more serious, and we have seen this issue raising in the last few years.
The sessions on Friday, we get a lot of requests from speakers not to be put there, and this creates a big issue for the Programme Committee because we really struggle to find content for that session. So this is something that will be discussed in the ‑‑ we have a lunch on Wednesday, and we will discuss it there.
And after the meeting, because we always have also a session with the RIPE NCC during the lunch but also after that to see what issues we have and how we can fix them.
Now, we still have space for lightning talks on Friday, but also maybe one for tomorrow on Tuesday. If you have an idea, are talk to us, me, Jan or the other people on the Programme Committee, and you can still submit.
Please include some slides, even if basic, and we will have a look at them. I know some of you are still waiting for an answer from us. There is a session tomorrow for which we'll send out notifications in a moment.
Last but not least, we have elections coming up. My term is up, so I will run again for election, but there are two seats up, the other one that's ending its term is Wolfgang's and you can nominate yourself until tomorrow, and then voting takes place from tomorrow until Thursday, and on Friday morning we will get to know who will still be on the Programme Committee.
Now, if you want to know more, talk to us, we are always available for explaining what it means to be on the Programme Committee. And I can give you a very basic glimpse. You have to review the talks, rate them, tell the team what you think. It's a very open group and we only usually have two calls for which you need to be on there before every meeting. So, it's not too much work, it requires a bit of concentration, it requires being critical and being open to discuss with your peers.
You can e‑mail us if you have any questions, and that's it.
So I'm not going to steal any more time. I think I'm at the end of the presentation. If you have any questions, here here.
(Applause)
.
After me, I see we need a big applause for Matthew Kirkland who was going to be the very first presenter today and is going to tell us about how Facebook removed IPv4 from part of their infrastructure.
MATTHEW KIRKLAND: Good afternoon. My name is Matt Kirkland, I am a network engineer at Meta, and today I'm going to be talking about how we are removing IPv4 addressing from network matters at network infrastructure. It's actually my first time presenting at RIPE, and I thought to myself like surely, when I was doing submissions, that surely I'll just get a nice slot on a Wednesday after the social. But it was not to be.
So, I'll be going through the why we wanted to do this, what approach we took and what lessons we learned along the way.
At Meta we have four main network areas, starting with data sets and networks, which are the data halls in our large data centres. These are connected together by our core network called the express backbone, and its primary purpose is to carry machine to machine traffic. We have also got a management backbone that connects all of these together for a management purposes. And then finally, the edge network which is what I'm going to be talking about today, where we have our POPs, third party facilities like Tellius, that also contain our compute for CDN, these are ten connected back to the data centres from what we call or classic backbone, which is kind of like an ISP network.
Our internal traffic. More than 99% of that is served over IPv6 already. This number on the left is actually wrong. I didn't upload the new slide, but as of today, there is 39% of our traffic is served to the public on IPv6.
The rest is IPv4.
So, this is a simplified diagram of our edge network. Starting from the bottom with our servers which we already moved to v6 addressing and v6 BGP. Then our top rack switches detected to the aggregation layer and the metro aggregation layer which allows us to physically separate peering from compute in the Metropolitan area. From there connecting to our peers over IPv4 and IPv6.
So in between each of these layers we have a full mesh point‑to‑point links dual stack and running IPv4 and IPv6 BGP sessions between those.
So, why would we want to do anything different? Why not just keep operating as we have before?
.
One of the major reasons is simplification. So today we run, as I said, IPv4 and IPv6, so having two distinct topologies within the network is added overhead.
From scale, as I said, we have got a lot of point‑to‑point links, just within one POP. Larger POPs have many layers, and then of course these POPs are spread across the world, so we have quite a few of those.
As we grow, we are running into limitations with our IPv4 space which is limited.
We started this project actually last year, by starting to test it out in our lab just between the rack aggregation and metro aggregation layers, followed by a small rollout, followed by a production rollout. At the same time, we started last year to rollout to top rack switches and the rack layer. So, where we are today is, we finished our rolling out to all of the other layers and we are going to start on the peering layer.
So, I mentioned dual stack a few times, and I'm sure everybody in this room knows what that is: Having two IP addresses on an interface, one being IPv4, one being IPv6. And then having separate BGP neighbours for each address family carrying prefixes where the next hop in that address family.
So, I'll be moving to RFC 5549, or 8950, and for the rest of this talk I'll just refer to it at 5549 because that's what I have been doing for the last 18 months.
.
So under that we have got a single IPv6 address on an interface, and a single IPv6 BGP session carrying IPv6 prefixes and IPv4 prefixes, the IPv4 prefixes having an IPv6 next hop.
So, this doesn't seem that hard. We are just removing IPv4 addresses from interfaces, and changing over some BGP sessions. It sounds easy, right?
.
No! We ran through quite a few challenges, many of them being platform or vendor dependent. One the first things we had was when we were consulting with partner teams, and what was going to happen with traceroute, because people are used to get an IP address associated with an interface for their traceroute. So, in the ‑‑ you know, in an RFC 5549 topology you only get a reply from the loop back address, v4 loop back address.
So, in parallel, we have been working with our vendors to implement RFC 8335 and 5837, 8335 being a probe utility for interfaces, and 5837 extending ICMP to include interface at next hop identification.
The first technical issue we ran into actually was with the ECMP, so referring back to the earlier topology diagram, having a full mesh of circuits, full mesh of iBGP sessions, you know, any one of these devices should have four paths to a given prefix. So, what happened is, one with one of the vendors that we use with the presence of v4 and IPv6 next hops they don't get put into the same ECMP group, and as a result, that OS only installs the prefix with the v6 next hop. So that makes it a bit difficult to plan migration since the first BGP session that you migrate will then start pulling all of the traffic for that device. So we had to do some BGP traffic engineering to balance the load during the migration.
We actually went ‑‑ I went and discussed this with some of our other vendors, and one of them does what we would expect, which is equally balances between v4 and v6 next hops. And the last vendor actually did the exact opposite of the first, where they would only install the prefix with a v4 next hop.
So, if you ask three vendors the same question, you will get three different answers.
So, when you are moving your BGP sessions over to IPv6, it's important to remember that these platforms will need to have additional configuration to allow forwarding of v4 packets out of IPv6‑only interfaces. On some vendors, this is a global command, and others, it's a face level command. But if you miss it, it's hard to catch. You will be silently dropping those packets. Even within some of the same vendors, there is differences in how this is implemented between platforms.
So, because we want to be able to catch any issues with v6, we wanted to have per address family counters, which is supported but differently again between each platform. So, with one much our vendors, you could get only egress on one platform but ingress and egress on a different platform.
And another vendor still would only give you IPv6 counters and it's up to you to take the total, subtract IPv6 and hope three that's your IPv4 traffic.
.
When you are moving to a single BGP session, in our case we had different BGP policy for v4 neighbours than we did for v6 neighbours. So, what you need to do is then move all of your v4 policies into the same, or policy terms into the same policy as your v6 neighbours. So, as in the picture on the right, specifically addressing IPv6 prefixes and IP prefixes for v4.
One of our vendors allows distinct policy per address family on the same neighbour so you can have an IPv6 neighbour and when you are enable a v4 address family, you can have its own ‑‑ it can have its own BGP policy.
So, now that we have migrated all of the other layers, the final layer is the peering layer, which is different because the other layers we were using just IP forwarding with BGP. And the peering layer we have, we run an ISIS level 1 domain in single topology mode with ISIS segment routing. So, one of the hurdles we have here is that one of our vendors is perfectly happy for you to remove the v4 addressing from a given link and not change the topology of ISIS so even in single topology mode it will bring you have an adjacency. Another vendor requires you to move to multi‑topology for IPv6, which then imposes a requirement on the other vendor. So, that makes migration a bit more painful as we have to change from single to multitopology in a maintenance window, it's more impactful.
So, I mentioned we were using segment routing in that part of the network, and there was some concern about how this would work. Luckily for us, as expected, we get an IPv4 packet from the LER on the left, a label pushed on from LSR, got from the LSR POP label, it forwards the packet to the final router.
What I found out subsequently is that if we have ‑‑ sorry, the LERs are one vendor and the LSR is a different vendor. So if we had the same vendor for all three, the same as the LERs, on that LSR POP, before it forwards the packet, it does a header look‑up and compares the address family on the outbound interface, finds out that it's not an IPv6 packet and it drops it. So we got lucky there.
So, once we have that done, where do we go from here?
.
We would like to remove v4 from the link addressing within our CBB core network. Unfortunately, because we are running RSVP‑TE, there are no implementations of RSVP‑TE that run on prefix today, despite it being in the early version of RFCs. We went to for vendors to ask if they would implement this, and some of them actually told us that no one had ever asked for IPv6 RSVP, which I find pretty incredible.
So, not all bad though. What we can do is we'll be removing the v4 BGP sessions and moving our BGP mesh to RFC 5549.
So, throughout this RFC 5549 just works, we did not have any issues with interoperability or implementation for the BGP side of this mission.
A lot of testing was needed to find all of the things that we have uncovered so far. So, testing is very important. And lastly, is it worth it?
Yes, the overhead from running two distinct topologies in the edge network reducing that and not having to plan for future IPv4 needs has been worth it.
That's the end of my talk.
(Applause)
JAN ZORZ: Okay. Do you have any questions? I think Peter was first.
AUDIENCE SPEAKER: Peter Hessler. Several times in your presentation you mentioned vendors did things differently from our vendors. Do you think that is something that is, that needs to be clarified in the RFCs? Or do you think that is something that the vendors kind of ignored or misunderstood from the RFC?
MATTHEW KIRKLAND: I think it's just a choice they made. In the case of the vendors that installed only the v6 next hop we had a talk with the engineering team and it was not following an RFC or anything, they thought of it the better way to do it. And so, they have actually changed that in a more recent release, so that was good feedback I guess.
JAN ZORZ: It's Antonio next.
AUDIENCE SPEAKER: Hello. Antonio Prado. A random BGP guy. So, it's quite the same question but just to understand if you did open a dialogue with vendors and if you came up with a solution.
MATTHEW KIRKLAND: For which part?
AUDIENCE SPEAKER: For your issues.
MATTHEW KIRKLAND: Yeah, I mean the feedback was received differently in each case. As I said, the next hop problem that was well received, they had agreed to fix it and I believe it is being fixed in a recent version.
Issues with things like the counters on different platforms, they explained that some of this is hardware related, so like an old chassis may not have the right resources for enabling both ingress and egress counters. So there is nothing I can do about that if it's a hardware issue. But yeah, I did take all my findings back to two vendors.
AUDIENCE SPEAKER: Jen Linkova. Thank you very much. Very interesting, very exciting. I just want to say that I feel your pain, I have been talking to vendors about getting RSVP working over v6. There is at least one or two vendors who have customers asking for this besides you. So you are not alone in this fight. Unfortunately most cases, what I have heard, was the answer: Why would you need this now we have an IPv6? Which is horrible, right?
MATTHEW KIRKLAND: That means I have to reengineer CSPF. So...
JAN ZORZ: I'm cutting the queue now.
AUDIENCE SPEAKER: Tobias. What are your eBGP plans? External.
MATTHEW KIRKLAND: They will dual stack, is that the question?
AUDIENCE SPEAKER: When do you make them 8950?
MATTHEW KIRKLAND: Oh... I was thinking about that earlier today. That's going to be a much longer tale, that involves discussing the matter with each peer.
AUDIENCE SPEAKER: Thank you. We should maybe chat.
AUDIENCE SPEAKER: Mitcho. We ran something like you but of course much smaller scale and we had just experiences with well multiprotocol open location, the ISIS multitopology, was it really necessary because it kind of skimped on it, and I guess that maybe it requires its own little presentation?
MATTHEW KIRKLAND: Yeah, I mean that surprised me. I mean basically one vendor telling me that you have to change to multitopology and the other saying you don't have to change because it's just a signal topology, so, I don't know what the answer is, the right answer. But... yeah, that's where we ended up if we wanted to interoperate between them.
AUDIENCE SPEAKER: Thanks for your effort.
MASSIMILLIANO STUCCHI: Before we go to Daniel we have a couple of questions from the queue here on Meetecho.
"What vendors are friendly for a mix of v4 and v6?" It's a broad question I know.
MATTHEW KIRKLAND: I don't know if I should answer that. I don't want to be in legal trouble.
MASSIMILLIANO STUCCHI: Okay. Well the next one from Nico: "Overall, would you say the main challenge was in inconsistent support across vendors or own product families for links addressed in v6 only? Did you encounter any of these issues in the free and open source software network stacks and routing daemons?"
MATTHEW KIRKLAND: That's a great question. Because the network that I'm training is all vendor hardware I did not look into any of the open source BGP daemons. But the actual implementation of 5549 was not an issue between the vendors that I found. It was everything surrounding it like forwarding and reporting that where there was inconsistency.
MASSIMILLIANO STUCCHI: Thank you. And I think we go to Daniel.
AUDIENCE SPEAKER: Daniel Karrenberg. Old network guy. In the good old days we had bake‑offs, we just put all the vendors in one room and the engineers and said make it work! I'm wondering whether people with the buying power that you have might team up with people with similar buying power and just make them do that? And basically say: You guys are responsible for even though you are competitors of each other to be in one room and make this work for us. Otherwise we won't buy from you again.
MATTHEW KIRKLAND: Yeah, and I think that's fair. Like I say one of, one of our vendors did fix what we saw as an issue and they didn't think was an issue with the ECMP groups. But when it comes to things like the v6 RSVP, which has been a problem for many many years and more people have asked for us, as Jen said, it's difficult to make them shift on it if the combined ask of Google and Meta is not going to work.
DANIEL KARRENBERG: My point is you are doing all the work there. What actually the vendors should do, so I think you should band up with people like Jen or others and basically beat them into submission.
MATTHEW KIRKLAND: Thank you.
(Applause)
AUDIENCE SPEAKER: Hi. I am Michael. It's part of an analysis presentation. Actually, I am curious about the CDN impacts after you implement this kind of migration like maybe some missed CDN that's impacting the latency, like maybe you are lucky that in Krakow but you take the CDN from any other country, a far away country, any impact to the user experience or something?
MATTHEW KIRKLAND: So, well... so I'll start off by saying that we broke this down into a number of phases. So we only worked on between two layers at a time. And for the first part, we didn't have to take traffic away from the CDN cluster. For the second part, which was changing the actual top rack to rack aggregation BGP session, those we had to drain the entire CDN. And from that perspective you would see an increased latency during the maintenance window but we have not seen any increased latency after we have shifted the traffic back. Does that make sense?
MASSIMILLIANO STUCCHI: We have a couple more questions from Meetecho. The first one is from Sascha: "Does IPv6 bring new security challenges that need to be addressed such as specific attacks on IPv6 infrastructure?"
That's a broad question.
MATTHEW KIRKLAND: I don't feel like I can accurately ‑‑ I'm sure there will be. Nothing that I know of right now.
MASSIMILLIANO STUCCHI: The last one I'm going to read is from Anna: "Are you thinking about introducing segment routing v6?"
MATTHEW KIRKLAND: Sorry?
MASSIMILLIANO STUCCHI: "Are you thinking about introducing segment routing v6?"
MATTHEW KIRKLAND: In place of RSVP? We have talked about it but, you know, the challenges as I mentioned is that you have then got to re‑engineer whatever ‑‑ something to replace CSPF which is a bigger project than this.
MASSIMILLIANO STUCCHI: I have a very, very last one. This is interesting so...
.
"99% internal and 38% public traffic on v6. Will these go to 100 and when?"
.
You can take out your sphere and give us some numbers.
MATTHEW KIRKLAND: We have internally we have some random projects that still use v4. It's that very, very long tale of trying to find stuff to move over. As for 4 internally, that's completely out of our control. We offer v6 to all of our peers.
MASSIMILLIANO STUCCHI: Thank you.
(Applause)
JAN ZORZ: So, Max, who is next?
MASSIMILLIANO STUCCHI: Next we have Thomas Weible from Flexoptic.
THOMAS WEIBLE: Hi. Thank you very much. My name is Thomas Weible, the co‑founder of Flexoptic, and I brought a topic with me where I think is going to be a game changer in optical transmission the next couple of years, it's about coherent optical transceivers and I have separated the presentation to the section. The first one is going to be a bit about theory, and the second one is going to be how we did a practical implementation together with DE‑CIX in Germany on their Nokia gear.
Let's first start with where we are coming from and where are the limits.
So, when we look at the ecosystem for there are limitations and I am pretty sure a lot of you get in touch with those issues that there are lot of form factors around, starting with the well known CFP. It's a big plate, taking a lot of power, horrible interface to implement, and it anticipates a lot of feed which in some circumstances is quite good which you will see later on. And there were some other form factors in that family like CFP2 and a well‑known C pack, I feel sorry for you who implemented C pack, because it's basically not there any longer. And maybe I'll ask a question about CFP 4, who has ever got one in his hand? One person. Who plugged it in the router and switched it and is still operating it. It's a 100 gigabit transceiver, it's fast.
Okay. So you see there is a huge variation of transceivers for 100 gigabits but they had limits and especially in terms of the ratio of the power consumption to the size of the form factor, for sure if you have a CFP it can draw a lot of power but it's a horrible bad form factor. The....... on the other side it has power limitations, and so on.
And for sure, the focus when the specification was made, they were mainly intended to in a data centre link. Up to roughly 10 or 25 kilometres but not beyond that.
And that's something which is targeted now by coherent. So for the 100 big world as well, when we were talking about DWDM, long distance links or long hall transmission, there was transponder cards holding a digital signal processor made out of a chip and this was produced in 28 nanometre structures for example. The card itself is quite big. And typically a transponder system. Now, with the time and what we get it knowledge in terms of building small chips and structures down to 7 nanometre chips, we are able to build a really tiny digital processor which does all the magic and place it on a night form factor called a QS FP‑DD and it can power it or hold it just in terms of size. That's where we are today doing 400 gigabit with a transceiver and providing coherent technology.
Where are we coming from? So let's first have a look at our basics of our 10 gigabit. In the past basically, we were and we are still doing it, I am pretty sure, doing direct detection transceivers. That's an on/off keying mechanism and modulation, and it's straightforward. So you have a zero and a one, light on, light off. And what you see here is on the the top one, that's basically how the transmitter transmits the signal on a time basis, that's a timing diagram. So on the top you have the one. On the bottom zero, and it's directing the shape. On the receiver side, it's not a rectangle any more it's more sinus curve or something between, because why the signal is traversing on the line it's going to be disrupted by effects like the link of the fiber for example.
Now, if we would just increase the speed, which is basically increase the frequency, you will see something like this. So, we dense the frequency, we get a higher frequency. The signal on the transmiting side is better but on the receiver side you see something like the amplitude is getting small. So it's getting harder for the receiver to detect between a zero and a one. That's what we want. If we increase the frequency even more, you can see on the right corner, the diagram actually it's just one. So the zeros are not detectable any longer.
So, we are talking about light. And light has not only one property, the amplitude. We have more parameters within light and that's actually what coherent technology makes use of it now.
So we were talking about frequency and amplitude and what we have face and impolarisation. Let's start with the easy one, the polarisation. All of you, use the privacy screens on your laptop so that your neighbour doesn't support your work while you are here in the conference. How does this work? It's a filter, it only allows certain directions going through that filter. In coherent technology, we do the same. We have two directions basically, and that's the DP standing for dupe polarisations directions, and we filter between them. We did a simulation, and we have two planes, we have the X and Y for the polarisation and what you see here is a signal. It's the X plane of the polarisation. And now when we move over to the Y plane, it's a totally different signal so far they look the same. Now when we combine them, that's where the magic happens. That's the real signal that is the receiver and it's calculated by the DSP and ended up in zeros and ones at the end of the day. These are roughly 160 bytes ween coded there. A typical text message, and that's how it would look like.
Just for the polarisation.
Now, moving on, as I said, we have phase, we have amplitude and polarisation. Now looking at the phase for example. At the beginning I introduced the timing diagrams with the frequency on the time. And this is also the foundation when some of you might have seen an I diagram of a transceiver. It looks like an I where you shall distinguish between zero and ones. Now for coherent the timing we get rid of it. We want to look at constellations. You can think about stars if you look at the sky there are a couple of stars lighting out. And start with an easy example of the constellation of on/off keying mechanism like what I showed at the beginning, 1 and 0, these are the two stars on the left of this constellation diagram. And you see on the X axis, this is the inphase component. On/off keying mechanism is all in phase, there is no phase shift. Now with 100‑gig bit and beyond, it's four level pulse amplitude modulation, it's modulated on the amplitude but we are still in the phase but we have now four stages or four symbols and each symbol is carrying two bits. So we can increase at least now or double the bandwidth just can encode now two bits. As you can imagine, as it is a diagram, and we have 16 squares now there, with 16 quantum, which is 16 quam amplitude modulation, we have a four by four metrics making use of complex numbers. And these belongs out of the real part, which is the X axis and the imaginary part, which is we should see here on the Y axis. Combining them together we have four by four constellation points and ends up in 16 different constellation points, which are distributed all of this diagram. And the biggest challenge there is the ‑‑ in the middle, the centre is quite important because the DSP, what it does from the centre of the diagram where the zeros meet each other in the middle of the diagram it does calculate a vector to each constellation point and that consists of an angle and a distance. And with that you can differentiate between all those 16 points and get a single out of it. We can encode as you can see, four bits from each symbol and that's compared to the on/off keying mechanism where we were only able to encode one bit quad crumb basically. We have four times more bits within the same frequency.
A real world example. Some of you might know it's an optical rotary encoder. Don't get confused. This is not part of an optical transceiver. It would be funny though. It is, it's used in several moderates for example. So you have a typically which detects the slices of the slice disc and then you can, depending on how fast the disc is rotating you can detect a single. Now when you place a second diat with a certain distance, you can get a phase shift and when the distance is correlated to the speed, you have, for example, 90 degrees of phase shift and you can detect always at the same time, that's the most important thing, you detect always at the same time and then it will look like this and you get your phase shift. When the real part is at the zero, it is still at a zero and it's going up to a one, the imaginary part is at the beginning of the zero and so we encode it two phases actually.
Moving on, within coherent technology one measurement is becoming very, very important now. It is the signal to noise ratio. This is something quite simple to explain. You get the noise level of a signal, like here in the audience, it's very quiet. And talking me as the desired signal to you and the same applies to a transceiver. So there is a desired signal in the ratio to the noise level on the line. So ‑‑ and we need that measurement. It is important to have that measurement, it's measuring something and this is like 21 DP, the receiver is still capable to detect a signal there.
How would that look like and we compared different signal to noise ratio levels? Like on the left side you see the 30 dB and that's comparable talking to here to the audience, it's a good signal to noise ratio, which is clear, you see the constellation points the receiver can easily detect them. Now, get ‑‑ if you guys would cheer now a bit more, to 20 dB, it's still doable to hear me because the audio is quite good but doing the same talk in a football stadium, this would end of in signal to noise ratio of 5 dB, the constellation points are distributed all around and it's hard for the receiver to calculate the vectors to which section actually does my desired signal belong to. So, in other words, on the right side you have a lot of bit arrows, you have flapping links and it won't work at all. The in the middle one it's doable but you have a lot of bit errors on the your line and depending how picky you are you might have flipping links and on the left side it's the perfect link.
That's the theory part.
Now, coming to the practical one. And to show you why the theory is so important, now in these days when you look at your operating system of your switcher router to understand why is my link making trouble? I have perfect power levels. Light levels but it's not working at all.
So what we did, we were just running one command. So first of all we were plugging in the transceiver in a Nokia gear, QFSC DD based, enabled the port, configured it. In the end we run a show port command and looked how Nokia did this and we ended up with three different sections returning us or we can do some analysis on it. And for the setup, it was 15 kilometre span, where we did the testing, and these are the metrics and the measurements we did so.
On the first page, this is roughly the physics about the transceiver, the specs. So it's a fully tuneable transceiver. From the starting frequency, I don't read the entire number because it's very long, megahertz, which is not very common. Typically we say it's terahertz. So it's 191.3 terahertz. Going up to a Max frequency of 196.1 terahertz or even easier, channel 13 to channel 61. That's where we can tune that transceiver. It is currently tuned to channel 24 and it does support a couple of grids. We can slice it down to 50 gigahertz grid. It's all done by the DSP. That's amazing.
Moving on, diagnostic monitoring. I am treaty sure everyone is familiar with diagnostic monitoring, looking at the temperature, the voltage, gigs and power levels and we highlighted the temperature because the temperature has become crucial and critical. When you look at the implementation of your switch and router gear, you will find out there will be some high power ports which provide enough power to that port but the more challenging part is getting rid of the power because all the power we feed into an optical transceiver, especially when we are talking about optical communication, only 0.001 watt is converted into light, and the rest what we feed in there of those 17 or 18 watts of power is heat dissipation and we need to get rid of that one.
I will come to the heat later on again. And let's move on with the coherent parameters. And I highlighted in my opinion the most important one which you should know when you operate your link.
So, these are coherent specific parameters and let's start with the RX channel. As I said at the beginning, it is ‑‑ when I introduced the characteristics of the transceiver, it's a fully tunable. Typically when you talk about tunable transceivers, you think about transmitter. You tune the transmitter. Now, for coherent, this is still doable, I didn't highlight this one, you do the frequency as well but you can also configure the receive frequency. That's really, really important, depending on the hardware you are using. There is a local oscillator inside which locks to the frequency and you need to do this also for the receiver. If your transceiver has two local oscillators, there were some CSP model layers out that that has that, if you have having this you can do a single strand transmission, means the so to speak on channel 3 and the RX is on channel 25, you can transmit on one single fiber. For the QS BDDs, we see in the market at the moment, there is only one local oscillator inside, us use an optical legislature and he is feeding both. So you can't change the RX frequency there or it needs to be the same like the TX one.
Dispersion. As I mention, the DSP is quite powerful. Dispersion is a critical measurement and we have two types in an optical transmission system. In the past 100 gig without the ESP you needed to compensate dispersion. What is dispersion? It is the change of the signal while it's traversing on your fiber and typically it's dense basically, so you start your signal itself on a timing diagram and then while it's transferses to the receiver, you will dense it and dense it. And then there is a certain thresholds you can't distinguish again between zero and one.
With the DSP we can compensate this up to 2000 gig seconds, which is with quite powerful. And on the bottom you see also the actual measurements. So we can measure how many dispersion we have on the fiber. We have 220 PS slash NM when you know the characteristics of your fibers for example, it's a G 652.D which does roughly that, you can do the reverse mathematics and calculate the length of your span. So this would end up in 22 kilometres, if you do the reverse mathematics, our one was 15, we couldn't find out where is this offset coming from. This offset of 750 peculiar seconds. We made a prove, we used the back‑to‑back link with cable and here we have we had the 70 pico seconds they appeared. There are some ideas that it might come up from the plucks, but I'm not convinced where is this dispersion coming from.
Moving on, as I said at the beginning we have polarisation now. We also need to take care about the dispersion which can happen on the polarisation direction.
So, and this is called either the polarisation mode. Dispersion, the measurement is the different group delay. Here we had two pico seconds of the delay. So that's the difference of our Y axis and the X axis, the direction basically, how they different with each other. And again the DSP can compensate is up to 10 pico seconds or depending on which standard or specification we are following, up to 20 pico seconds.
And finally, ONSR, the signal to noise ratio, we do have now for both polarisations we have an OSNR measurement, or SNR measurement. This link was running perfectly fine with 34 dB, and there is the forward error connection, this pre‑FEC. And this is important because every DSP inside buzz a forward error correction and it is required, otherwise you will end up with flapping links. And the RXQ margin is correlated to the forward error correction. And some Windows also call it the Q factor, it's actually the gap, how capable to correct errors, so when this margin is eaten up down to zero dB the FEC is not capable any longer to correct errors. A back‑to‑back link at roughly 4 dB of margin error for the forward error connection to properly work.
And finally, you might have heard about the term "Open set‑up plus" or auto specifications, OIF, each transceiver, each coherent one can follow certain specifications. But the interesting one we configured t this is the config section in Nokia here to the open set R plus, but actually the transceiver itself was not capable to follow that specification looking at the first section this transceiver was only capable to follow the OIF specification, which is a different one. Which I show in the next slide.
And so you need to be really aware what you configure and what is your hardware capable to do. There are simple node checks, at least when we did this last year, maybe it has changed but so far I haven't seen any improvement there.
Having said that, and mentioned already the OIF 400 ZR which is the older specification, and later on in the industry and in the community well known open ZR plus, threes are the two different main specification today. They don't differ that much in the TX and RX power. As you can see, but they differ pretty much in the CD dispersion, it's all about dispersion around the ONSR tolerance and especially the open setup plus, it's would say it's the latest one, it's more sensitive, it's less sensitive on the CD, you can build at the end of the day longer spans. Open setup doesn't differentiate between a couple of sub‑standards but we have two to point out. It's a 60 LA, the L is a low power edition it's called. With the TX power of minus 10 DBM and the current one which everyone is looking and aiming is the 60 HA, the high power solution, doing zero DBM and giving you roughly, depending on your ONSR and your requirements on the speed, of 12 dB or more power budget.
That brings me almost to the end of my presentation. A little bit of an outlook. And as I said at the beginning, there is coherent technology is a game changer in optical transmission. I showed up just with raw compute power inside of a transceiver we can now, let's say, quadruple the speed of what we do to transmit data. And here is a little bit of an outlook where we are going to. You see the green circle is modulate the signal and when you quadruple is up to the 8 times one. That's dual polarised 16 quantum signal and just with the DSP we did four times more and weakend up and build a 6 terabit transceiver. The current implementations we see so far is the red line actually for the 800 gigabit solutions, it will be palm 4 still but also with the higher boat rate and the higher frequency on the electrical options side. We are running it eight times 100 gigabit palm 4 model layer. This is roughly a 50 gigabit signal on the electrical side.
Last but not least. Thanks a lot for listening and watching on the from our side it's very it go to see how other manufacturers and vendors, we did a test with Nokia, I got some feedback from customers running on Arista and Juniper. I had an interest look on Cisco NX OS, very interesting. If you have another gear which implements a coherent parameters, talk to me, I am really interested to have a look at it and also support you with some testing gear. Thank you very much.
(Applause)
JAN ZORZ: So, there is ‑‑ there is no people running to the mics. There is a question in the queue. From Mico Brown:
"Are all coherent optics agile in terms of colour wavelength? Do they require optical filters for WDM or can they handle incoming signals containing other carriers?"
THOMAS WEIBLE: There are different solutions out there. There is things like the colourless solutions but for the moment where people aim to build it, it's requiring a filter and typically a flat top filter to get through the 100 gigahertz. Thank you for the question.
AUDIENCE SPEAKER: Blake Wisano. Thank you very much for doing this, it's in my life for the last three months. So I very much appreciate t have you seen much progress on the front of having like an optical vendor be able to actually get data out of a router in modern ringness so that like you can present to your kind friends in your optical team the data from your router in a way that they can see it and manage it in their shine owe managing monitoring system?
THOMAS WEIBLE: That's a really good question. And thank you for raising that one. What I showed today is really like the tip of the iceberg, what is a coherent module is capable to do. It's really the tip. It helps, 99% of the engineers here to troubleshoot their links but a coherent module itself or the coherent nothing itself is way more capable and there are may more parameters to show and to represent it. And I think that's the big challenge. The ESP can do it but the software isn't ready yet. That's what I see. I think we will see in the next couple of years more and more emerging, and it won't end up with only three pages of configuration. You will end up with let's say four, five, six pages then. But for the moment, I think it's covering a lot of cases.
AUDIENCE SPEAKER: Thank you. Second quick one: Do you have many customers using this standard, bog standard OIF 400s that is in unamplified modes?
THOMAS WEIBLE: Yes.
AUDIENCE SPEAKER: Hello. David. We have running coherent optical transmission about five years now and I was just wondering if you have any plans or expanding your portfolio to see if transceivers were running lots of OTU with CFP transceivers and getting Flexoptic as a vendor would be really nice. Do you see any future in with standard or...?
THOMAS WEIBLE: Honest answer is: I personally don't like the CFP. I looked into the specification at the beginning when it came up eight years ago, and it's a nightmare. It is over engineered, to be honest. This is 300 pages plus. It is capable to handle a lot. But it's way too much, but that's my Thomas personal opinion, because I had to go through those pages and it was not a lot of fun. So, the answer is: I have some influence in the company, sorry, most probably no.
AUDIENCE SPEAKER: All right. Thank you.
WILL:. Thank you Thomas for the really insightful talk. I was wondering, my problem as a guy who recovers a lot of secondhand hardwares and so on, I also recover crappy fibers and so on. That will be a problem for me, I suspect, having non‑totally fresh mono mad fiber that came from you know where or wherever, because obviously the signal will be really affected if I try to do query on that. What's your thought about that? Will I need to measure that with a special ODTR or suspecting to be sure that I can actually go and do anything on this fiber?
THOMAS WEIBLE: Okay...
AUDIENCE SPEAKER: Maybe we can take that after.
THOMAS WEIBLE: Typically, you are talking about single mode fiber now? Typically, for sure, you get a measurement from the guy who brings out the fiber, you get a proper ODTR measurement and at least two frequency or 2 wavelength hopefully. This should do quite a lot of it.
AUDIENCE SPEAKER: Okay. Thank you.
MASSIMILLIANO STUCCHI: I don't see anyone queueing any more. So thank you, Thomas.
(Applause)
MASSIMILLIANO STUCCHI: So, this concludes our first session, and we are like a few seconds ‑‑ no, 15:30 right now. Perfect. Perfect timing. One request from the PCs: Please rate the talks, let us know if you liked them or if you didn't like them, and then we'll see you again in half an hour. Enjoy the break.
