 Okay, I think we can get started now. So thanks everybody for joining today. This is the Telcom user group monthly call. Just a reminder that this call switches between more APEC friendly, which is this call, which is at 11 UTC and next month, it'll be the more US friendly time at 1500 UTC. Before we get started, I just wanna quickly run through the agenda. So pointing out some of the upcoming events that we have, but is there anything anyone wants to add to the agenda before we jump in today? Okay, I know, is why Linda Lee from China Telecom on the call today? I know she wanted to present last month. Okay, it doesn't seem like they're on the call today, even though they listed themselves in the attendees. So I guess we'll just skip that point. So upcoming events that we wanna point out, there's the Etsy plug-fest in February and the CNF test suite developed by the CNCF, will also be there to test out the cloud nativeness of cloud native network functions. And so if you're planning on attending, look forward to testing out how cloud native your CNF is. And then we have kind of two things coming up today or two things on the agenda for today. The first is a white paper that was originally started by Jeffrey Seilins around telecommunications challenges and drivers. And this is something he kind of wants to move forwards on in the new year. And so if we look into this doc, it was originally started in 2019 and kind of the goal of this white paper is to dive into kind of what is driving cloud native transitions in telecommunications and also kind of what the problem statements or what the problems are as telcos try to go more cloud native. And so what we're looking for is people to contribute to this and continue to develop some of the ideas in here. So he's kind of laid out the initial framework of different challenges and different drivers for the cloud native transition. And what he's looking for right now is people that are interested in helping write up different sections. So if anybody on the call today wants to kind of like volunteer for one of these sections say for the generic telco one of the challenges and going cloud native is integration into existing systems, tool sprawl operation I operate rationalizing new tech layer two, layer three integration. There's lots of different things on here. If there's anything else, please feel free to jump in. Does anybody have any like questions about this so far? Hello. Yeah. Hello. My name is Asis and today is the first call I'm attending the user group. So I would like to ask the question the challenges mentioned in the document are taken from the vendor perspective or it's just the user group like they have come up with the requirements from like from the past experiences or taking the cloud native journey to forward Yeah. So this, yeah, absolutely. So Jeffrey Salons is at charter communication. So he's an operator. So I think this is focusing on the operator perspective. So service providers and operators go more cloud native. What challenges do they have? And part of it is kind of understanding the hurdles that we need to get over and learning from the NFV transition. Okay. And the other thing like can we introduce more challenges or is it just have to be like we have to work on these challenges itself? No, no, no. You can absolutely add more challenges. So if you think there's important ones that are missing please feel free to add them. We'd love to have your contribution. Because like what I see in the generic telco in the NFV section like these are more towards the wired infrastructure like it's more towards the core network side or more towards the like the transport network basically it looks like that way. But it doesn't capture the RAN specific like operations or the what goes into RAN or like in the more importantly the protocol stuff of like a E node B or a G node B in that sense it doesn't have those challenges listed here. So. Okay. Is there something specific that you want to put down in the document? Right now, no, no. Right now, I won't put it down anything. I'm just asking like can we introduce more challenges or like can we reduce a new category of like making a RAN section for the for the NFV like cloud native journey for the RAN also not from the just NFV perspective or the transport network or yeah. Sure. Yeah, absolutely. So do you mind if I put your name in here as like you suggested this as a section? No, no, it doesn't matter. There's no need of any name or anything. No, no, it doesn't matter. Please, yeah. Okay. I mean, this is a common document, right? I mean, it doesn't matter. Yeah. Okay. But yeah, if you have more ideas or want to contribute something, please feel free to flush out this section. I'm sure other people will start contributing it to it too. Okay. Okay. Thank you. Yeah. Does anybody else have any questions on this document? Okay. So if you're interested in adding more, please feel free to start contributing to the doc. Obviously anybody can start writing in there. The second part is so Tal from Red Hat is currently sleeping because it's about five a.m. for him right now in the U.S. So I'm going to give a brief presentation of something that he's interested in talking about. So apologies Tal, if I don't do it full justice. But so what he's interested in kind of talking about or starting up is kind of a group to talk about Kubernetes networking orchestration. And I guess when we say networking, this isn't like layer seven, it's more layer two, layer three. It's because obviously there's already SIG networking in the CNCF and the Kubernetes networking SIG, but those are more a little bit different than what he wants to talk about in this. And so starting, I guess the starting point is like Kubernetes networking is to bear because there's really only one layer three network for all the pods. One of the fundamental concepts within the Kubernetes is that all pods can talk to all the pods on the local network. And you can also create services, but that's not the complete way to do it. And so there's currently four different parts that are core to Kubernetes networking, which is the CNI plugin, which is in charge of IPAM and internet connectivity. Qproxy allows services to have stable virtual IPs, DNS, which is decoupled from IPAM and optionally there's also the ingress controller. But the problem, one of the other problems is that Kubernetes has no option for multi-cluster networking. This problem is being worked on in the multi-cluster SIG, but it's not a solved problem or has a really good solution yet. And the real problem, especially for this group, is that this isn't quite good enough for telcos or for network functions. This really, this single altering network is pretty insufficient for telco needs. A lot of telcos have wishes for special types of network, including there too, hardware acceleration, WAN, RAM, and other exotic networks, let's say. People have tried to kind of go around these shortcomings with different types of solutions like multis, NSM, or DanM. But the problem is, is each of these have to be configured more at the platform level. And so therefore deploying a network function actually begins like way, way, way before. It really starts when you're deploying the platform too, because it's so tied to that. And so a CNF can't be just packaged as a Kubernetes workload, because it's reliant so much on how the platform is set up too. And so it can be challenging to orchestrate network services at scale across these platforms. And so if we go back to previously previous clouds, like OpenStack, one of the key focuses there was isolation and portability between environments. And so the really big difference there is that layer three IP networks and subnets are actually resources owned by the workloads. And it's actually included in the platform. And so a virtual machine can connect to any number of networks rather than just the one main one. And so therefore the networking providers like Neutron actually do the heavy lifting rather than having to rely on the actual network function. And so what Tol wants to discuss is how we can kind of bridge the gap between these two systems in Kubernetes. And so one idea that he had is to bring back kind of the portability. So allowing us to move CNFs from platform to platform. And so the idea is, what if a CNF could request the type of network that it needed through a Kubernetes CRD, then the platform provider could know what's available and can handle the provisioning and configuration. And thus the provider can give visibility into how networking is being used by the app, by the node or by the cluster. And so in a way to make this cloud native in a narrative like automated fashion is they can be themselves become Kubernetes workloads. But one of the problems is a lot of providers would need to have privileged access to host capabilities. And so one thing that Tol kind of POC was this project KNAP which enables like cloud native providers for a multis. And so what Tol wants to do is set up a group that is interested in discussing these problems within Kubernetes. And so what he wants to set up is a little Kubernetes networking orchestration task force. And so what he's going to do is have a meeting to discuss this. One of the first ideas is to have a white paper under this telecom user group to discuss kind of what's missing and what should be done. And figure out the exact configuration of this group. So one idea is to have it fall under the telecom user group or create a new SIG within CNCF. And so I think this is kind of like a walk crawl runs this stuff or sorry crawl walk run. And this is still very much in the crawl phase. It's the initial things. This is he's kind of stated what the problem statement is. And now the idea is to bring together a group of people that are interested in it to discuss what the potential solutions might be. So if you're interested in being more involved in this please contact Tal, his emails here. And once again, sorry Tal if I didn't do this exact justice. But yeah, if you want to know more please feel free to reach out to Tal as he'll be kind of working on this going forwards. Are there any questions? Okay, that's it. Is there anything anybody else wants to bring up today before we close? Okay, thanks everybody for joining today. Just a reminder, the next meeting is next month on February 1st at 1500 UTC. Thanks for joining me today. Thanks Will. Thank you.