 My name is Daniel Bernier. I'm a technical director at Bell Carada focusing on cloud transformation and other crazy things like P4 and SmartNix. But today, I'm going to talk to you about something which is really interesting to us. It's about leveraging Cilium with SRV6 for telco networking. First, I'm going to start with some problems with the telco networking. And I think our colleagues from Swisscom were talking about it before. But telco networking, although we would like it to be, is not something that we can talk typical. So most telcos, their networks are built through mergers, acquisitions. And although we would like them all to get consolidated, sometimes it never ends up. So we keep legacy devices that are ranging from even the 70s. Most telco networks are plagued with legacy technologies which never seem to go away. We still sell DS1s, DS0s. The gear is still there. The tools that come with it still there. So even though you like to go completely cloud native, that doesn't change. And the systems that you need to manage them with need to cope with that. Most telcos networks are also bound by regulations. Sarbanes-Oxley, old sailing agreements, which they do impose limitations on how you would like to do networking and how you need to keep networks segmented, isolated. Otherwise, it doesn't work. So the big fat net single VLAN that covers everything doesn't work in those kind of cases. Most operators have differentiated services, which they do offer. And that also implies some reality checks around how you would like to do networking. Sometimes your TV delivery system will not be the same, will not be able to run on the same as your mobile core. The systems will have to change. And there's still that 5G thing that everybody keeps talking about that's requiring a bunch of new things in our network. And it's also coming with something which we call network slicing. We need to think about. So conclusion is, although we would like them to be, telco networks are not typical. And they're not like any enterprise networks. Cloud native transformation for telcos is not just about CNS. If you look at this, our IT systems need to be going cloud native. A lot of our systems that manage the network need to go cloud native, not just the function. And it's also an impact on their networking. And by the way, hyperscale clouds use the same technologies as hyperscale as we do in operators to build their networks. They run MPLS, they run IP network V6, they run those classical device technologies. And whether you like it or not, network segmentation and isolation will not go away. The question is how we do it. So today, I'm not talking about how cloud native is affecting the telco. I'm going to just talk mostly about multi-networking and multi-interfaces. So even with all the potential alternatives that exist within communities, the multi-interface is still not a pleasing experience if you have to deal with it. You have either static route, sprawl, forwarding rules that go really crazy on your pods. You could use VRFC and I's, but most apps still don't understand how to use VRS properly Linux kernels. So it's a fun thing, but it doesn't really work. If you have multiple interface which is able to suppose to be providing you isolation, for some reason we're kind of recreating the four-legged server which adds a leg into a physical, because now pods have legs in four networks for some reason. So, and not to mention that the security policies don't necessarily follow those four interfaces, for new pod interfaces. And we still dump the problem most of the times to the network guys, and then we complain that the network doesn't work because we pass a VLAN with dump traffic and expect them to fix the problems. There's lots of third-party R-downs available. That's one of the beauty about communities is it's so malleable that you can add extensions and new features to it, new modules to it. But that comes with other problems. Now you have to deal with support model challenge. So I have a communities platform with it's CNI, then I want to add another mesh. I want to add the third-party mesh which is not the same, I want to add another CNI because it does some cool things. Then you end up with four licenses to support and use your single point of contact for this. And you also have to deal with the compatibility matrix. You want to upgrade your version of OpenShift, but then that new shiny mesh that you integrated is still not able to do so, so you have to wait. So that's not still fixing. And for just for fun, although it does work, have you ever tried to have a VPP-based and then native CNI running on either ANTAS, EKS, or OCP? I still haven't been able to get it. So, and by the way, I did try an SM for my feature set so it was a, I'm coming from scars and experience, but it was a cool project. So let's try to find out on our way because in the end, this is what we want. The developers should be able to create their applications, their pods, connect them to the network and not have to worry too much, expect this to be black magic, but how to make the networking, even if complex, simplified for them so that it doesn't become a challenge. So that comes to the, that was a part about the multi-interface problem. I'm gonna talk about technologies that exist in the networking protocols. Do I, that's gonna, you're gonna see them, the linkage together, why it became so interesting for us. So I'm gonna talk also about SRV-6. So for those who know me, they know I have a pet peeve with SRV-6. I've been through this for a long time in IETF and other initiatives. It's basically a new way of doing routing based on IPv6. So I was quite happy to hear my dirt-chilling friends talking about IPv6 so vividly. It's basically doing pat routing, like a source routing based on either 128-bit address scheme, like a segment of 128-bit or multiple small segments of 16-bit. So you basically carve out the sort, the pack, the path of your network through the source address. It's based on a few drafts and a few standards, one of them being the network programming framework where you actually, you encode instructions in your network based on your IPv6 address scheme, and you can actually create programs or small policies. SRV-6 is also not prescriptive, so it doesn't really care how you do the control plane of SRV-6. It does BGP because it came out of IETF, but you can create your own SDN controller, you can use your PC, whatever you feel like. It provides a single-length cancellation to provide both overlay and underlay. And in the end, it still leverages pure base IPv6 routing so you can actually simplify a lot of your network by just doing Rob IPv6 routing. It also is based on the logic of policies. So based on how you define the end behavior, the way your IPv6 is gonna be treated at their destination, you create various policies, which is called in the IETF term segment routing policies that help you define how your network is gonna treat the application. And the traffic is teared into those policies, either some physical or virtual interfaces, five tuples or even more flow-based mapping, GTP header remapping. And this is how you actually create what they call segment routing network policies, is based on those parameters, you create constructs. I can do a layer two pseudo wire over an IPv6 header by doing the end.dx2. I can do IPv, layer three VPNs with the DT46, which is a decapsulation in a two IP table lookup. And I can also do something which is quite getting quite a lot of traction right now is remapping GTP into IPv6 setters. So you can completely remove the GTP problem to simplify your encapsulation in the network and then reconstruct it later on. For those who were not there at Mobile World Congress, SoftBank did quite a good demo on this. So what we did is we look at how could we leverage SRV6 with Celia because of the EBPF base it has in its data plane. And how could we construct a new way of doing networking for our clusters? So working with the ESOventine, we looked at various scenarios and I'm gonna do a small talk and then afterwards I'm gonna try to do a demo if the wifi agrees with me. So basically, based on the fact that it's pure IPv6, so a cluster that is completely v6 doesn't need to have any encapsulation. The only thing that really makes it work really quite well is if you're able to run in something what you call flat mode or in the case of Google Cloud, they call it VPC native but EWS of the same. So you don't constraint your IPv6 addresses of your pod, you let them loose as I would say. And based on this, v6 routing doesn't need to think about anything, not even segment routing v6. v4 on the other hand, you can actually encapsulate if you want to or you can use the CNI mechanism of Celium if you want like cluster mesh. But for a paradigm, we actually did look the way of can I have a v4 pod talk to another v4 pod using an SRv6 encapsulation over Celium, and that way, you make your underlay network completely v6. We also look at the way to do cluster talking to a L3 VPN PE, physical PE in the network. And how do you do this from Celium? The beauty of this is I have a single interface. I have no multiple interface to talk to VPNs. I don't, I can still associate my pods to multiple VRFs based on the egress policies. Because you remember in SRv6, I was talking about SR policies. In Celium, we constructed the notion of SRv6 egress policies. So based on criterias in the pod definition, you say I need to be attached to VRF zero and one in the case of our demo. And based on this, with the route Celium learns from the BGP, these BGP neighbors is able to construct dynamically the egress policies associated to the VRF. So that single default route, single interface, you can still got default internet or default behavior with the standard construct of Kubernetes. But in the case you need to go somewhere in the deep of your network through VRFs, you can use the egress policies of Celium and it makes it works. In our case, as I showed there, the pod needs to go talk to an application over an L3 VPN PE in SRv6 domain. It just goes across. And then the beauty comes with the rest of the integration when you look at SRv6 overall. So Celium still does its magic, integrates single route table, single interface. The egress policies still there, but oh by the way, the destination PE is not SRv6 is a legacy classic MPLS. In that case, the SRv6 architecture allows for gateways to be able to translate from an SRv6 domain or IPv6 domain to any other model. In that case, we do MPLS. So going from an IPv6 flat net fabric, no SRv6 device unless except for the gateway function that translates into MPLS. And my cluster is still able to go and talk to VRFs. And then I can do a service insertion. For those who were at MPLS Paris this year, I did a remote talk around the fact that we integrated physical devices into an SRv6 domain using services proxy, kind of the logic of an envoy proxy, but or like a proxy less mesh. For those who are able to do it, but for physical device as well. And in that case, CILIUM does the same magic, single interface, but now you can construct either dynamically through BGP advertisement or statically through the policies created in CILIUM. You can also insert physical or attach physical services within your network to that construct. So I can actually create a chain from my network physical devices or virtual network elements. It's still going to the application. And if you look at this, this is the simplicity of interconnecting the clouds in an environment. I need to map VRFs or VLANs from a cluster, make them go to our network, redo the mapping to any VRF I need to have in my network, but I still need VRF in my physical network. Now go to my interconnection, map that back to VLANs. And now I go to the clouds and the clouds don't have multi, so I need to create a large amount of VPCs and try to interconnect them. If you look at this, and if I can start having my clusters be able to do a basic IPv6 overlay end-to-end, the only thing that missing now is to be able to say, well, public cloud, can you just provide me IPv6? And in that case, I can actually do a single flat IPv6 address scheme with my cloud providers and my VRFs or my isolation I need to have it will be done directly by the CNI. Before I go to the demo, if you do you think you wanna pass the questions for after you wanna go to the demo in case it actually works. So what could go wrong? I think right now it's only the wireless. Sorry. Simple demo topology. So I have Cilium with two pods that need to talk to two different VRS but the same address scheme. And there's a physical PE which is running FR Linux because FR supports a service X. And at the end I have the devices. So I'm gonna show the pods. I'm gonna show the routing table of the pod, the interface of the pod. I'm gonna see the encapsulation happening in Cilium from when it case it goes to a service X and the case where you don't see any encapsulation because it's actually doing the default routing of the pod. Wi-Fi is still up. Yes. Now it's gonna be fun trying to do this remote. Okay. Wi-Fi. Okay. This is fun. You make the text bigger. I actually try to see it from the back. Okay. Oh my God. I think I'm gonna have to do a session with the table with the speeded guts. Okay. So I have my two client VRS, the client pods that are attached to different, that need to talk to different VRS. I'm gonna try now and show you the routing tables. I'm gonna switch to this. God, it's painful. Sorry guys, I'm trying to get back my command but the speed of the Wi-Fi is not helping me. Okay. So I'm gonna first start to show you. I'm gonna show you a policy so it's gonna help. So you see this is a dynamic policy that was created through the route advertisement that it receives. You have the VRF ID and the destination SID which is a segment routing ID that's gonna use at a remote PE. And you have the destination SIDRs that are used to map for the policy. I can just try to get you to the pod. Da, da, da, da, da. Sorry. This is painful. Let's try this one. Come on. Okay, I'm gonna switch things. This is not helping me. Okay. No, I'm just switch mirrors so it's gonna be easier for me. No. You don't have to borrow my Wi-Fi. Oh, but it's a bit too late. Yeah, maybe too late. Okay. It's for hours. No, it's okay. I'm gonna make it work. Okay. So first I'm gonna show route. So you see that for those who don't see, sorry, but I only have one single interface in my pod. I only have one and one route. Now I'm gonna do a ping of Google, the famous Google. So you see here, you only see the BGP advertisements coming up, but there's no traffic going through the PE at the end remote because the traffic is not encapsulated. It's not part of the egress policy. So it's basic net curatees networking going on. There's nothing happening. Now I'm gonna switch and you're gonna see now I'm gonna ping the right location and now you see the encapsulation happening. You see the source address 10.1.156 going to 10.3.0.1 being encapsulated into SRV6 from Celium. So I can now use an L3 VPN. In that case, we did a L3 VPN going to a remote PE using IPv6 SRV6, but again, no multi interface, no secondary CNI, a single one. And it's just a matter of having the right BGP policies and the EBPF code to map that back into dynamic egress policy. With that, I'm gonna go back to my famous presentation. If you wanna have a session, the question about the way that things are constructed after because I burned so many valuable minutes on my demo, we can do the discussion afterwards. No, again, I'm low. Okay, let's go here. I'm gonna stay this way because for some reason, so the next step. So right now, FRR only works with SRV6 in the mode of base IPv6 segment ID under 28 bits. The next step is working through the community with FRR to support also the micro-SIN instruction by 16. The good thing with FRR is it's part of the big sonic community. So a lot of people are already working through that effort with SRV6. So we're not alone in our world. Second one is optimize the SID allocation. How do we do a good, clean addressing scheme of IPv6? This is pure like trying to figure out the right model to do the addressing scheme based on how we do IPv6 assignment in Kubernetes. Finishing the work with the ISOvalent team on the BGP integration to make it crisp and production grade, I would say. This is the part with the CDM project with the team. The rest is really keep tracking the IPv6 development in Kubernetes to ensure we don't end up redoing V4 but really maximize how IPv6 is used. This is for those who remember, which is actually a good thing. When you look at how you could use IPv6 in Kubernetes, if you really wanna go crazy and try to burn 10 million containers per second, it will still take you 58,000 years before you actually max out the slash 64, which is right now how we do slash 64 in assignments and pods. So I think we can burn a few IP addresses to build the network properly rather than do not port forwarding and all those things. I think this way we can actually do this. And I also added a link, which is around something that came out of the internet, the innovation of the internet from Etsy, which is around the design of IPv6 data centers. So a big thank you to the Asovalent team, they have been ninjas with me, hop until three morning, three o'clock this morning to make the demo crisp and clean, although I messed it up with dealing with screens. So a good shout out to the Asovalent team, Luchano, Christopher, Paul, and Yutaro. We're really, really helpful with this. So if you have no questions or if you have any questions, please go to the mic so that everybody can hear. I think the mic is not on though. All right, okay, now. So first of all, thank you for the great talk. I think we did something similar within Deutsche Telekom, not with segment routing, but a bit differently. I have one question because we've seen it with vendors. They heavily embrace and want to use multis for secondary interfaces within pods and heavily push back on a, I have one interface with different routes approach. Have you seen something similar and how to approach that? Or how do you approach that? You're right, we still do see this. And the question I would ask though is why? Except for, except for high speed interface, actually we can do with the FXDP. Right now, actually with a Cilium code, we actually did like 23 gigs out of a 25 gig NIC, so SROV pro for me would kind of seem something weird to have to fend them. But anyways, most of the time, it's really around, there's cases with protocols not supported inside, but if you look something like this with a pod directly, with an overlay, whatever protocol you need to pass to the pod, as Kubernetes doesn't see anything at that point, the pod still needs to do it. If it was V4, I understand you need to go through services because of the limitations, but V6 right now would not have. So I think it's more cultural than really a big technical reason. Yeah, I think so as well, thank you. No other question, oh, there's a question. Okay, last question. If you have any further questions afterwards, I'm here all day. Okay, so my question is that how much does the platform infrastructures are supporting this technology because if we rely on this, then it should be everywhere basically. Can you please repeat a bit louder? Yes, what is the support of this in platforms like in Google Cloud or in AWS? So in AWS, funny enough, I did this in 2018 and it worked like a charm. So from Montreal to Toronto going through OIO East, SRV6 and 2N, I had never had any problems. So the question is more around the way how Syllium is supported. Actually, Syllium is the default CNI for both Google Cloud now and Amazon EKS. So I would have trouble understanding why this would not work in that case. The only trouble I might say though, is the MTU size, but it's gonna be the same for everybody. If you have any communities instance that has now a large MTUs because they do telco workloads, but their interconnect doesn't support a large MTUs, they're kind of in your own world. So that would be the only case right now. Thank you. Thank you very much.