Challenges of Cloud Native Telco Transformation today and how to overcome them - A CSP perspective v1.0 - December 4, 2023 Preamble This document is a product of the initial joint work of several Communication Service Providers (CSPs) who are active in the Cloud Native Computing Foundation (CNCF)’s Cloud Native Network Function Working Group (CNF WG), NGMN Alliance, and projects like Linux Foundation (LF) Europe’s Sylva and Linux Foundation Networking (LFN) Anuket project. It is a draft that has been published with the goal of inviting feedback from other CSPs and motivating discussion and improvements from the broader telecommunication industry. We hope that through public discourse we can make the document more complete, relevant, and ready for final release. If you would like to contribute to the discussion and document, please feel free to open an issue or create a pull request. Introduction The recently published Cloud Native Manifesto from Next Generation Mobile Networks (NGMN) Alliance does an excellent job outlining the vision and target picture for

Challenges of Cloud Native Telco Transformation today and how to overcome them - A CSP perspective Preamble The document presented here is a product of the initial joint work of several Communication Service Providers (CSPs) who are active in Cloud Native Computing Foundation (CNCF)’s Cloud Native Network Function Working Group (CNF WG), NGMN Alliance, and projects like LF Europe’s Sylva and LFN Anuket. It is a draft that has been published with the goal of inviting feedback from other CSPs and motivating discussion and improvements in the broader telecommunication industry. We are hoping that through public discourse we can make the document more complete, relevant, and ready for final release. If you would like to contribute to the discussion and document please feel free to open an issue or create a pull request. Introduction The recently published Cloud Native Manifesto from Next Generation Mobile Networks (NGMN) Alliance does an excellent job outlining the vision and target picture for cloud native telecommunication networks. The transformation towards a cloud native production model has already commenced in many Communication Service Providers (CSPs). Practical challenges and pain points on this journey, which hinder progress towards the target expressed in the NGMN Cloud Native Manifesto, have been identified and are being felt. These hindering aspects are especially prominent in the CSPs which are already taking practical transformation steps and are trying to closely follow the vision described. We, the group of CSPs gathered around Cloud Native Computing Foundation (CNCF)’s Cloud Native Network Function Working Group (CNF WG), live on the frontlines of this transformation and have gathered valuable experience in this regard. We firmly believe that to attain the envisioned outcome, the entire industry needs to work together to align around key strategic and operational principles. Besides building a sound understanding of what it would take for the transformation of CNFs to become cloud native, it's also important to emphasize the ecosystem that would support that evolution.

Last updated: [time=Thu, Sep 7, 2023 4:33 PM] Issue: Best practice proposal: A CNFs container(s) should have one process category (or type) #242 - https://github.com/cncf/cnf-wg/issues/242 PR: TBD CBPP-0005: A CNF’s containers should have one process category Release Signoff Checklist Summary MotivationGoals Non-Goals

Description: The categories in best_cnf_dev.md are no longer in sync with the test categories in the related CNF Test Suite. TODO: [x] review https://github.com/cncf/cnf-testsuite/blob/main/TEST-CATEGORIES.md [x] determine if those categories work for the CNF WG for now [x] Update best_cnf_dev.md to match https://github.com/cncf/cnf-testsuite/blob/main/TEST-CATEGORIES.md [x] see line #198 for suggested edits [x] Pull request #239 created

References: Hackmd CBPP: No root in containers / Container should execute process as non-root user Pull Request: Initial draft for a not running processes as root in containers as a best practice #182 Firewall CNF downloads compromised updates A firewall running on a K8s cluster applies configuration from an external, centralized system. Software updates are also pulled directly into the running container using a hot code reloading update procedure. Unfortunately, the latest update has been compromised on the central system and looks like a valid update for the firewall application. The firewall downloads the application and the compromised code is able to take over the containers process with its own malicious code.

Release Signoff Checklist Summary Motivation Goals Non-Goals Proposal User Stories (Optional)

Release Signoff Checklist Summary Motivation Goals Non-Goals Proposal User Stories (Optional)

DRAFT CBPP Notes to build from: google doc notes Required by: indirectly operator, directly CNF provider (since it improves CNF security) Provided by: CNF developer Detected: how? Straightforward justification

References: http://www.artofcommunityonline.org/ Removing: - run the operations Comment: The operation of the group, or the day to day decisions will be handled by individuals and team members. This is out of scope for governance. Process improvements would be part of helping with effective facilitation. Removing:

2020-02-03 Presentations with TUG. Ideas for where it could go TUG monthly Show-and-tell on-demand weekly every 2 weeks Written version: discussion forum, Blog post

Please see https://github.com/cncf/cnf-wg/discussions/130 for most recent updates The default process covers items which do not need additional discussion and community buy-in. Any item not in the listed in the "exception" list be be accepted after approval from a small number of any community member approvals (see more below). Items needing further discussion and approval are the exception. They will use a different decision making process and are listed in the Additional Approval Items list below. The following list only requires 1 reviewer for approval Spelling, grammar, and adding new interested parties

DRAFT: Send to cnf-wg@lists.cncf.io Subject: Call for CNF WG Co-chair and Tech Lead Nominations Body DRAFT: This email will kick-off the nomination period for co-chairs and tech leads. The nomination period will end on Monday, March 8th, 2021. The CNF WG will be co-chaired by 3 people. We are looking for one co-chair from the Kubernetes (K8s) Community, one from the Service Provider (SP) Community and one from the CNF Developer (Dev) Community to have equal representation.

issue https://github.com/cncf/cnf-wg/issues/56 DRAFT: Contributing to the CNF Working Group Welcome to the Cloud Native Network Function (CNF) Working Group! This is an open, public working group (WG) welcoming anyone who would like to help identify cloud native best practices applicable to networking applications. We're glad you're here! To learn about this working group, read the CNF WG charter. Except as otherwise noted, the content of this repo is licensed under the Creative Commons Attribution 4.0 License (local copy), and any code is licensed under the Apache 2.0 License (local copy). See more at https://github.com/cncf/cnf-wg/blob/master/LICENSE.md.

Where is work transpiring? Monday CNF WG meeting Slack discussions GitHub discussions GitHub pull requests Github issues Ad-hoc working sessions What areas can I help with?

What are some networking use cases which can be used for context and assessment? As part of any proposed best practices it is requested to provide 1 or more use cases showing where the best practice could be used. Goal: Relating best practices to real world use cases. Discussion of core features and functionality from use cases and their NFs. Examination of existing use cases to discussion of kubenative implementations which provide the core features and functionality.

Background context Goal for CNF best practices: Determine what practices will allow telco applications to most efficiently utilize K8s to lower the operational risk and burdens of SPs and telco vendors Production Telecom K8s environment: k8s cluster based on upstream k8s + CNI + CSI backed by adequate persistant storage + Container Registry + Helm repository and most likely + some standard observability and logging add-ons + Git and some CICD pipeline connected to it. The CNF is free bring its own (cloud native) add-ons and install them of this platform. ref: https://cloud-native.slack.com/archives/C01F1LVAQCC/p1606991123008800