 Hello and welcome in our virtual booth. Today we are going to show you how easily you can build your own NSM-compatible CNF. I am Miroslav Miklut from Pantheon Tech and I am here with my colleague Milan Lencho who will guide you over the second half of this demonstration. CNF stands for Cloud Native Network Function. You can think of it as any other network function like Router, Firewall or VPN but following the Cloud Native Architectural and Operational Principles. Including Lifecycle Management, Agility, Resiliency and Observability. The CNF is usually packaged in a container image, can be deployed in a Kubernetes environment and supports declarative configuration. Multiple CNFs can be chained or meshed to provide more advanced customer network service. What? A network function in a container? I am in. Where can I get one? There you go. This is the one of the fastest data planes in the world combined with a declarative intent-based control plane called Ligato. And it's for free, waiting for you to hit the cube control run command with the Ligato BPP agent image. That's it. That's all you have to do to run your own CNF. Now you can connect to the CLI by executing the BPP control command inside that container. And when you type show interface, uh oh, that doesn't seem right. There is only a local interface in this CNF. That might work for a shy CNF which only wants to talk to itself. We would probably want one or more interfaces to be connected to that CNF. There are multiple options how to provide layer 2 connection between containers. You can use projects like Conti VPP, Multus or Network Service Mesh. Now we will show you how to use Network Service Mesh or NSM. NSM is an official CNCF project. It's biggest advantage is that you can run it in any Kubernetes deployment alongside to your preferred CNI. It extends the Kubernetes network model and provides layer 2 and layer 3 service mesh for your CNFs. During our CNF journey we have figured out that NSM provides an imperative SDK for integration with your CNFs. So we have decided to implement an NSM plugin for Ligato which gives you a declarative way of configuring the NSM virtual virus between CNFs. But not only that, when you combine it with your simplest CNF you will get a declarative way to configure not only the virus between CNFs but also the configuration of the CNF. Now that's what we call inton-based networking. Long story short, the plugin sits inside the container where you run your simplest CNF and it is providing the translation in between the declarative configuration and the imperative NSM SDK. Now please welcome Milan Lenca, who will guide you through the demonstration. This example we have a simple chain topology to be deployed inside the Kubernetes cluster. Here on the left side we see the YAML file for the definition of the routing for NSM. So it's just two rules. One, the routing is defined such that the VPP web server is an endpoint for CNF not 44 and CNF not 44 is an endpoint for the client put. By the way, inside the repository with the demo there is a readme file which you can then follow to try it out for yourself. And actually first couple of steps tell you that you need to have Kubernetes deployed together with NSM but this has already been done before recording. But in the readme file you can find links to the documentation of Kubernetes and NSM to learn how to deploy each. Right, so now let's start deploying the ML files, there are a couple of them. So first we actually need to deploy CRD controller for our CNFs. So next once we have CRD controller we can start deploying our CNFs and POTS. So first we will deploy web server, actually inside of its YAML files you can see the declarative configuration which contains just that NSM endpoint and it is inside an instance of our CRD. Now once we deploy web server what happens you can see on the right side. So the pod is created, it includes the VPP which will be our HTTP server but also NSM agent that receives that configuration and based on that configuration it will advertise the endpoint to the NSM control plane. Next we deploy CNF NAT44 in its YAML definition you can see that there is a definition of the endpoint to which the client will connect, there is the NSM client that will connect to the web server and then there is now highlighted the NAT configuration and that NAT configuration references those interfaces by their logical names. So the same NAT configuration could be used regardless of what wiring technology we use but in this case it's NSM. So once this is deployed the NSM agent of NAT44 will request connection from the NSM control plane. The NSM control plane will look at the routing and will determine that it should connect to the web server both once MEMIF interface because they are VPP based and it will create those MEMIF interfaces that will connect to each other directly without even having to go through the NSM data plane so it's a very efficient connection in this case and we can use the VPP CLI to confirm that those interfaces have been already created on both ends. And finally we will deploy client pod with the call. So in its configuration there is just this NSM client definition that will connect to the CNF NAT44 and also there is a route for HTTP requests to be directed through that interface, basically through this data plane connection rather than going through the primary interface which is created by CNI. And so once we deploy the client the NSM agent of the client will request connection from the NSM control plane. The NSM control plane will determine that it should connect to NAT44 but since client is a Linux application, the Dacro is a Linux application, it wants tab interface and tab interface cannot be connected to MEMIF directly so both client and NAT44 will connect to NSM data plane and there they will be linked together using L2X Connect connection. And with that we have the chain ready. We can test it using the HTTP request sent from the client. As you can see we have received the HTTP response from the server. Thank you very much for your attention. We'll be glad to hear your feedback. You can find us on LinkedIn, Twitter or just leave us a note over CDNF IO webpage.