 Hi, everyone. Good afternoon. Thanks for coming to our presentation today. My name is Rani Hybi. I'm the CTO. For those of you, I see some familiar faces here, but for those of you who still don't know me, I'm the CTO of Networking Engine Access at the Linux Foundation. You might know me from my previous life as an assistant architect working for various Linux Foundation member companies like Nokia, Samsung, and Alcatel Lucent back in the days. With me today is Tyler Carpenter, who's the CNF workgroup co-chair, one of the co-chairs, and also the co-owner of the Vulp software cooperation. And we're going to talk about the future initiative or where the cloud-active network initiative is going with the Linux Foundation. So we're going to do a little intro and I'll explain what I mean by this cloud-active network initiative, speak about the motivation and what really brought us here, and what are we are trying to achieve, what are our goals, when is it going to happen, the timeline, and I'm going to speak about how it relates to, we are going to speak about how it relates to some existing assets that you're probably already familiar with or already actively contributing to. And then we'll stay tuned because we're going to ask for your participation, so please bear with us. So what are we talking about here? I think we all know that when it comes to telecom, everybody's talking about the transition or evolution to cloud-native, meaning we want to use technologies that were proven to be efficient with enterprise computing, with hyperscalers, and we want to bring him in to the telecom domain or networking domain, but the question is how exactly do you do it, and where do you go to, and what open source assets are available to you. And this is exactly what we're going to talk about today, and this initiative is all about helping you to adopt this cloud-native technology for networking, whether it's telco networking, enterprise networking, hyperscalar networking, whatever your networking needs are. So in a very basic form or in a nutshell, what we are talking about here is combining efforts, meaning that some of the initiatives that existed under the CNCF and were related to networking technologies will merge with some assets that we have at the LF networking, and we're creating a new home for everything related to cloud-native functions under one roof under the Linux Foundation networking. Now, a few of the other technology assets that are relevant to what we call cross-domain cloud-native in general will remain under the CNCF, and the CNCF will continue to build and evolve them, and as you can expect, we foresee a lot of collaboration between these two organizations, the LF networking and the CNCF. And what we are currently starting with or spearheading is focusing on two areas which are certification of network functions, and a test catalog to help that certification. We're also bringing in and keeping some of the work that's been done in past years around best practices, and we expect this program to grow over time and add other aspects, and I will hand it over to Tyler to provide more details. All right, so the motivation behind it. Why are we doing all this? So, a little bit of a back story. LFN has been doing networking since it started, that's kind of the point, and as cloud-native was getting going more and more, of course the networking needs have caused other projects and initiatives to spin up. Kubernetes, being cross-domain meant it's going to eventually need to take on more of what's in Telecom and Edge and other things, and so that's where, as Lucina had mentioned in 2018 during one summit, the concept for cloud-native network functions are really we're saying the network applications that are applications focused on network functionality that came into play, and so we have CNFs. What do we do from there? So then we ended up with a CNF test bed, within CNCF a Telecom user group, which a lot of folks ended up coming from LFN and other groups, and we produced a white paper, and then eventually there was the CNF test suite, and then we launched a beta certification within CNCF, and we've had a bunch of products now that have gone through that. At the same time LFN was working on more of the platform side, and how do we build this out? So the Anakit project, specifically on the Kubernetes side, was moving forward. There's a lot of collaboration between the groups, the cloud-native principles papers, which tied into the working group and best practices, that went right into the reference architecture for LFN Anakit, and we've continued to go forward, but one of the what we end up with is where do you get started on this? So that's I think one of the the main challenges that we had was where do you come in? What do you do? So that's why we're trying to bring this unified front and have some type of unified collaboration. So going from there like the motivation behind it, so we have this continued adoption of cloud-native into production, and Deutsche Telcom just launched a 5G standalone network that's running on these Kubernetes-based deployed platform and environment that's using like GitOps patterns and other things. Orange is doing similar things. They've had a I think 2021 was their experimental network, and that's tying in with silver and everything. They're trying to have full automation for the network in 2025. So these are like we're cloud-natives been here, but now we're really getting there in production. So there's this need for more testing and validation. How do we work with multi-cloud? If you're bare metal, which I've seen a lot of them, or if you're running across clouds, Telus is running on Amazon with some other 5G core. You have other ones in different areas. So that ties in with this vendor interoperability. So you've got a lot of different clouds. You've got a lot of different CNFs and components, whether you're on the core or all the way out to the ran, the edge, and how do you test? How are you going to validate? If you have one vendor and they're running their pipelines and they think they're good and another one, but how do you actually make sure that you're going to work well together? And then how does the operation team at a CSP, how are they going to know? So, you know, transparent validation testing, that's about the interoperability as well. And we're versions, releases. So as we move more to production, the deployments and upgrades, you have the testing and stuff that ties into all of this. But you also have the tooling and stuff for the automation. I was mentioning those GitOps patterns and everything. You have some people that are using Flux CD and Argo CD and others are doing Flux CD with Argo workflow. And then you have Nephio project that's doing some similar things and operator patterns. So the, you know, these end users, they're wanting to adoptions of this. And I think the testing and validation is a big part in that the real strong adoption of automation. And this is not just at the end whenever they're running in production, but I think we're also talking about how to give the creators the capability to do the testing and feel confident to get releases out faster. So just a little bit more on the end users. We're talking about the whole ecosystem here. Everybody is working together and we want this cloud native networking program to be valuable for the whole community. So whether you're a creator or you're an integrator, you're doing open source development, we're trying to make this valuable for everybody. And I think if you're a creator and you can be confident in your CI CD pipeline, then it's going to help you release faster. You're going to lower your maintenance and support effort. If you're a communication service provider, then, you know, you're driving those challenges and communicating. And we want to make sure those are out in the use cases, the challenges are upfront so everybody understands them and then relate the best practices there. And then ideally we're providing tests in a test suite that can be used by operators for onboarding. We can put it right in the pipelines. The creators, the developers that are building the different components, they can use the same sets of tests. So we can use it all the way through. And then as a whole, we feel more confident. And maybe it's right there, you know, we've talked with some folks like Microsoft for the Azure for operators and others that are interested in maybe even providing testing as a service. Maybe we'll see that. But I think it's important to think about it as a whole. All right. And I'm going to turn it over to Ranny to go over a little bit of the scope now that we've talked about the motivation. Yeah, so hopefully you got a little bit curious about, okay, what exactly is this program? So the next slides will provide hopefully some more details. So what you see in this diagram, and I'm sorry, it's a bit busy and maybe the not perfect choice of colors with the old yellow. So didn't realize that. But anyway, I wanted to focus on the lower part of this diagram. And it shows kind of in this green frame what we're talking about. And it starts with on the left, lower left side with best practices about how to build the network functions and deploy them. And that covers everything from the edge of the network to the core across everything that's in between. And on top of that, we propose or we plan to have test tools that will help you make sure that you've correctly followed those best practices. And on top of that, there will be certification, which will be optional. If you want to go all the way and kind of get your CNF through all the tests and eventually make sure it's certified to follow all the best practices. And what you see here on the vertical, on the vertical axis is where we're going to focus. So starting at the bottom with things that are more what we call foundational. We mean things that kind of validate the follow-ins of basic cloud native tenants, which are not specific to any specific network function or any specific implementation of the cloud. But over time, we hope to add more test and certification that will be more oriented toward our existing open source projects, things like Anuket for the infrastructure, things like nephew for how you orchestrate and manage those network functions. And also maybe further along the line, serving projects like Silva, which is defining how to build a standard compliant cloud native infrastructure for telco and Kamara that deals with the exposure of APIs, but also has requirements for the network function that are providing these APIs. So again, it's a lot of different blocks and things that and it may be a bit over the place, but what we are trying to start with is maybe the lower layers and the best practices, test tools and certification that we'll talk about in more details. Now, you probably are familiar with this diagram. Don't worry if you've seen it for the first time and you're a bit overwhelmed, but if you are familiar with the work of the Linux Foundation Networking, I'm sure you've seen this diagram. This diagram kind of gives you an idea about the ecosystem of open source and commercial offerings that are out there that enable you to build end to end network services using leveraging the best of open source technology. So this new initiative that we're talking about is not disconnected from this landscape. It's actually being built with all this landscape in mind. I already mentioned a few of the projects that we plan to work with or collaborate with in the short term, but over time we think that we will have more collaboration with other projects and in general the goal of the initiative is to help you build end to end networks using these building blocks that are also compliant with the open source and cloud native best practices. So again, probably a lot of information to absorb for the first time, but just to kind of make things more specific, what we are focusing on right now is how to test and certify the cloud native network functions or applications or CNFs. We, something called them for short, but in the future we're going to kind of expand the horizon and look at things like the platform itself, the automation of the deployment, not just the initial deployment, but also the entire life cycle. We're going to look into things that may be relevant, for example, RAN or in our case Open RAN more specifically. And we're also at some point probably are going to be able to offer project specific testing and certification. And we mentioned NFU is one example of a network orchestrator that we're looking to work with closely and create testing and certification that are specific for cases where NFU is used. Yeah. And so I mentioned, we mentioned tests a lot and I want to make clear that what we envision is an approach of a test catalog, meaning creating a large set of tests and test suites, but providing them in the form of a catalog, meaning it's not a big monolith that you have to use as a whole or not, but rather a catalog, as the name suggests, where you can pick and choose the tests and certifications that are relevant to your use cases without having to worry about things that may not be relevant in your use case. So we're going to, as Tyler mentioned, we are aiming to serve whoever is building and deploying cloud native network functions. So whatever helped that adoption, we hope that program will bring. And this kind of modular approach to the test catalog, we think will help with the adoption of this test and certification, meaning that everybody can use as little or as much as they need from that catalog. Yeah. And so I started by kind of highlighting the things we feel will be the short term deliverables of this program, but we have great plans for later. So I'll let Tyler say a few words about that. Yeah. So we're coming to the end of 2023, but we're wanting to keep the momentum going. So I think maybe the first thing to say, I keep saying it's at the end, but the community side, we're wanting this ecosystem to have input from everyone. And we are going to try to keep going with the certification and the test development that we have right now, but we want to make sure and keep getting input. So we're going to have a workshop tomorrow. I'll talk about in a minute. And you can attend remotely or in person. And we have a lot of existing resources. So if you have ideas on stuff that's happening right now that you think would be useful, so whether it's part of the test catalog tooling framework, best practices, then we want to hear from you and keep that going. I think this transition is going to be happening through the end of 2023 and into the start of 2024 as far as the actual tooling and testing and certification going over into LFN. We're going to keep supporting the existing products that have been certified. And if you're interested in certifying, it's available and working right now. So then going on with the goals and scope that Brandy was talking about, ideally the project specific, those other communities, Silva and Camara, if there's specific things like maybe specification or requirements that you think are relevant that are maybe in the Silva project or somewhere else that you think will be relevant across the board, then those are good to highlight earlier. And of course, if there's something you're seeing coming up in the future that's aligned, then please bring that in. The ORAN compatibility, that's already something that's happening in the test suite right now, the CNF test suite. And if there's areas that you're seeing like that for future, it's going to become more important and just bring it up. Okay, so a little bit about what we have now. This is definitely a broad area, so I'm not going to try to cover everything. There's going to be some things that we want to keep and then some things that we may say are not aligned. Maybe we're going to keep them, but there should be part of some other area. Elephant is huge. There's a lot of different initiatives happening. So we're really talking the cloud-native networking focus. The certification and test suite, they're working. We also have a lot of material in the Anakit project. The CNF working group, if you're not familiar with it, it has best practices, a lot of content. There, there's a white paper that was published, just a poll request for it on Friday, just this past Friday, and it's actually a follow-up for the NGMN cloud-native manifesto. So there's a lot of material that we can build on right now, and then of course if you know of something else, bring it up. All right, so I already said this, but if you want to get certified, it works right now. Please just try the test suite out. It's supposed to be, it is designed to be a useful tool. If you're creating network functions, if you're onboarding them, testing them, it's designed to run in pipelines. We're going to keep running these community meetings tomorrow. We have this alignment workshop. I think we can dig into some of the tools. We have a bunch of topics already listed. If you want to join, there is a limit for in-person. It's actually pretty low. It's only 20, but we are doing a live stream so you can connect remotely. If you want to come in person, scan it, get on the list. Maybe we can get a few more and we'll see, but please join. All right, so I think for the rest of our time here, we'll just have a couple of minutes, but Q and A, so any questions? Do you want to go give Gerge? Hi, Gerge from Nokia and Anuket TSC co-chair. So my question to this, whatever, the scope is that it seems that Anuket is out of the scope of this activity, but then what we are solving now is that we are moving practically the fragmentation only and we are not solving the fragmentation. So it should be somehow we should merge these two activities. What do you think about that? Yeah, and I think there's so much going on that it's hard to communicate all of it, but yes, we are wanting to merge the activities. What we don't want to say is it's all merging into Anuket or Anuket's all merging into here. I think what we're going to have is some pieces that we know are working right now that we want to continue and some parts that we may not. Probably the easiest to think is there's parts of Anuket that are going to be, whether we keep the names, I don't want to think about name changes. I think we will have Anuket as part of the cloud native networking, parts of it, just like we're going to have parts of what came from CNCF. So that will continue. What, Anuket's huge so I don't know what all we're going to keep and that's not something we're going to decide in one or two meetings. Yeah, maybe some, some addition to that. Anuket also has OpenStack-related documents and we are publishing a couple of documents to GSMA. So we have some dependencies what we should consider also. So there, it may end up, and this is to be considered in discussion within I think the community and you know the different aspects of this, but potentially the some of the OpenStack and other pieces would continue as its own effort separate from this or maybe a subset. I think that's undecided. Yeah, I think the guideline is to serve best our end users and we need to figure out together and this workshop tomorrow is part of it what makes the most sense. So let's try to kind of think about our customers and figure out, I don't have the answer of what parts of Anuket will go where and we really appreciate the opinion of Anuket leadership on what they think would work best and again we are all in it together to serve whoever is building, deploying, testing and operating CNFs. I think one other aspect to think what this probably motivation a little bit but there's been an effort to maybe take on too much. It's all going to be solved and you're going to be able to be compliant with every single thing even when it's conflicting. Just don't look that it's conflicting. So we're trying to see if maybe we can shrink down the focus potentially to have here's what we know is going to work well together. When you go and this is also we're thinking it upstream. So if we look at something like Silva, well Silva is also thinking about European specific regulations and then there's other requirements. But if we say we're an upstream resource for Silva and other projects then we should be more compatible with what they're wanting and then they can build from it. Any other questions? Kind of two. One is very quick, the QR code for the that was gone very quick to form. And the other thing is, is there any effort like going on between the Kamara project and this because one of the things if you take the telco industry from like a high view it doesn't necessarily resonate very well with developers and usually that's the last thing on the conversation. And if Kamara is trying to that you have this kind of network exposed functions or APIs that work across all the telco vendors and it's particularly the ISPs behind the telco vendors and then you have the certification process. Are you building any bridges to have some like requirements there to pull this whole you know cloud native kind of adoption. And like more specifically like if you think the customer profile on that side or the kind of end user experience is that you know there's this interoperability where app developers and everything can build properly on top of telco networks. Not just the basic you know SIM card plan where you have data know that but actually utilizing the cloud native functions that you're like pushing here inside this kind of telco movement but actually showing them that this is going to generate more revenue. Thanks. Yeah Rene probably has some on that too but I think what you're talking about with tie right in at the higher foundational level so declarative APIs and declarative configuration is a core tenant and what you're talking about with the APIs would be part of that and I know like Dish networks they've been pushing for having APIs where everybody can integrate and there's other service providers that are doing similar things. So that's definitely in the foundational side as far as like Camara specific I would say that would be future but anyone that is involved in any of these projects should try to help contribute upstream so that we build something that's going to be aligned and compatible going forward. Yeah just to complete that we kind of try to flesh out our kind of crawl walk run approach and starting with some basic things but definitely we're open and I think we fleshed out Camara as one of the projects we intend to support in the future but as Tyler said it's an open source community effort so we need people to work on that and if people see value in creating test suites and certification for Camara the project under that program they're more than welcome to join and start working on that. I think we're over on time now that's all right we had a good buffer anyway so if you have more questions you know please join this and you feel free to reach out to us we definitely want everyone to be part of this new effort thank you