 Welcome to this CNCF session on an introduction to telecommunications from the Cloud Native Competing Foundation. I'm Taylor Carpenter, owner and a software cooperative vault co-op. I've been using Linux for over 20 years and an open source advocate the whole time. I've been working with CNCF the last three years helping with CICD, DevOps, Cloud Native Networking, and other items. If you'd like to continue this conversation for this ONES session, we'll be on the Cloud Native Networking Slack channel in ONES and these slides should be available in schedule after the session if they're not up there available right now. Priyanka Sharma, general manager of CNCF is also here and if you have questions during session please press the little Q&A button and add them in. Lucina and Product Owner on some of these initiatives, CNF Conformance, CNF Testbed, and Owner and Vault Co-operatives also here to help answer questions. Today we're going to go over the different initiatives. We'll talk about some of the driving factors and then dig in a little bit to each one of the initiatives, talk about how you can get involved, and have some time to go over any Q&A items we didn't go into during the live session. Alright, so the Cloud Native landscape is extensive as you can see here. Dan's had a funny tweet about it where some folks are finding it useful, some overwhelming, some call hellscape. The main point here would be there's a lot of projects, technology, groups that are building Cloud Native software and trying to help others. So CNCF would like to help service providers and developers in the telecom domain and navigating that landscape and trying to gain the benefits from the different technologies. There's currently three initiatives, the telecom user group, the CNF Testbed and CNF Conformance, providing output for the different end users. The telecom user group's a place to come together where we can discuss ideas, new technology, needs from the telecom domain, from providers, service providers, from vendors, and any telecom developers and look at things like best practices from different communities, talk about gaps in the technology or maybe processes. A lot of it can be the language trying to understand the difference. My audio is out. Okay, I hope I'm back, y'all. So the CNF Testbed is a platform, a framework, and a set of examples that help you in reviewing the different emerging technologies. And you can reproduce the test results, the use cases, any examples, you can also use it for creating your own. The CNF Conformance initiative is a test suite, an open source test suite that helps service providers and developers by allowing you to test the workload applications or cloud native network functions, as well as the underlying telecom platforms. This helps service providers to select solutions that meet their needs, when those solutions adhere to principles that are important to them. And it helps the developers in both demonstrating that they follow these best practices. And it also directly helps them to improve their software by providing feedback and tools in testing. Behind all of these initiatives, we have cloud native guiding principles. These build on years and years of other best practices and principles like those from DevOps, all the way back through Unix philosophies, agile software development, and other best practices and patterns. The cloud native definition talks about some of these and what would be expected to be seen in the technologies and how these can help a telecom make changes like security updates move quickly into production in a predictable manner. There's a whole set of cloud native networking principles papers that go in depth on each one of the principles that have extensive references to other documents, best practices and experts in the domains. And it helps us to ask questions from a telecom perspective, how you're going to configure these systems and how do we handle a mutable infrastructure? And what are the different properties underneath so that we know how to apply them at every layer? And then we can get to specific definitions like a cloud native network function. And a cloud native network function is a cloud native application. Cloud native applications have a lot of best practices and principles that you can look at running microservices and following the mutable infrastructure. One of the big ones would be the repeatable deployment process. So in DevOps philosophy, one of the big things would be your CICD pipeline that allows you to safely and predictably move all those changes. So that's a big thing on allowing developers to make changes, have new features, make security updates, and then safely move those into production. The platform also builds on the same principles. So when we look at service discovery, if the platform provides service discovery in a cloud native way, then your workloads can register and find other workload components CNS to build themselves. And the platform can help manage that. It pushes a lot of the work into the platform and allows the CNF developers to focus on their business needs that they can excel at. And you're going to see this all the way through all the layers of the platform and up through the workload. Another driver is community collaboration from the CNCS side. From the LF standpoint, there's engagement all the way through many different large communities. So all of the LNF groups like ONAP and FDIOC set for the testing, the new XG Vella platform service initiative, the OPNFV and CNTT work for the Kubernetes reference architecture, as well as all the CNCF and Kubernetes initiatives like individual projects and SIGs and everything else. There's also interaction across the different communities and outside of LNF like that folks from the O-RAN Open Air Interface software alliance and providers like Packet who are interested in working with the different communities and we engage with them and give feedback. And then we go directly to end users like the telecom service providers and developers themselves so that we can get the feedback to the CNCF initiatives and back into other communities that we're interacting with. So many efforts and initiatives and CNCF is from the telecom perspective is trying to be engaged in all the parts so that we can help from the requirement side where you look at cloud interprinciples best practices from the Kubernetes and CNCF community implementations like those that you see in the CNTT OPNFV effort XG Vella directly collaborating with projects on the testing side. We build on to existing testing to add additional parts like the Kubernetes India tests and conformance and then what CNTT is doing to be able to plug in there as well as the certifications that different groups would like to have. So this all ties together from those principles, community collaboration, into the different initiatives and the output having all of those as the drivers for many different end users, individual as well as groups. The telecom user group has a good number of members from both vendors as well as service providers. And we have been meeting regularly since 2019, including some face to face. This one would have been a face to face if we were all together and talking about those different ideas and looking at the different network requirements and gaps and how things are moving forward within the Kubernetes and CNCF community as well as the changing needs in the telecom world. We have created a white paper called the cloud native thinking for telecommunication, which is more of an introduction on the collaboration between cloud native and telecom. And then there's a extensive set of papers cloud native networking groups in the cloud native thinking for telecommunication as well as within other groups. And that goes back to the collaboration. So the Kubernetes based reference architecture documents for the CNT-TOP and Fee work, the principle papers are sourced and a lot of that's in there. And this comes from best practices and references within the Kubernetes and cloud native world. We've identified various gaps and scope within the requirements, both for the reference architecture as well as the implementation side and continue to give feedback and work directly with both CNCF and Kubernetes projects to ensure that they're hearing those things and encouraging collaboration. So the telecom user group meets on the first Mondays of the month. It has alternating times, 1500, 1100 UTC. The next Zoom meeting will be October 5th, 1500 UTC. And you can find more details on the telecom user group GitHub page. I see one question. I'm going to take a quick look and see what's there. It looks like it was dismissed and audio. Okay. It was an audio question, so I dismissed it since you fixed it. No problem. All right. And then if anyone in chat, if you have any questions, just please add them to the Q&A or raise your hand if you would like to speak directly. Hi, Jim from Elephant. I see you and some other folks. All right. So the CNF Testbed is a second initiative and it also has collaboration across many vendors and service providers that are engaged. You can see some of those here and different projects and initiatives. I'm pointing out the FDIC set where we've had a lot of direct collaboration on the testing efforts that they do. Network service mesh involved with some of the examples Intel and Samsung have been engaged trying to provide examples updates. And we've had many different participants helping in different ways in this effort. So it's an open source software across the board. And it allows out of box deployments to packet for both the hardware and network provisioning portions. The focus is on supporting different technology options and trying to have each stage of the process be as uncomplicated as reasonably possible so that you can come in and understand the pieces. We can plug in different parts if we want to try different technology. It also tries to use upstream community tooling. So we use CubeSpray, a SIG testing project, and we use NFE Bench, which is an open FE project for performance testing. And there's other tools in there and technology that are upstream within the different communities that we're interacting with. And we try to follow cloud native principles wherever possible. And that ties in with how things are done on the cloud native principles. We're looking at applying those from the provisioning standpoint when we're going from the hardware provisioning, the host or node, if you're saying on the Kubernetes side, the networking underlying underlying network, so layer two networking or whatever we're working with, as well as all the way through the different layers up through the examples and use cases that we're deploying. And then we try to highlight any problems that we may see for either whether it's missing items that we may want for telecom needs or out of band procedures. So maybe it's not Kubernetes native or we feel that we're having to step outside of a process that we think would be more helpful and try to note those. And we also try to highlight where specific technology has done a good job in following cloud native principles or being more Kubernetes native for that side and bring some focus to that. So it's fully repeatable where possible use in band components. The examples go all the way from very minimal so that you can understand one small piece all the way through larger use cases. And those build up and where wherever possible, we try to make it where each component can be put together and into larger, more complicated potential use cases, but you can break it down at the small side. And we have several examples that show different types of technology being used. That's the same type of use case or examples so that you can compare those and and have an idea of which you may want to use. So we welcome your participation in the scene of testbed. And you can get the software on the GitHub page. And if you have an API key from packet, then you can deploy the testbed. You should be able to deploy any of the examples that we have active right now. If you'd like to deploy your own network functions, you should be able to package them up and do that. If you want to share any results from that, we would love to see it. And if you'd like to contribute, we would love to see more examples, improvements to the actual tool chain, so provisioning process, the deployment of the cluster. And you're, you're welcome to do that, including ideas for issues, or we have a spec board, if it comes to something that we need to brainstorm. On the CNF confirm it side, we also have many different contributors from different projects and companies. It's a open source test suite. It's modeled after the Kubernetes conformance program. And by that, I'm saying the testing portion. So the, and the process for how you could test it so you can self test, you can download the software and run it to test your CNS, the cloud network functions or the applications specifically as well as the underlying platform. And it should provide visibility on how well the platform and those CNS are following cloud native principles. We expect it to help service providers in adhering and identifying solutions that adhere to the principles. And we wanted to provide the tools and feedback that can help developers improve their technology. It's also something that we hope could be used as a checkbox, the tool suite, as well as and the results for any type of certification programs. Along with that, I would announce it has been integrated with the CNTT open opnfv project, specifically the fun test fun test framework that's used for validating the Kubernetes based architecture. Right now it's integration for the workloads that's running. Platform testing will be added. And we expect to test different CNS as we collaborate with them. So here's a look at some of the categories within the conformance test suite. These are used for discussing the different needs that telecoms may have and tests themselves may go across different categories. Sometimes the focus is on that configuration lifecycle, the initial deployments of insolability. And then we can get into other things like statelessness, which means cloud native, how to handle data in a cloud native way, all the way through resilience and observability. If we take a look at some of the workload tests that are there and available right now, you'll see some and many of the categories for microservices all the way through resilience. On the resilience side, you can see a few like containers or the applications dying or having problems. What would we do? What would we handle? And what's expected by the application? Likewise, if we look at the platform test, you can see different ones from compatibility. Are they thinking about configuration from the CRD side security aspects? And then when we get to the resilience, you'll see problems, how the platform can handle problems like a node failure. So does the machine die? Does the platform handle stuff like network outages and other things in a way that allows a telecom service provider to continue with services as they would need? So the platform testing itself is expecting that any telecom platform would be conformant to Kubernetes conformance. So this could lead to the platforms that are being provided to a service provider could even be certified Kubernetes. And then what happens then is the CNF conformance builds on that. So looking at add-ons to Kubernetes, as well as underlying provisioning aspect for the nodes and host and how things come up. And we care about all the layers in between. So this is an extension to that core testing, AD testing, that's very extensive that Kubernetes does. And we go to many different places to gather requirements. When we're thinking in users, and how do we help them? Of course, as mentioned, we do talk with CNTT and work within the Kubernetes reference architecture. And there's back and forth on trying to understand and gather that. We're also working directly with service providers, developers, and then within the Kubernetes and CNSafe community, going to the different projects, talking about best practices for security and observability and all those sort of things, and those driving cloud native principles. Within the CNF conformance itself, we have some examples. So this would be in addition to stuff you may find in CNF Testbed. We have Core DNS, the Envoy Proxy, a VPP-based IP forwarder, which can be used for service training and other things. Linker D2. These are some that we have examples that you can come and see. We may add some future ones. The Clearwater IMS and BIOS are software that's being used by CNTT for testing, and some service providers also use those. So we're looking at testing those with the CNF conformance. And there's many others, including Evolve packet core examples and other items. If you would like to test using these, you can go and look at the large amount of documentation we have from very simple quick starts for CNF developers. If you want to test CNFs or test your platform, all the way through extensive source based insulation, or if you'd like to get engaged as a test developer, a lot of that's going to be good. There's usage instructions that cover from the individual test, all the way through running categories, or the whole suite with platform and workload, prerequisites, including how to use kind, if you'd like to do that, use the CNF test bed toolchain to deploy a cluster and test with that, and the different example configurations, if you'd like to get started and either use the CNFs that are there, or use those to test your own CNFs. Here's a quick look at running it. If you'd like to test all of the workload items or CNF specifically, you run CNF conformance workload, likewise for testing, all running all the platform tests you can run with the platform command. And you should see in the console, an output similar to this, where you're going to have all the different tests. And this is a snapshot, it would continue going of the different tests and whether you passed or failed. And then there's a final score for all the tests that ran, and how well it did for the platform or the CNF itself. The results are saved into an external file, which you can check. So the scoring system is based on the Sonaboy Kubernetes conformance test suite, which allows you to within CNF conformance, you can configure the scoring for the different individual tests and the AML configuration file, and other items. And then the test results are also saved into a AML file with all of the individual tests, the different groups as well as the final score. So that can be consumed and then re-displayed in some way, similar to what's happening on the LFN, CNTT, OVB2 results, and likely to be directly part of the badging program on their side. But it could also be used directly by service providers that are wanting to test a platform or an application side, and then by the CNF developers directly so they can get the feedback. What I showed before is minimal information, but we can also turn it on for highly verbose for developers to use. If you'd like to contribute, we have a contributing guide. We'd love to see pull requests for improvements across the board from documentation through new ideas and new tests. And we're going to continue to collaborate with the different communities providing output from all these different initiatives. We'd love to invite you to the meetings on the CNF conformance and test bed. We have a technical meeting that's combining both of those. It meets every Thursday at 14.15 UTC. And then again, the Telcom user group is the first Mondays with the next one on October 5th. You can reach out to us via the Telcom user group mailing list, the CNCF public Slack channels for all these initiatives. You can reach myself directly via email taylor at www.coop or Dan We're also on Twitter and GitHub if you'd like to reach us that way. So there's some related sessions. I wanted to point out the cloud native for Edge and service providers. This was a Monday session. So you can check out the recording. And it had six CNCF projects all showing how they can be used within the Telcom community. And then right now there is a panel session with some service providers and different project leaders, including some people from the CNF conformance and test bed. These slides again will be available on Sketch. Happy to continue the conversation in the cloud native networking Slack. We'd love to hear your feedback on the presentation as well as how we can help service providers and developers in using the CNF conformance and developers in using the CNCF and cloud native technologies. Let's see if there's any Q&A. All right, Jim. Elephant host an end user advisory group that is made of only the network operators. And there's members across both the groups. And the question is, are there opportunities to collaborate more? I think absolutely. I would love to collaborate more. And whether that's on gap analysis or requirements, very important. Many service providers are saying what is the underlying why and business reason. And I think getting listening directly to the those network operators to be great. So and it's going to help what Elephant is doing, which is on the more opinionated side and CNCF, which is giving the options and view. So that collaboration, I think is very important. I think we are at time. I'm not seeing any other questions in the Q&A. If anyone doesn't has anything else, please join the cloud native networking Slack channel on ONES or any of the CNCF Slack channels for these initiatives. Please reach out to us. And we're happy to help. Priyanka, Lucina, and myself specifically that are on this call. Thank you.