 Hello everybody and welcome to this session which is about the CNF working group. I'll just make some quick introductions. There are three of us co-chairs and we're all going to have a little chat with you today. My name is Ian Wells. I work for Cisco. I build CNFs. My co-chair there from Charter is Geoff Saylence. He runs CNFs. And Taylor Carpenter is our man in the community who makes sure that they all work on Kubernetes. So what we're going to talk about today is why the CNF exists, how it was started, what we're trying to do and how we're trying to make the world a better place for those of us who actually need to run CNFs for a living. So a quick intro to the group itself. We were formed at KubeCon about a year ago at this point. It was a collaboration between a bunch of us. Service providers, telcos need to actually run CNFs as vendors need to make CNFs. And as I say, we need to make it so that it's possible to create these things. They're not that easy to create and consume these things because, you know, it's easy to get into the weeds when you're trying to run complex software. And we're going to do that by publicizing the best practices that we've learned for both the development and the operation. The CNF, for those of you aren't quite aware on that is a cloud native network function. So we're not just looking for containerized but actually cloud native that influence or facilitates network functionality. So it might be moving individual network packets around, or it might be something that supervises or controls or transfers information about where those packets go. We include actual things like routers, but we also include things like root reflectors, BGP, and, you know, this crosses the board into other areas of networking like mobile networks. We obviously want to design at least we want to enable design of those CNFs as microservices as well structured applications using the best practices that we already know from the Kubernetes world. We have a mutual infrastructure with declarative APIs, and of course repeatable deployment. But we also need to deal with the things where CNFs are a little bit different and special. So our problems basically amount to the difficulty in making these things work. CNFs are hard to develop and operate. We want to simplify that we want to make it so that developing a CNF is not something that you spend so long trying to figure out how even that works. We want to make sure that you follow the best practices for building CNFs. We don't want you to go and fall into the pitfalls that other people have found previously. And we want to make sure that CNFs actually are consistent. So you use them consistently, your experiences with one CNF transfer to the next one and the next one. So our goals here are to identify the best practices for running CNFs and Kubernetes so that Kubernetes developers and operators can both adopt them to work out which of those practices allow specifically networking applications to use Kubernetes properly. And we also obviously don't want to reinvent the wheel. So we talk to other groups in the CNCF who do related topics that we're interested in, and we take their advice. So we have to remember at the moment CNFs are relatively in the early phases. It's not that they don't exist, but there aren't all that many out of them out there, and they're not completely consistent in how you use them and how they behave. So what we want to do here is basically meet people doing this in the state that they're currently in and then walk them forward. So we learn from what they're operating and we take what their experiences are and make them best practices and write them and share them with people. And then as we find out new things we share those as well and a best practice is not a perfect target. A best practice improves over time as you learn more and more. We work with these four design ideals portability flexibility extensibility and automate ability. And why do we talk about these well to begin with portability. We're looking for applications that run on Kubernetes, but Kubernetes is not one thing I could what I find in public clouds like AWS and Azure works in one way. What I find in private clouds whether it's supplied by one of any number of vendors will work in slightly different way. And there are some things that Kubernetes itself doesn't standardize for you. So as one particular example that we see if I want a specific kernel module to be loaded if I'm going to do STP as a protocol as an example, then I have no guarantee whether the platform will have that in loaded or not just saying it's Kubernetes doesn't decide that on me. One platform or another might work slightly differently. So we need to figure out how to make portability work so that I can take my CNF and run it in whatever platform the service provider has chosen for whatever purpose for, you know, their personal preferred reasons. Flexibility extensibility is about making sure that we're getting the benefits of being part of the Kubernetes community. We don't want to lock ourselves down to doing things in one precise way forever. As an example, Kubernetes obviously does orchestrate containers to an extent it will run a certain set of containers for you and try and keep the count to a certain number. But on the other hand, we then moved on to using helm to describe that because it made things a little easier. And then because we worked out that it wasn't always suitable we went and we started writing operators to run specific microservices, because sometimes you need orchestration that's more complex but more functional than helm provides. And that's a perfectly natural evolution. The world moves on and we learn better ways of doing things. We want to be a part of that learning we want to be able to adopt what comes along. So it's important that we don't end up in a rigid place where we can't change. And finally, automated ability. Humans are flawed. I think that's a fairly safe thing to say. If you ask them to do something twice or indeed even once follow a set of instructions, they can't always do it the same. Or right. If we look at 5G networks where we trying to build radio access networks, we're actually looking at them orchestrating thousands of applications and thousands of clouds around the network. If we're asking them to hand deploy 1000 clouds, you're going to get 1000 different clouds out of that it's not going to work. Similarly, if we asked them to hand deploy 1000 applications then you're going to get 1000 different deployments that don't behave the same. The more we can automate the fewer problems we have and the more consistently everything works it's so much easier to operate so making sure that our CMS automatable is absolutely key. And now I'm going to hand off to Jeff who's going to talk about some of the challenges we run into as we're trying to do this work. Thank you Ian. So as you mentioned earlier I'm Jeff Saylens I work with charter communications. I come from the operator paradigm and you know one of the main reasons I contribute and in active in the CNF working group is so that I can share my views but then also try to understand Ian's and Taylor's and like the groups that they represent. So we're going to walk through a little bit deeper on the challenges through the different paradigms. Talk about how those eventually use cases and then how those use cases drive the best practices. So first we're going to take a look at developers and one of the first questions you know that we ask is do you write CNF and if the answer is yes what challenges are you facing. Some common answers are you know what are the defined patterns like what are the best ways to add a second interface into a pod. How do I deliver network services that a consumer actually wants. Will the provider of the infrastructure give me what I need when my CNF be able to run there you know if not is it okay for me to package my own Kubernetes distribution. How do I innovate you know like it's really hard to gain adoption right now because there's so many different views people want to get out there improve that they're pushing the bleeding edge and bringing value but it's sometimes it's tough to show that your way actually is best. And then finally how do you support your product it's tough in a multi CNF world that's heterogeneous when the provider is the one controlling the platform and you start to lose you know complete control of the different variables that you might have had in a PNF world or physical network function. Next we look at the operators you know operators do you run a network you know do you support CNF in production and like run critical infrastructure and cloud native environments. If yes, you know what is life beyond NFE look like what lessons can we learn. You know do you get to run your own upstream Kubernetes this is always a point of contention why because of that support ability conversation. Can I run a standardized platform throughout my private and public cloud instantiations and expect CNF developers to provide me software that I can run on it. You know what's wrong with my CNI like why do I have to use a proprietary CNI. Ultimately, can I put this into my software apparatus you know that I have my other operations and applications pushing through. Can I put this into my pipeline. Finally we have the Kubernetes community itself and specifically the CNCF community at large. You know, monitoring logging Kubernetes itself service meshes. What haven't we provided to the telco community that they're always coming to us and saying you know Kubernetes doesn't quite do what I needed to do. So how do we understand the request of these CNF developers in these CNF operators. You know why doesn't a sidecar fix what we have going on right now. Why do you need a layer two or a layer three interface in this. So after we've looked at the challenges then we start to talk about use cases and why do we care about use cases because ultimately we can't really prescribe best practices unless we know what we're actually trying to accomplish. So we look at you know the concept of user stories from our three different paradigms and then we start to look at building out use cases that will ultimately drive us to you know find ways to overcome the challenges that are being listed and drive towards use cases that are sorry best practices that we can then publish and start to help define some of those established patterns. So that you know starting off it like a more high layer esoteric view of things is a combined user story for like developers and operators and that's how do I get CNF into someone's infrastructure and then how do they maintain and run that. So first, you got to get the CNF into the telcos infrastructure. Typically this is a private cloud maybe even a hybrid cloud scenario where they're using both public services and you know first party services from a cloud infrastructure standpoint. You know is there a means for them to watch repos and pull them in continuously into their pipelines? Can we treat CNFs like we would other software despite some of the quirks that they present from a software and management standpoint? Are there feedback loops to present data from our continuous testing back to the CNF developers? Are we being good citizens and giving them the information that we're finding as we're running this? Are there defined requirements? Things like air gap installations? Do I have to go to the internet? What if I don't allow internet access from my private data centers? Can I pull in all of this and build from scratch within my own environments? Then you go to the next phase of this which is life cycle management. As service providers start to attempt to you know move into a cloud native paradigm themselves that typically includes a get off the approach to managing your infrastructure. Everything declared automation from top to bottom version deployments for all of this stuff underneath. So when I take a CNF which is both software but also infrastructure, how do I ensure to the CNF developers that I'm going to have the right run times, the right kernels? The necessary NICs and physical infrastructure that they want to put an SRV interface into something, etc. Conversely, if I'm a CNF developer, how do I ensure that I can handle the constant you know upswing of Kubernetes releases? If I have a customer that is agile and is constantly maintaining and updating their infrastructure and versioning, will I be able to keep pace with them? What does that agreement look like? And then finally, how does the CNCF community stitch it all together and help us bridge these worlds? So moving on to a more actual you know concrete technical use case. We want to start simple like as we are looking to build out use cases we need to have or sorry best practices we need to have use cases that are solvable. And we take a look at something like a bump in the wire firewall. What this is is just a simple like filter and ACL, any type of transparent like network device where packets come in. And that is the key thing we specifically care about a packet by packet consumption model and then how are packets egressing. And so some of the considerations that we have to think about with such a simple use cases, we're probably going to need more than one interface, an interface for ingress and an interface for egress, or else we don't actually have a pipe. There's probably a third interface in there for the control plane mechanisms that Ian was referencing. How do I program this transparent firewall to have the right ACLs in place? How do I ensure that it's performing the way I want? How am I collecting metrics on it? So then ultimately we looked at the design ideals, and we start pulling apart this use case and figuring out what are the actual best practices. Once again, meeting the user where they at, what technology exists now, and where do we need to try to push the envelope? Because it's not all trivial, right? Everything in Kubernetes, like if you look at the base requirements, it's, you know, Layer 3 reachability between pods, between nodes, etc. What if I need a Layer 2 interface, which is at that Ethernet layer. It doesn't work with packets, and it doesn't work with IP addresses. Can we achieve this in Kubernetes? Finally, I want to touch on the, you know, the use case to end all use cases, and that is the 5G packet core in RAM. You can have a discussion about CNS without 5G coming up. It's very new, it's very exciting, and it's going to, you know, change the industry. It's also incredibly complex. It is, you know, an application comprised of many applications. And so ultimately, we need to figure out how we support people trying to deploy packet core in Kubernetes now, but we need to make sure that we don't repeat this past mistakes of the NFE evolution, where we virtualize things, but we didn't really design the software to run in a virtualized world. We treated them like appliances, and we didn't really get that cloudish type experience that we were ultimately hoping for. So moving into the final portion of my section, best practices, right? There's a ton of categories that we're looking at. And these categories, you know, they come from the use cases, and they drive things for us. So you can see that there's a bunch of them, and, you know, we'll look at a couple specifically right now, such as lifecycle and onboarding, because that was one of the use cases we covered, right? How do you make things better for yourself as a CNF developer or a CNF operator? You have declarative APIs, right? Can I write declarations to consume your CNF? Can CNFs expect that the infrastructure itself is declared if they make requests without potentially breaking, you know, privilege boundaries and things like that? Was the CNF or the infrastructure designed for automation, you know, am I going to get the portability, the compatibility that I need? How do I manage state when I have stateful applications? Next, we look at security. Security itself can be broken off into multiple different subcategories. Security is not a unique concern to CNFs. The reason why we do look at it specifically, though, is because CNFs tend to be very greedy when it comes to things like privileges, talking to the kernel, requesting elevated access to the underlying infrastructure that a lot of, you know, more traditional applications would not. So diving a little bit deeper in the security bucket, we could look at something, say, specifically like lease privilege. What are some of the best practices that, you know, come from the lease privilege bucket? And that's things like not running your containers as root if you don't have to, you know, ensuring that like privilege equals false is the default setting that is deployed over and over and over again. If I have something that's privileged, when it's done doing what it needs to do and execution is complete, does it relinquish those privileges? And then finally, am I implementing our back through all the different layers of this stack, the platform, the pod, the container, etc. So finally, where are we going with best practices? Why are we pulling apart all these use cases and digging into the weeds to figure out what we're trying to accomplish? And that's because there's a lot of new areas to explore and areas that are unique to both CNFs and Kubernetes just because of what the two pieces of technology are trying to accomplish. So what is the best way to do multiple interfaces in the pod? This is something that's being explored. You know, how do I leverage node labels and the metadata available to me to get the Kubernetes scheduler to put the right workload on the right piece of hardware without breaking cloud native paradigms and declarative approaches? Can I move packets quickly? You know, is it a microservice if my data plane acceleration is four million lines of code? You know, like, are we going to have to rewrite software at some point while still taking advantage of what's available there today? And then finally, at what point have I turned so many knobs that I'm actually starting to diminish the value of cloud native approaches in itself? If I've made something that so bespoke and, you know, broken all the immutable infrastructure like mantras that are preached, then have I started to like erase the value that I got from going into Kubernetes and taking on cloud native approaches in the first place? And so lastly, the thing that you need to know is how do you get involved? And with that, I'm going to hand it over to Taylor. All right. Thank you, Jeffrey. Let's see. So as of this recording, there's 27 organizations and individuals who are actively participating in express interest and the work that we're doing in the CNF working group. If you're a service provider, or you're creating network functions, we invite you to join these other organizations and sharing your role world use cases and experiences. You can also add yourself to the interested parties markdown file on the gap repo with a pull request. And we see the potential for collaboration across many groups, starting with those in the CNCF community. If you're part of a CNCF or Kubernetes technical advisory group, special interest group or working group, we welcome you to come and help us define the best practices based on your areas of expertise. Also, if your group has created any white papers reference material that you think is applicable to the goals of our group, please let us know. An example would be the tag securities security white paper, which we're already referencing for things like the least privileged principles that Jeffrey mentioned. We also want to help your group. So if you have anything that you think we could help with, please let us know. One instance that we've been working on is the cloud native glossary where we're trying to contribute relevant telecom and networking specific terminology. If you are part of the CNCF project community, or working on a project specifically, please come and talk with us about where your experiences with those projects could help. There should be in use cases, how the technology is used, the best practices that you've learned. We've seen a lot of stuff from projects like Falco and OPA and tough for the security area. There's also projects and focused in all the different areas that I think we care about configuration deployment life cycle. There's our go and flux and harbor. I invite you to come and share your experiences and help us with those best practices. And we also want to mention that we're interested in helping and working with groups outside of the CNCF, like Linux Foundation networking under the LF umbrella and their aniquette project we've been collaborating with. We're also working with folks from the Etsy plug test where we're working in an experimental track in October and we've been helping in past events with them. Orange France has a network of the future seminar, we'll be talking with folks from there. I'd love to hear from people from the open networking foundation and maybe those working on the omic project telecom infrastructure project or tip. So if you're out there in another organization project, and you think there's some ideas you'd like to share maybe you see some stuff that we're doing that you'd like for us to come talk please reach out to us. We want to contribute within this working group, whether that's adding to existing creating new content. We're helping to improve across the board and docs whether that spelling small clarification adding new references we'd love to invite you to come in on that. So we're working with different places where you can get started. And we've made it possible to come in in different areas like the GitHub repo itself we have a discussion board, we can come and add your ideas. If you'd like to join our weekly meetings you can add a agenda topic to talk about. We're also on Slack and we have a mailing list where you can come and talk about these things. We have something more permanent so that we can take the content and maybe added into use cases. We have a Google Drive that's open with content we've been putting in there we can collaborate in documents there if you're prefer Markdown, we also have a hack MD space. There's that get up discussions as I mentioned, you can add issues, put comments and pull request. We have a lot of places where you can collaborate. We're interested in actually writing tests around these best practices and helping to validate the software. We do have an initiative initiative called the CNF test suite with a set of test focus on doing just that. It's, you can check it out on the CNF test suite repo. There is a contributor meeting for that on Thursdays. There's also a public Slack channel on CNCS Slack and a mailing list. We recognize there are challenges in the journey of adopting implementing cloud native best practices, and we'd like to work together to identify what we can do today. And what needs improvement. Please join us improving these things. We hope this presentation has piqued your interest in collaborating with the cloud native network function working group, and thanks in advance for your participation. If you'd like a copy of these presentation slides you can download them off the event page on schedule. Please stay tuned for the interactive Q&A with Ian, Jeffrey and myself. See you there.