 I'm Lucina, and I'm here with my colleague Akash. We work at Vault Cooperative. It's a software cooperative that helps CNCF with strategic initiatives to help cloud native, to help the cloud native computing foundation make cloud native ubiquitous, including with their telco initiatives like the CNF certification program. Has anyone here heard of the CNF certification program by CNCF? About half of you. Great. We're excited to share the latest and greatest of the program. There was a press release out today ahead of telco days, so be sure to check that out. I'll give a history of how we got here, what we're working on now, and what's next. Akash will join us for a deep dive on the CNF certification process, how that works, and the underlying framework, the tooling underneath of the tests. And we do have time for questions at the end, so please hold your time for Q&A. If you'd like to follow along, these slides are all on schedule, so you can check that out. So firstly, CNCF is a community-driven place for projects and initiatives, so we wanted to thank the community, first of all, for helping us with the contributions, the thought leadership, and your support. So thanks everyone who's helped us along the way, and thanks in advance if you're interested in helping us and contributing later. The CNF certification program provides confidence to CSPs to make sure that their vendors are using cloud-native best practices in their networking applications. So we know that CSPs are migrating to cloud-native, and CNCF created a micro-survey earlier this year to better understand why. And as Phillip mentioned earlier, they're looking for eliminating vendor lock-in and dependencies, decoupling hardware and software, interoperability, flexibility, agility. The CNF definition, CNF contains one or more micro-services that follows cloud-native best practices, like declarative API, immutable infrastructure, and a repeatable deployment process. The initial definition of CNF was defined in 2018 by Dan Kahn, Ed Warnacky, and Frederick Kotz at ONS in Los Angeles. And there, a challenge was given to us. How do we apply cloud-native network functions to telco applications, and how would we measure the benefits of going from VNFs to CNFs? And with that, we created a prototype, the CNF testbed, to validate CNF proof-of-concepts with FDIO, Intel, and Cisco. At KubeConnEU, the telco user group kicked off to facilitate discussions between service providers and vendors and also connect like-minded folks who are ready to move from VNFs to CNFs from monoliths to micro-services. We looked into each part of the CNF definition to highlight the attributes of what cloud-native means. In 2020, white papers were published, the cloud-native network principles, and the cloud-native thinking for telecommunications. And the CNF test suite started, all with help with service providers like Bell, sorry, Bell and Vodafone, and vendors like Nokia, Samsung, Intel, Volk and others. To complement the test suite, the CNF working group was created to document best practices, cloud-native best practices for telco use cases. And at the end of 2021, the CNF test suite had over 60 tests running from contributions from CNF projects like litmus chaos to test self-healing, open metrics to test observability, caverno and Cubescape for security. And earlier this year, the CNF certification version 1.0 beta was announced at Valencia. So as of today, we have five certified products from vendors F5, Juniper, Matrix and Pantheon Tech, and more on the way, more in process. The CNF certification program is different because it's open. It uses open source, open standards, open implementations, and it's a community-driven bottom-up approach so that it uses the cloud-native ecosystem experts to create the standards rather than a top-down standards body approach. And there are no kingmakers. The CNF prefers to allow a healthy competition in its ecosystem, so it doesn't like to say this is the best solution for all. It allows competition and it allows choice. So this means that telcos can choose to adopt the cloud-native as practices in addition to standards that also meet their business needs. And it means that tests in the implementation come from multiple sources. So we have security tests from multiple sources. While there are several certifications for telcos that test interoperabilities of CNFs on a vendor-specific Kubernetes platform, the CNF certification tests on any certified Kubernetes environment and checks cloud-native principles like interoperability, resilience, workload self-healing, just to name a few. To earn a certified CNF badge, you can get started on the landing page, cncf.io slash cnf. Participants will fill out a participation form with eligibility requirements. After they run their CNF through the test suite, they'll submit their pull request with their test results to us, and then they'll earn the certified CNF mark. And be listed on the landing page as well as the landscape for CNCF. Some frequently asked questions. The CNF certification is per product, and there's no limit to the number of products a company can certify as long as each product has its own participation form. And there's no charge for CNCF members or nonprofit organizations. So what's next? We'll continue to collaborate with providers and vendors and cloud-native ecosystem to document those best practices, including the operator framework, a CNCF incubating project, the tag app delivery, and LF projects like NFIO for automation. And also we hope to have a new release ahead of KubeCon EU. Speaking of, we wanted to mention some upcoming events. So tomorrow there is a chaos day, and the team will be talking about our litmus chaos test in the CNF test suite and the CNF certification. And next month we'll be at One Summit Seattle for Lightning Talk, and we'll also be doing a hands-on tutorial on how to run the test suite or run your CNF through the certification program so we can walk you through that process. And KubeCon EU will be held in Amsterdam in April. The CFPs are open until November 18th for that, and stay tuned for the CFPs for the next telco day and start thinking about what you might want to see in this program or what you might want to present yourself. All right, please welcome Akash to the stage to talk a bit about the CNF test suite. Hi, I'm Akash and I have a fast heartbeat right now. Okay, so I'm going to walk you through the CNF test suite. It's Breeze. So the CNF test suite is designed to help developers and ops teams by codifying best practices that are part of this CNF certification program. It helps you stay aligned with the cloud-native ecosystem, various concepts, and projects. It also has a fast execution time, so if you were to use this in your CI pipeline, that is supported, and you can have faster feedback loops for your development and for your pre-production checks. Now, the test suite that we have leverages upstream tools wherever possible. We use Prometheus, OpenMetrics, Jager, and Floundy to test for observability. We use Litmus Chaos to test for resilience. And we use Kivarno by Nirmata and Cubescape by Armo to test for security-best practices. We also use Helm to test for configurability and installability of CNFs. Now, these are just some of the tools that we integrated. There are a lot more. Now, the test suite requires a multi-note Kubernetes cluster along with Helm, KubeCuttle, and CURL. The test suite is compatible with any certified Kubernetes platform, including distributions from AWS, Azure, Google, Red Hat, and kind. You could use any of the other distributions also. Let us know if you're using any other distribution or environment and we'll try to support it for you. Now, you can run the test suite in 5G steps, download the test suite, run the setup command, create a configuration file for your CNF, and install the CNF using the CNF setup command, and then run the cert command in order to be able to run all the tests. Now, when you run the setup command, you should see something like this. The setup command checks for prerequisites and it also installs certain tools that are required by the test suite to run certain tests. And the test suite requires a YAML configuration file to test any CNF. At a bare minimum, this configuration file needs to include the release name, anything that you choose for your CNF, the Helm chart to install, and the Helm repository to pick the Helm chart from. To install the CNF, run the CNF setup command with the CNF option with the path to the YAML configuration file that we just created. And the file that we just created is the code ENS and we're going to test that with the test suite. So let's run the cert command in order to run all the tests. Now, you see some output there that's in red, yellow, and green. Any lines in green, it means that your tests have passed. You have lines in red, that means you have failures for your tests. And if you see lines in yellow, those are tests that are skipped. That means that there are certain tests that are being skipped because they don't meet the criteria on your platform. Now, all the tests that we just run as a part of the test suite or the cert command that we just saw, those are the seven categories of tests that are best practices that Lucina just showed off in the previous slides. Now, after the cert command is finished running, it outputs a summary that looks something like this. It tells you the number of tests that have passed. It also displays a file name where the results have been saved. Now, this is what the results file looks like if you open the YAML file that was saved after the cert command. It contains the same information that was output to the console, but it's in machine readable format. So you could include this as a part of your CI pipelines if you were to use it for daily development. You could put this in your GitHub Actions, GenKens, or any other CI system that you work with. And we already have end users like Dish Wireless, Matrix, and Anuket that already integrated the test suite as a part of their development process. Now, the results file is essential in order to get certified. In order to get certified, you would create a pull request to the CNCF slash CNF certification repository with some information that includes the product name, the product version, the vendor of the product, and the results file itself. The repository has a read me with detailed information. The link is on the slides, which should be available to you after the talk or if you have downloaded the slides via the QR code. I would like to bring Lucina back to tell us about how we can work together. Live long and prosper. All right. Thanks, Akash. Yeah, there are a lot of ways that you can collaborate with us. We have meetings on Mondays for the CNF working group to document best practices. We meet on Tuesdays for the CNF certification and CNF test suite office hours. You can also find us on the CNCF public Slack. As well, you can send us an email or forward our email to any of your colleagues who might be interested. If you'd like to schedule a demo or working session of the CNF test suite, this is our calendar. We're available here all week at KubeCon and we can also meet with you on Zoom anytime remotely. And if you're ready to get started and join your CNF in a growing list of certified CNF products on the landing page, feel free to get started at cncfio slash cnf. So we do have some time for Q&A. I'd like to introduce and bring up the contributors and some maintainers of the CNF test suite who can also help answer your questions. You can also put the name to the face and know who to reach out to. Hi, Will. It's about Will Harris. You're welcome to just hang out on the front, too, if you want. Avoid the steps. Taylor Carpenter. Hi, Denver. Watson and Drew. Do we have any questions? Got a first question. Hi. Delore, you actually tried to explain for me how the scoring works, but I do not really get it. Can you explain it a bit more like what cases are mandatory, what cases are not, and how the final score is calculated? All right. The question was, can you explain how scoring works and what is mandatory? And it was specifically to Taylor. So there is an essential test, normal and bonus test. That's kind of how we have it split right now. And there's the set that are included in the certification, and then there's kind of extended beyond that. The essentials test are, and what we're looking at is more of, what do we have now and what are we going for in the future? So there may end up being levels of certification. So certified, maybe we'll have like silver, gold, platinum in the future as we're going forward. The essential are those baseline tests. Here's what we think every application and workload should have. And to get certified, you have to have at this point 10 of 15 of those essential tests. Looking towards those others are saying we're adopting more of those best practices. And as far as scoring goes, that's what it is right now for getting the certified level. It's the number of tests out of the total. Does that answer your question? Thanks. Any other questions? There's a lot of different pieces that make up a stack and can alter the behavior of a given CNF. And so how do you see this interacting at like validating a matrix of different components from the hardware to the Kubernetes layer, to the CNF itself? Or is this really trying to be focused strictly on the software that's powering the network? So currently the CNF certification looks at workloads that are running on Kubernetes. And would anyone like to expand on that? Nina said it's true. There's also, as far as the platform, there's an Anakit. So we could talk to Durga about that. So I think part of the idea is to look at also the applications and you have, in a workload, you may say there's many different applications and some are at a higher level and they look the same as any other Kubernetes applications. In that case, you just say, it's simple, you should be adopting any of the best practices that are applicable to any Kubernetes application. And where it starts looking different, I think, is maybe in applications that are going to be related to like what was the F5 talk earlier. So what are you going to do on these different networking pieces? But even there, you can talk about best practices on different aspects of the application. Before you get to a point where you say, well, we're not quite sure because we don't have a standard yet that the community has adopted. But that doesn't mean all the other parts. And then if you're looking at the something like 5G applications, you may say, well, all of these components in the core network can follow these specific set and focus on getting those going forward. I think with like Facebook's magma, you're seeing some of that where you see some of the interfaces are not going with the standards that were in the past because you can maybe use something newer that's a good fit within a Kubernetes environment. But then they'll have other pieces around the edges that may use a 3GPB standard. So obviously I believe in this because F5 has certified some of our CNFs. But there are other CNF certifications and as much as I love my friends at Red Hat like they have their own and a bunch of their stuff is super specific to them like you have to use their base image, you have to be in their marketplace, this kind of stuff. Is there some thought of maybe using like the CNCF certification as a base? Like having some of these others start leveraging it as like a first step in certification? Has there been any talk there? My initial is yes, absolutely. It is a base layer. We know that it's not going to solve all problems for all telcos. We do hope that it solves, eliminate the ambiguity of what we're saying when we say CNF and what properties we're looking for when we say CNF or cloud native network function. So we do hope that we can gain more end users from those telcos, other conformance that might find value in some of the tests that we're checking that they're not yet. That aren't specific to one vendor's platform but can be applied broadly. We've reached out to several of the projects and orgs too including Red Hat. So there's some of the tests look like they're very similar or a complementary. I don't know if I haven't tried to run the Red Hat test suite which is on GitHub in other environments. I'm not sure if it would work outside of OpenShift. But we've tried to make sure that the CNF test suite works in any environment where we're seeing end users they're running theirs. So running an OpenShift would be a good baseline. So we're saying yes, if you pass the CNF certification, then you should be good on some portion of whatever you're going to have on a maybe a distribution specific testing. And so it would add on there. So I think it is a good place for that. Anacut has been focused on the platform side mainly for the last 18 months or so. But they have some workload application specific that would get into and what I would think of is like a Kubernetes distribution and having opinionated ways of doing stuff. But you're still going to start with base Kubernetes and then build out what are the components on there. Well, you're going to have Kubernetes native pieces that you may want to adopt and you're going to have cloud native pieces that maybe go beyond that. So yes, it's a good place and we're definitely open to those conversations and we're advocating within CNCF to do that. That's part of what they want is to do that. But to work with this specific one is like what is LFN coming out with? What is Red Hat? What is Google coming out with? Definitely open to that. And anyone that has conversation would like to have conversation. Please reach out to us. How much of these is specific to telcon CNFs and how much of these can be used to other types of cloud native workloads? Who wants to take it? Yes, so at the moment the way we've got the platform is it's there's a lot of tests that are you know kind of focused on CNFs but we've got a few there where we're running against core DNS and other applications. So I mean arguably we can test any application containerized application that's doing operating on network layers. So if it's free up if it's operating on an network stack layer then we can do tests against it and check whether it's following cloud native principles. Yeah and I guess that's another thing Taylor just mentioned which is in line with the chaos talk we're doing is we're testing resiliency and availability of the application and that's something that is really applicable to any cloud native application whether it's telco or enterprise. More questions? Just can you go back to the first slide with your opinion? Sure. Okay we got time probably for one more question. Anyone else? Okay right well big applaud, warm applaud to all of you on stage. Thank you very much. Thank you. Okay so we're gonna have a coffee break now out in the foyer.