 Welcome to the session. This is the Cloud Native Network Function Working Group. We're going to talk about Kubernetes best practices for telco apps. I'm Taylor Carpenter, a co-chair of the CNF working group and owner in Vault Cooperative based out of Austin, Texas. I have been doing DevOps and development for over 20 years across multiple industries, including telecommunications, finance, healthcare, open source advocate and Linux user since the mid-90s and started helping in the CNCF community in 2017. We're going to have an introduction to this working group, a quick overview of a couple of other initiatives, CNF test suite and test bed. Then we'll talk about how you can contribute to the CNF working group and have an interactive Q&A and discussion. You can add your question and comments for that Q&A. You can chat with us on CNCF's public Slack after the session and you can download these slides from Sketch. CNCF has the mission of making Cloud Native Computing ubiquitous and it's driving this adoption in different ways with the goal of everyone gaining the benefits from Cloud Native technologies and methodologies. We would like to help telcos in adopting these technologies to ensure they gain the benefits like resource efficiency, resiliency, availability, reducing risk while increasing development velocity. Towards this goal, it's created four telecom initiatives since 2018 to aid companies who are running telecommunication workloads and understanding what Cloud Native means and how Cloud Native technology and methodologies can help to effectively gain the aforementioned benefits once adopted. It's created the telcom user group where you can help provide feedback from your experience and area like a service provider and developers, creators, all coming together. The CNF working group, what we're going to mainly focus on today, looking to create and find best practices for networking applications. The CNF test suite and CNF test bed, two tools to help with these best practices. Let's take a little bit more look at those first, those last two, the test suite and test bed. The CNF test suite is an open source test suite for validating how well CNFs follow Cloud Native principles and best practices. This is a tool that can be used by development, integration, and operations team to help see how they're doing in their application platforms. There's a test framework, there's different tests focused on best practices, there's minimal instructions for getting started as an end user or developer as well as more extensive instructions for both. Pre-rex and other things are outlined, it runs on your own Kubernetes cluster, you can use kind or bare metal type environments, and there's configuration and other examples to help you get started. If you would like to contribute, check out the contributing guide and you can download the software from the GitHub repository. The CNF test bed is an open source initiative to create a reproducible and easily repeatable test bed and set of tests and use cases. It's for early adopters as well as those in the networking industry who'd like to check out some of the example use cases or create new use cases. The goal is to keep things as simple and as straightforward as possible, try to use upstream tooling and domain language where possible, so CubeSpray for creating the Kubernetes environment, uses Helm charts and other things in a feed bench for benchmarking. So if you're familiar with those, then you should be able to hop in and start using those and contribute new use cases and examples. Out of the box it works on Equinex bare metal, and you can download it and use it right here on the CNCF test bed repo. All right, if you'd like to get involved in either of those, there's two channels on the public slack and there's also a contributor meeting on Thursdays at 1415 UTC which you can join to talk about either of those initiatives. So those build into what we're here today to talk more about the CNF working group. So the CNF working group has the goal of making it easier to produce and consume networking applications through the adoption and development of cloud native best practices for these networking applications specifically. It's a collaborative effort with service providers, CNF developers, and Kubernetes community working on definitions and use cases, best practices, and the process around finding these. We have the mission of making the to increase interoperability and civilizations for these cloud native and Kubernetes native workloads with aspirational goals of making things more portable, extensible, automatable, and flexible, whether that's deployments, development, management. We want to meet users where they are because we know there's a lot of brown filled deployments already there and technology that we would like to be able to try to see how you can do integrations while advancing the state of the art and methodologies, new processes, as well as the technology itself. So those goals, we have the goals of course to identify the best practices and we're specifically saying for CNF's running on Kubernetes is the focus right now, which CNF developers and operators alike may adopt. We want to determine which of these best practices are going to help the applications to CNFs to most effectively utilize existing services and capabilities in Kubernetes when you look at it as a framework at a building block and then provide feedback to improve projects and other specifications working with groups to improve their use cases and the applications themselves. We have over 27 organizations and individuals as of this recording that are have noted themselves as interested parties and the interested party document at which you can add yourself to. The leadership right now consists of three co-chairs, myself, Taylor representing the cloud native and Kubernetes community, Ian Wells from Cisco representing the CNF developers and CNF creators community, Jeffrey Saylans from Charter Communications representing service providers in that community. We also have an assortment of informal community leaders that are helping in different areas as well as all the rest of the community working together. So the relation to other groups. At a larger scale we're working with many different orgs and as well as directly with service providers and CNF developers, companies from Intel ARM, Equinex Metal for working on things, the SC plug test community. We've worked some with them on testing the different LFN groups and then within CNCF directly of course many different projects and SIGs. If we look at those telecom initiatives which is what's showing here we can see we start with the cloud native principles. Those are flowing into this working group where we think about how those can be applied as best practices, trying to get feedback from many different areas including some of those I've already mentioned but specifically here we're talking about the telecom user group and how it comes together and provides feedback from the different users and then taking those and building into recommended best practices of different types whether that's design and development type of things, different type of testing that we can do potentially conformance wise, operations, life cycle management practices that are going to help. These can all come to creators as well as end users that are actually using the CNFs or those networking applications and used in different places like of course the test suite itself could be used to write these and then we can provide these into other groups that may utilize them as well. All right let's look at how you can get involved and contribute. It's many different ways. Documentations are a great place to get started as specific area and there would be providing definitions, actors roles, expanding on acronyms within the glossary, helping to conduct gap analysis in different areas suggesting new networking applications or CNFs, helping to define or contribute to existing use cases and user stories and then of course getting to our end goal of contributing more cloud native best practices. Let's take a look more at those best practices. They can be in many different areas from installation and upgrade about acceptance of new CNFs, your life cycle, running CNFs, hardware resource management that's a important area or how to use Microsoft based design patterns for delivering the different parts and functionality of CNFs and applications all the way through all these different areas that you could contribute and the best practice may actually overlap in some of these areas. So if you'd like to propose a CNF we want to make sure that others would like to help so we want to socialize the idea in different places. You could put this in a new GitHub discussion or send your idea to the mailing list and come and talk at one of the upcoming meetings and then you want to talk about different aspects of the best practice. Whenever we have a full proposal we're going to actually go through a checklist so why do we need it? Well we want to tie it to a use case so we have context which we'll talk about more in a little bit. What makes it best? What are the circumstances around it? Is it even implementable? This could be limitations in the platform or technology and how you may work around those. Do you have a test plan? Can you test it? So start with a short description. This could be lease privileges for CNS something like that. What is the primary purpose or motivation behind it? What are the goals and non-goals so limiting the scope and the type of workload so that we have a context of when it may work and when it may not? Lease privileges may be great most of the time but doesn't fit some specific occupations. At least one documented use case so where would we use lease privileges? Who's involved? We need some context that's why we document this and then the test plan for checking metrics and what are the results. These are all needed for a proposal. Those use cases are going to provide most of the context and that's why we say it's required for any best practice proposal. They're talking they're showing us how a best practice will help get work done how the application is going to be utilized and what we expect as far as the end results. One example would be a transparent firewall. This is more of a hello world type of networking application or CNS representing the bump in the wire pattern for how to run an application that's just passing traffic as far as most of the time. This could be rewritten showing a story for different things. This could be a layer two firewall, a layer three firewall. You could be doing deep packet inspection. They all do very similar things as far as the transparency for this networking application. There's many variations local and external internal network services. It highlights a few things that we may find difficult such as the different types of traffic that you may need to handle. Normally you would think of a transparent firewall being on a second interface for taking in traffic about management or metrics for what it's found. It doesn't have to go this way but this type of idea shows us where we may need to work on solutions where you need multiple interfaces. One of them out there is multis and we'd be another one so CNIs that give us multiple interfaces. That's fine if those are what we need. The point is what are we looking at underneath as far as the problem so this raises this problem up to a higher level so that we can look at different solutions. Another use case, this would be a strong more complex real world use case would be a BGP on a customer network. This use case is also going to describe what someone wants to do. It's a pattern that's common in the networking industry and then what do we need to do? What are the different parts, the problems that we may see? There's different features that are going to be needed on this including how it may integrate with the underlay network. Again we're going to help by breaking things down like we did in the best practices. We want to see a short script of title going back to the documentation. We want to try to have our technical terms and acronyms fully defined so provide a glossary and if there's other use cases or best practices that have a term that matches then let's try to use those and have consistency. Add any other information about involved processes, the actors or who's the target audience like the operations team and maybe life cycle management and how they're managing that and then any type of entities involved. The cloud data platform is this Kubernetes, this is a specific provider, the data center network for maybe the BGP is going to connect into the wider area and we need to look at those. Then what are our intents? Similar to the best practices but on the use case we can go a little bit higher level and look at the whole situation and say what are our expectations at a high level before we then dive down in and talk about a more technical focused and expected behavior out of the different components and then talk about any challenges and limitations that you may see and how you could overcome them whether that's following existing standards or potentially new ideas if there's no standards around the problem as of yet. All right so you want to get involved please come and join our weekly meetings on Mondays at 1600 UTC. You can add your name and organization to the interested party documents come and describe use cases and talk with us about new best practices. Here's our roadmap for 2021 so far in this first quarter of 2021 we established governance we had an election for co-chairs and elected them started many use case discussions which we're continuing now the process for adding those use cases and best practices being finalized in Q2 and we're planning to have a few initial best practices and use case published and then we'll work with the test suite to try to implement those so that in Q3 hopefully we can see some results on running those test cases against the best practices we'll continue to add new ones and then we'll have an update at KubeCon North America in October on how things have been going and potentially look at formalizing under a CIG as CNCF CIG by that time. If you'd like to come and help please join our public Slack channels for these initiatives including the CNF working group join the mailing list and you can reach out to us on Twitter as well. I'm Taylor you can reach out to me I'm happy to chat Taylor at Vault.coop or Taylor on GitHub. Let's move on to the open discussion and get some feedback and answer your questions thank you.