 Okay. So, welcome everybody. My name is Galgai Chatteri and I'm working in the open source of Nokia. And I am Luis Melarde, head of cloud and infrastructure within Telefonica Global Team. And we will talk about Silva and Anuket in a format of a fireside chat, which practically means that we do not have slides. And also, I would like to ask you to ask questions or say anything what, you know, gets into your head because of the presentation. I'll tell you how you ask one slide, this one that you have here, but it's just so that we don't forget what we have to talk about. That is just for that. Okay, but first let's maybe talk a bit about what are these two projects because if it wouldn't be clear, these are two different open source projects. And maybe we will discuss why these are different open source projects. So let's first introduce Anuket. So Anuket is an open source project, which aims to define cloud infrastructures and cloud infrastructure workloads. And the main problem that Anuket tries to solve is the integration problem between the workload and the cloud. Because currently, this is one of the biggest issues when introducing cloud-native network functions in the telecom industry, that whenever we are trying to integrate our workloads with the platforms, that will be a very big and expensive exercise. And this is what Anuket intends to solve by creating specifications for the platform and specifications for the workload. And if everybody is competent with specifications, everybody is happy. This is not happened yet. But that's Anuket and Silva. I'm representing Silva here. Silva is a project that is very related with Anuket, but they are not the same thing. We will talk about differences in a minute. Silva basically tries to resolve a set of issues that operators have identified that are common for telco operators, but actually may affect other industries as well. And Silva has two main objectives. It's a project within Linux Foundation with two main objectives. One is developing reference implementation or a framework, a reference framework for cloud-native stacks. That's the first objective, to have a reference for cloud-native stack. And it's where we use Anuket as the basics to understand what we think cloud-native is. That's the first objective. And the second objective is, once we have this reference defined, build it and implement it, have a reference implementation to validate that network functions can be onboarded on top of this reference implementation. So it has two objectives. Building the reference framework and having a validation program to demonstrate that network functions or to allow network function providers and application providers, in general workload providers, demonstrate that their solutions are cloud-native because they can run on top of a cloud-native stack. This is what Silva is about. But they are not the same. Anuket and Silva, to me the main difference would be that Anuket is, as Gergely has just commented, is more requirements oriented, defines or standard oriented, defines the standard and defines requirements, and Silva is more implementation oriented. Actually he uses these requirements because tackle the same issues, at least part of the same issues, and implements a solution that abides by these requirements. Yes, in my head, their difference is in the how concrete their implementation is. Anuket is really like a specification and it enables several implementations. While Silva is one specific implementation of a content-as-a-service platform or a CNF platform, and that's how Silva is solving the integration issues because you have one platform and everybody have to run on that one platform. While Anuket tries to be a bit more liberal in this sense that Anuket, in Anuket, we are defining the API or quoting quote API between the workload and the platform, and Silva could be or maybe it is one reference implementation of the Anuket RA2 specifications. And this is exactly true because the main reference for us is the RA2. Anuket has different reference architectures and the one that we have identified that resolves the issues and help us, the telco operators advance in the cloud native world for the use cases that are coming is the RA2, the containerized one. And actually between that the performance profile one. So this is our main reference, but as Gerli says, Anuket has more reference architectures. Yes, we have also a reference architecture for OpenStack based cloud, but Silva is focusing on the cloud native. And as we both explained, both Anuket and Silva is focusing on verification or conformance tests of CNFs on specific platforms. Therefore, there is a big overlap between the function that is what we are trying to address. And there is also a connection between these two projects in this sense because Silva is using the FUNC test framework for running the tests, but it does not use the whole reference conformance test if I'm not mistaken, correct me if I'm wrong. Yes, so there's some points where we interact and we are working together, but when we enter into those I will describe them one by one later on. But first of all, we have to discuss if we really need a reference implementation. Why do we need a reference implementation? Any view on that? Well, I think we need reference, so because cloud native is a technology where there is a lot of room for diversity. Even if you are just running Kubernetes, you have to choose a runtime, you have to choose a CNI plugin, you have to choose a storage solution, all of that. And all of those are making differences in the runtime performance or even maybe the APIs of your stack. And as we are working in TACO where we are constrained on latency or on performance, we need to specify all of these details to make the integration of the stack and the CNF seamless. And that's why we need the reference implementation because that is practically like a very open-ended specification, a very strict specification of a stack. And this is exactly the situation that we have identified. The main issue we want to resolve is the fragmentation. So today the industry is very fragmented because even though let's say talking about cloud native and talking about containers, let's say we are everybody going and talking about containers as using Kubernetes as the orchestrator for containers, it is a standard de facto. Even though it is a standard de facto, everyone does it in their own way. So it's not just the vanilla Kubernetes and we all follow this. There's different implementations of the Kubernetes, but not the basic Kubernetes, the extensions that are required. Because for the telco operators, the workloads that we need to deploy have specific characteristics. They need acceleration. They need to guarantee the latency. It has been commented in the previous session about the Kamara APIs and how to support APIs that accommodate latency. Also the stack has to accelerate and reserve ports so that being providing guarantee in the latency. There's also additional security. There's maybe need for service mesh for security or for any other reasons. We may need specific synchronization for the open-run specific workloads. Automation because if we are talking about an environment with many containers distributed, so many little virtualization sites, we need to manage them all. So we need to automate deployments. So there's specific requirements on top of just having a vanilla Kubernetes. And everyone is doing it in their own way and it's very fragmented today. There's different certification programs, at least three different types of programs. Every vendor has its own application vendor, his program. Every stack vendor has its own program. Operators, we have our certification programs. So we think that we need to have a reference that tells us this is the basics. This is what should be incorporated, should be included. We need to have a service mesh. We need to have automation. We need to have deployment skills that make it easy to deploy these extensions. And to do that, we need this reference implementation. We could still be having different programs and probably we will still have different programs, but having one basic program that is common for all the vendors, all the stacks and all the operators is at least a benefit for the industry. And we are using Anuket to provide us the requirements for this reference implementation. Yes, I agree that we need one open conference program for CNFs. I think openness is also like very key here because it should be an industry consensus. What is in the conference program, what is needed to be supported by CNF and the platform, because if we are trying to agree on one particular stack, then we all have to agree in what are the properties of that stack. And even in the open source world, we have several CNF conformance programs. That's the interesting and funny part of it. So we have the Anuket conformance program, what we call Anuket Assured. There is a conformance program in CNCF and there is a verification program in CILVA. So I think we should somehow bring all of this together and create something together. Yeah, I agree. We should work in improving this interaction. We are already doing some activities together. Something important to say is that there's two things to keep in mind here. Regarding the different certification programs, the CILVA certification program is actually not certification and we specifically call it validation because it does not pretend to guarantee that anything that has been deployed can be just going to production. That's not the intention of the validation program. The intention is to validate that the network function is cloud-native enough so as to be deployed in this reference platform that has the basic extensions to Kubernetes. So if an application needs an accelerator and let's say epa characteristics, this reference implementation incorporates them and the validation of a network function that requires these capabilities demonstrates that can be deployed there and it has no attachments to the hardware or the configuration of this Kubernetes. It can just deploy the application and demonstrate that the application is working with the basic validation. We are not doing performance testing. We are not doing all the battery of tests that are intended for that specific function. This is to be done by each operator before they put it in production. The validation is a reduced one, let's say, limited, at least up till today, just to confirm that the network function is cloud-native enough to be deployed and actually when it is deployed to demonstrate that it is a network function, not just a set of images put together. That's one thing to keep in mind. And another thing that makes different certification or validation programs that we have is that today we are using Anuket as a reference for the performance profile part. So as we said, the acceleration part, let's say. But there's additional requirements that we take that are not coming from Anuket because Anuket today is not incorporating them. Maybe all these can come together and we will have all together, but we have requirements for additional entities. For instance, the security requirements are coming from the, right now, the European Security Entity Organization, ENISA. The synchronization requirements for OpenRAN are coming from the O-RAN Alliance. So the use of PTP, for instance, is not considered in Anuket today, but we need it because OpenRAN workloads, BDU and BCU likes, they are important applications as well, functions. So we have different requirements. So Anuket requirements is a subset for us. And we are using a subset of the requirements because they have others for other parts. So it's not exactly the same certification, but I agree we should keep working together in these things. Yeah, so I think we should align these and maybe the best way is to collect these requirements, the gap between the silver and Anuket and bring them into Anuket and then we will have one-to-one mapping between the requirements of Anuket and Silver. And I agree with that, we should work on that. Okay. So I don't know, we can go and talk about the specific things that we are collaborating, things that we are doing together, but before that, if anyone has a question before we keep going in the audience, yeah, go ahead. Okay, this is addressed to me. I repeat the question, just the end of the question. Yes. No, the analogy that you said I think is very appropriate. We are having the evaluation, conformance certification at different levels of validation, I think is very applicable. For Silver as validation, Anuket is a bit further and an operator has to certify everything before putting into production, of course, because we have a responsibility there. That's a statement that you and I agree with that. And your question was about if we have other requirements apart from Anuket, do we have a similar procedure with the rest of the organizations? Well, we are working on that. So there's a lot of initiatives, organizations and entities that are working today in different things in cloud native world. It's a mix of overlapping about things. So of course, we are having interlock and relationship with all the other organizations to identify where we can benefit and where we can provide feedback because we don't want to reinvent the wheel. I mean, we are not just rewriting the Anuket requirements, they are there. So we are just using them. But as part of the initiatives that we are doing together, we have provided them feedback to improve them. And as we are discussing here, we can even improve our collaboration. Well, we want to do the same with the other organizations, but the one where we have right now the relationship well established is with Anuket. Okay. Any other questions before we keep going? Okay, so the next topic is what are the initiatives where we are collaborating? Actually, I can name four things that Greg Lee briefly has commented before where we are working together. The first one is that any release of silver needs to be RC2 compliant. So this is the first thing. So what we are doing is we are running the RC2 compliance tests just to confirm where we are okay. And if there's something that needs to be changed, this is an input for us to improve the, well, it's not a product, to improve the open source solution. We are important. Silver is not creating a product. It's creating a reference framework and open source solution. Out of there, products is up to someone to do products. But the reference may be improved because it has to be RC compliant. If we are saying that we are going to be a cloud native stack, a reference for cloud native, we have to abide by the CNCF and cloud native RC compliance. So this is the first line of collaboration. Any point there? No, correct. Okay. And as an experience, we already run it in the beta version in a previous, well, the official release will be soon, but the beta version, we identified that there was some discrepancy in a specific case where we run it and the ingress controller, there was two ingress controller and there was some kind of dispute for the ingress controller control within the, what came by the fall with Kubernetes and what is provided by within a silver. So this was some kind of feedback because this test may be modified. The existing RC2 compliance testing may be modified because you are not forced to use the ingress controller from Kubernetes. If there's an implementation that is trying to be a reference that incorporates an ingress controller that have additional functionality, maybe it is possible to disable the vanilla one and enable the other one. So maybe this has to be considered. So these are things input that we are still discussing. And same as that, we had other inputs. And in the other way, we receive, we identified errors, let's say, or flaws that were resolved after running the RC2 compliance tests, which is, I think, positive for both groups. Yes, I think that's a very important aspect in this interworking that Silver is providing feedback to Anukhet. So it's not really like a single direction communication channel, but it's a bidirectional collaboration between the communities. In that sense, as we have just discussed, supporting PTP may be one requirement that we are providing feedback to Anukhet. That's the first point of collaboration, being RC2 compliant. The second line of collaboration is, as we said before, we don't want to reinvent the wheel. So in the Silver validation program, and in general, in Silver, there's some scripts that we have to run to confirm things. For instance, before we validate that the network function is actually deployed properly, we have to confirm that the platform, the Silver platform, is actually running and has enabled the capabilities that are required. For instance, let's say, multiscapability that is configured there, or Calico, or whatever is the CNI that may be required. So we have to confirm that the platform where you are going to validate something is actually properly configured. And we have scripts to confirm that. Well, we could have created any script framework to do that, but we have extest from Anukhet. So we are using extest as the framework to do these scripts that we are running. And also, if these scripts are deemed interesting for Anukhet, they can use them. If somehow in the other reference in the conformance testing or whatever, using these scripts is something that is valuable for them. It's free, it's Linux foundation. It's open source, so they can use it as well. Second point of interaction. Yes, I agree. Okay, a third point where we are working together is an additional scripting. Once we have confirmed that the platform is properly configured, let's say it requires SRIOV, because the application demands SRIOV to reserve the ports, the physical ports, and then accelerate and guarantee the latency. Once we confirm it is enabled, we can deploy the application, the network function, and it will be run and we can validate that it is working. But in the validation program, we have thought that we need also to demonstrate that the application is actually making use of that capability. Because one of the main things or the main issues that we want to resolve is a setting of resources. So if an application indicates that it needs some resources, some specific capability, we need to demonstrate that it is using it, because if not, we are some kind of wasting resources. So we have incorporated this testing not only that the application is deployed, but also that it is actually using what it has requested in the Helm charts. And we are using also the tests for that and we are doing it together because within Anuket, they are also having this interest. There's people from Anuket team working together with Silva. I can name you. I can name Petal or Cedric as well. And we are working together in preparing this script because they are interesting for both of the two conformance and validation programs. Yes, and I think that's a very important aspect of these collaborations that it always boils down to persons and people who are active in both of the communities. These persons are somehow the bridges between these communities. And we are very thankful to them for the support they are providing us. And another aspect where we are working together, actually we are starting or we should be starting because it's just very new, is the workload conformance in Anuket because we are, the validation program verifies that the application can be deployed. But even before verifying that, the application should demonstrate that it's cloud native. Let's say it's following the cloud native requirements. And again, Anuket has a program for that. It's called the workload conformance. And we want to incorporate in the validation program the running the workload conformance for a network function before it enters into the validation program. But this is something that is starting right now. The requirements are defined by the scripts to validate that are still not created and we can work together, I think, because it's the same kind of testing that we are going to do. Yes, we share the same problem and that's a good ground for collaboration. Yes, in this sense, it will be just running the conformance from Anuket before starting. It's not really a silver thing, but since we are interacting, we can do it together. So the team from Silver can help. The team from Anuket create these scripts. We should start by defining which is the minimum set of requirements that have to be covered as to say, well, this is minimally cloud native workload. But of course, this should evolve to a more complicated thing. And these are the four main areas where today we are working together. But there's still some things coming in the future, but there's a question before. Yes. Yes, so the question was that CNCF tag defines how cloud native workload in general and what Anuket is doing is that it defines how that workload can run in a telecom environment. Yes, absolutely. And in Anuket, we build the array to requirements in a way that they are referring back to the CNF test cases which are based on the CNCF working groups work. So there is a chain of requirements here. And on top of that, we defined those extra constraints which are needed because of the tech use cases like multi-network support and all of that strange things. And this is how the Anuket workload requirements are created. As one specific example, we can provide this. An application could be following Kubernetes and using alpha APIs because they exist in Kubernetes. But a requirement from the CNCF to be cloud native is don't use alpha APIs because they will probably can be obsoleted without any notification. So it's not recommended to use them. So if this is, if we, after we discussed, we consider this is one of the requirements to consider cloud native, this is something that Anuket will incorporate and we will demonstrate before taking two values. Okay, so talking about the future, there are things that we have to discuss. One is sustainability that I think is a topic you wanted to... Yes, and I would like to discuss a bit sustainability from two meanings. One is that the environmental sustainability and CELVA is kind of leading the pack here because in CELVA there is a working group for environmental sustainability and there is a thinking about how to calculate the footprint and the used energy of different CNS in a stack. And I think that is a very good initiative and I would like to get the requirements identified there into the Anuket side. Yes, and actually maybe I didn't mention in the beginning, the main use cases of CELVA are distributed environments with things like in core network the UPF which is going to be distributed, actually distributed, open run that the video per se is distributed and H that also by definition is distributed. And in this distributed environment one of the main things to take into consideration is reducing the energy consumption because we cannot have many stacks scattered around the world, all of them consuming a lot. So we should be conscious of that to reduce the environmental impact and cost as well. So this is something that is one of the requirements or the things that topics and actually as Gerli said in a specific work stream has been created in CELVA to tackle that issue. And this is one of the things where we could feedback Anuket or we can work together because requirements that we may define or situations that we may define will drive into requirements in Anuket and or not if in the end Anuket is not tackling that we may need it so we will use it. So this is about environmental sustainability that you commented. Yes, the other meaning of sustainability that I wanted to discuss a bit is the sustainability of open source projects and the health of open source projects. And unfortunately now we are in the situation that we have to talk about this when we are talking about Anuket. We are lacking of contributors in Anuket and as it is an upstream project for CELVA I think that's a common problem for us. So what do you think how can we tackle this sustainability issue of Anuket and we can maybe focus on the projects which are available for CELVA like FUNCTEST, RC2, RA2? Yes, this is something that we need also to work on. One of the main things of this project is to have adoption, to have enough audience for the project. We understand that the problems that we want to resolve affect all the operators. We started a group of European operators and with us come some vendors. So we are working on that and we are expanding the list of operators. In the end we're just a group of Europeans but this is a situation that affects the world worldwide. So this will have more participants soon. But we need to have more vendor workload providers understanding the need to become cloud native by design being capable of deploying in this reference implementation of a container base or cloud native base environment. And this will help also understand Anuket because it will feed all of us having this. So we are working in and we are inviting anyone who has workloads or network functions to demonstrate that they are cloud native by coming and being validated in in CELVA. They are for demonstrating that they are RC2 compliance from in the world part. Yes, so I think that's a very important aspect of this open source sustainability that we need an option. We need users of these projects because from users we will get the contributors because otherwise why would anybody contribute to these projects if they are not using them? So that's a very important aspect of this. There is another difference of these two projects and we didn't discuss that maybe we can discuss it as you just mentioned now with European operators. Like CELVA is considered as a European open source project whatever it means while Anuket is like an international worldwide project. Do you see really that CELVA is a European thing? No. So it started as that because a group of European operators we came together identified that we had common issues and we put this all together and it started as European and actually we started with the Linus Foundation Europe because it makes sense but it affects everyone. So all other operators from outside of Europe are invited here. The fact that it's a part of Linus Foundation Europe doesn't mean it cannot participate anyone. All the sessions are open as anyone in Linus Foundation so it is not really an European issue what we are trying to resolve or tackle but it is a group of European companies that started it and I think we covered all the topics. Any questions from the audience or any statements? Okay for CELVA you can go to the following web page CELVAproject.org, HTTPS, CELVAproject, CELVA is with white, CELVAproject.org. We also have a GitLab environment in CELVA. We also have a stack in CELVA so if you enter Slack and write CELVA you will find it but CELVAproject.org has everything. That's the best way to understand what is it about and participate and know where the next meetings happen. For Anuket it is anukets.io what you should look for. Thank you. Okay so any other question? Okay if there are no more questions thank you for attending and that's all we wanted to share with you.