Toc

Logistics

Proposal template

Draft proposals

How fragmented CNF conformance verification can be?

OPNFV, later CNTT and Anuket were formed with the idea in mind to decrease the integration costs of cloud applications and clouds. OPNFV intended to build integrated cloud stacks, at that time only based on OpenStack, which would become the de-facto cloud stacks of the telecom industry, so every VNF would know what to expect from it. OVP provided a verification program around it. The integrated OPNFV stack did not really become the de-facto cloud stack of telecom workloads and only a small number of NFVI or NFV vendors verified their solutions with OVP. Then CNTT was formed. The idea of CNTT was to specify the properties of the cloud stacks, this time both OpenStack and Kubernetes, and build a certification framework for clouds and their workloads. Then CNTT and OPNFV merged under the name of Anuket. OPNFV stacks became the Anuket reference implementations, the OPNFV test frameworks and tools used for the Anuket reference conformance program and OVP became Anuket Assured. During this time, CNCF started to build the CNF Testbed to test infrastructure capabilities needed for networking applications. CNCF created the CNF WG to define the characteristics of CNF and the CNF Testsuite implemented a set of CNF tests. In its Moselle release, the Kubernetes based reference architecture in Anuket adopted most of the application tests from the CNF Testsuite as application requirements. In KubeCon EU 2022 CNCF announced their CNF Certification program based on the tests defined in the CNF Testsuite.

All of this sounds confusing? It is because it is. In their talk Georg and Gergely will uncover the details of this story and the current state of CNF conformance verification. They will do this from a very selfish CNF vendor perspective to draw the attention to the issues of the current situation. At the last part of the presentation, the presenters plan to invite a set of key actors from the Anuket and CNCF CNF communities to discuss possible solutions to the problems addressed.

CNF vendors and network operators who are using the CNF-s and paying the integration bill.

Due to the flexibility of cloud platforms and the sensitivity of CNF-s the integration of CNF-s and their platforms is a continuous issue. The industry tries to address this with different conformance programs, but that only makes the CNF vendors life more difficult. This session attempts to explain the current situation and trigger a discussion to make this situation better.

We plan to invite some key contributors form the CNCF CNF Certification program, Anuket Assured and Anuket RC2 programs and initiate a discussion in the last part of the presentation.

No

Yes

How difficult can be to define a Kubernetes reference stack for CNF-s?

“Anuket specifications are a family of LFN initiatives to design, implement and test the conformance for Telco Cloud infrastructures. The aim of the specification work is to decrease the time and money needed to integrate Telco Cloud infrastructures and their workloads (Network Functions). Anuket specifications consist of a technology agnostic Reference Model (RM) and two technology-specific Reference Architectures and Reference Implementations, for OpenStack and Kubernetes, aligning with the Anuket Reference Model. In this talk Riccardo and Gergely will describe how RA2, the Kubernetes based Reference Architecture is enabling Telecommunications Providers and Vendors to deploy Containerised Network Functions (CNFs) on Kubernetes efficiently, and what’s new in Moselle, the current Anuket release, and what are the plans for the next one, Nile.”

Architects in telecom network operators and in CNF and cloud platform vendors.

This talk is a generic information sharing about Anuket RA2, a release update on its Moselle additions and information about the plans for Nile. 

Participate in the hallway track after the session.

A very similar about the previous release.

Yes

Working towards a shared model for Telecom Cloud Infrastructure, an Overview of Anuket

Anuket grew out of a marriage of a requirements task force (CNTT) and a infrastructure test project (OPNFV).   The idea is to create a  single project that not only defines the reference requirements for infrastructure, but also creates and supports the code needed to test and valid these infrastructures,  As you can imagine, it is an LFN project with a difficult mission. In this session, the co-chairs of the Anuket TSC will explain the structure of Anuket sub-projects, the activities in these different sub-projects and how all of this works towards the mission. The presentation will cover release highlights from the latest Moselle release and provide some insights to the targets for the ongoing Nile release.

Anuket is a project that was designed to be a joint effort by and for Telecom vendors and operators.  This session will allow those who are Anuket curious to learn more about it a and those always wanted to ask what Anuket was but never had the chance.

Actors in the telecom industry need better understanding of the mission of Anuket and how the project works to make this mission reality.  Anuket is a project that supports other projects in LFN and across the Open Standards community in general.

This is intended as a fully interactive session with lots of opportunities for the audience to participate and ask questions.

No


Day 0, 1 and 2 in the life of an Edge Computing Deployment

Theory and use cases are important, but what happens when the rubber hits the road, or in other words, when your edge infrastructure is ready to be deployed and run in production.  During this session we will look at the dependencies and requirements for successfully launching and managing edge architectures in the field. Grouped around the Telecom concept of what happens over the three "days" it takes to take an edge infrastructure from development to deployment and into production. Starting from “Day 0”, the preparation/development phase before the deployment so to speak, and moving into “Day 1”, the actual deployment into the field, followed by “Day 2” or Day N (depending on who you talk to) which includes the management of the systems in production, each step calls for different components that interrelate with each other. 

Any person who is serious about Edge and operating an edge deployment in production.

The Open Source community tends to focus  on Day 0 or requirements, but increasingly the telecom industry is looking for community to standardize operations and deployment activities.  While the nomenclature is borrowed from the  telecommunications industry, but the steps are applicable on a much wider scale and many more industries

This is intended as a fully interactive session with lots of opportunities for the audience to participate and ask questions.

No