 Hi, welcome. My name is Gere Gere Chatari, and I'm working for Nokia. Hello, my name is Gere Kunz. I'm a solution designer with Ericsson. And we will talk about the technical details of Anokant and a little bit of its history. And for that I need to share my screen. So first of all, let's talk about a bit about the initial statement of Anokant. And it is basically to create an open source reference cloud infrastructure model, architectures, conformance programs and tools to deliver this. And the aim of all of this is to empower the global communications community to analyze the technology. And how do we do this? It's basically by merging two already existing open source initiatives. One of them is being OP NFV. And the OP NFV was started in 2014. And interestingly, its target was to build an open source NFC reference platform, which is pretty similar to the current Anokant target. And during the time, OP NFV evolved and joined to LFM as a funding project. And in parallel to this, there was an initiative to standardize somehow cloud infrastructures and create specifications for these standards. And CNTP was born. And later it was put out to the open source with the support of LFM and GSMA. And after a while, when we started to work out the details of CNTP, we realized that there is, of course, some implementation and conformance testing work is needed. And the developers organized in a way that these projects were started under OP NFV. So that was already a link between these two. And later on, it was decided that these two projects should merge to have a better communication integration of these projects. And this is the output of our presentation because we are having this merge now. So let's talk a bit about the former CNTP specifications. So as I mentioned, the overall target was to create some kind of specification for cloud infrastructures. And the approach was to start a very obstruct reference model, which basically describes cloud infrastructure in a technological way and defines different cloud infrastructure hardware and software profiles and assigns values to different properties of these abstract cloud models. So in this way, we can have a technological standard how a cloud infrastructure should look like. And based on this reference model, there are reference architectures created, which are technology-specific specifications of cloud infrastructure. So currently, we have one OpenSec base reference architecture and one QBase base reference architecture. These are the two most prominent infrastructures. Anyways, and these reference architectures are still like specification documents, but they are describing how one should build and integrate the QBase or OpenSec installation. And we describe the details of these, like meaning what kind of components you need to have, what kind of parameters you need to have. All of these which are important for the BNF or CNF to run flawlessly in the infrastructures because the main aim is to lower the cost of integrating the infrastructures and the workloads together. And based on these reference architectures, of course we need to have reference implementations which are really installable QBase and OpenSec installations. And these are done in different OPNFA projects. And that is a detailed specification is also created about how to build these projects, and what kind of a cookbook or installation manual for this. Anybody can reproduce the building of these infrastructures. And as the last step, there is a conformance part of CNTT also, which is basically test any OpenSec or QBase infrastructure if they are according to the specifications of the reference model and the reference architectures. And also they are testing the workloads, if the workload is compliant with the worker-specific parts of the reference architectures and the reference model. So these are the four types of documents what CNTT brings to OPNFA. And as I discussed, like already some parts of these, like the implementation part of the reference implementations and the conformance part of reference conformance are already part of OPNFA. Here, I would like to give some pointers. So here I have links to different artifacts by the group. This means that I have a link to the read the docs version of the documentation for all the before mentioned documents and the link to the raw GitHub repository link so anybody can go and edit these and create a pull request. Also for the reference implementation and reference conformance projects, I included already the new Onuket wiki pages and it's important to recognize the button here that whenever we are talking like reference something one, that means the open stack based reference architecture reference implementation or reference conformance. And if it, if it reference something to them, it's the Kubernetes based reference architecture reference implementation or reference conformance. And with this I would like to hand over to Gael. Thanks, Gael. So, yeah, as Gael already introduced like the the extensive specification work that is being done formally in CNTT and now in Onuket. So the question is, is that sufficient or not. We are in the tech industry very much aware that specifications are fundamentally important thing because they provide us with a framework to build complex yet still into operable systems. And also just that right requirements in a textual form. So in Onuket we will go one step further and complement the specification with real implementations, so to say and those implementations come in various flavors. Of course you need to start with deployable platforms as Gael already mentioned, you need to have something to install and something to run workloads on and to use to validate those workloads. A comprehensive set of test tools to really go into the details and put systems to the test, figuring out what is their behavior, what are the functional capabilities of platforms. And finally, of course, you also need to have a development lab environment for making all of that happen. In the next couple of slides I'm going to give a brief overview of the implementation side implementation ecosystem of Onuket and how it ties into the specification work that Gael just described. Next slide please. Good. So the starting point here really is the specification work. We start with the reference model, the architecture and the implementation as well as the reference conformance work. And then you need, as I said, you need to start somewhere. And we start with the deployment process projects because we need to have something that we can put into a lab to work with and to put workloads on. That's an important component. Then we have a bunch of feature projects that address Tokyo specific requirements by building and developing components on top of the, let's say, standard platforms that correspond to specific components. We need lab as a service, as a development lab environment, already mentioned that. And then there's also another aspect and that is the comprehensive testing, test tooling part. And all of these different components will provide artifacts to work with. And now the real value that Onuket brings to the table is that it allows to feed all of those different artifacts into like an integration and testing pipeline to integrate platforms specific components come from feature projects doing CI CD and putting them to the test using our extensive test tooling. And the test tooling, of course, is particularly important because it if you click once you because it provides of course feedback to the implementation projects that's understood, of course, but they the testing also closes the loop to the specification part right so the testing results will provide feedback about for instance the feasibility of certain requirements and thereby in the specification folks to refine the architecture requirements and Mary mentioned the same concept also applies for the test tooling part. That allows a feedback loop. So let's go one level deeper and look at the projects a little bit right so from the deployment perspective, we currently have two projects on delivering deployable platforms that is a ship, developing the R I one the reference implementation for the open stack track and cube rev develops the reference implementation for the Kubernetes track. Then we have the feature projects. Right, so a selection of those barometer is tool that builds or that allows to monitor a system at runtime and to collect metrics from system fast data stack provides high performance data plane. Project developing security and policy management security policy management component and CR of the develops hard and software basically specification validation tooling. I already mentioned lab as a service as a general development environment for like the entire community. And then on the testing side, we have func test very comprehensive generic test tool for running functional tests against cloud platforms. General cross testing is a part of it which is an even more generic framework for integrating all sorts of tests and sweets and frameworks. This perv and if he mentioned sample the NF test, the data plane performance of a cloud platform from various different angles and store perv focuses on the storage performance. And then, as I said, if you could click once gay gay, taking all of this together is basically the the unique thing that a new cat can deliver so we have the specification part we have this extensive implementation ecosystem and we create by emerging CTT and open if we create these tight feedback loops between both worlds, so that we can. Yeah, impact and our industry to the best degree. Okay, and then going one slide further. I already mentioned so we have the two pillars of the new cat that we already mentioned we have the specification part and we have the implementation side of things, but there's actually a third flavor and that is the compliance area. Now by itself the specifications and the implementation artifacts are already tremendously valuable for the industry, because they provide requirements and they provide test tooling or deployable platforms. And they can be used and find them that's that's all good, but the compliance part of all of that will add a formalized process around how to formally test workloads and platforms using the test tools and the artifacts that a new cat will deliver according to the specifications is a formalized process of how to run the tests how to review the test results and how to avoid compliance badges to commercial offerings and the goal of that obviously is to simplify the the overall process in the industry of building complex systems jointly with vendors and operators. And with slides vendors and operators would benefit from having a simplified process, building on top of the compliance. Okay, then, some words about the variations of one cat to other groups on a cat that has an open source project which integrate structures and create compliance programs, of course, have relationships to several other groups. For example, I look at, of course, uses opens the care ship and and Kubernetes downstream, let's say so on cat is integrating these, these, these together. Also, I look at plans to reuse the CNF conformance program from from CNCF as part of the of the of the conformance, but just to mention other type of group. There were projects inside the open FV, which, which are, which we're using at CNF standards to implement different API for for open second, of course, the list is is is very long. So we are using lots of, lots of different projects, but on the other side, can look at is also contributing to two different other projects, like the before mentioned the open stack. And also, we are working together with the CNCF CNF working group. For example, finish project to to open stack and and other projects also, which are related to telecom requirements in open stack. Also, we are working together with the CNCF CNF working group. In reference architecture to to define the different requirements for for CNF. And this will cause so effects the CNCF telecom, it was at home and as Similarly to the, to the new open source projects, the list is is is very long so as we are a big project, we are contributing to several other projects. And the main point here is that that is not not living in the vacuum but we are integrating to an ecosystem of of different open source and and other industry groups. So with this we reached the most important part of the the presentation, which is the the call for action. So please help us to make all of this this possible because this is a community effort, which means that we need volunteers from the community to to do the different tasks and to start this. Please check the look at wiki, the github project for for CNPT or the get it project of the former opnf we get it. Project code or join us to discuss in the look at select workspace workspace, or if you are really interested in in active and interactive communication with us. Join to our next elephant developer and testing forum which will be in the beginning of February. And this would like to thank for your time, and happy contributing to an upset.