CNF 2022 meeting Minutes

Meeting Recordings

(CNF Taskforce Meeting Minutes - 2021 and older)

Table of contents:

1. Problem statement and scope

This Taskforce focuses on two main topics

  • ONAP as an orchestrator for network services consisting of cloud native network functions - CNFs (as well as VNFs and PNFs)
  • ONAP's architecture evolution as a cloud native application

1.1 CNF Orchestration

1.1.1 Evolving from VNFs to CNFs

1.1.2 ONAP as a CNFO

  • Hybrid services CNF/VNF/PNF, leveraging open-source
    and standards
    • Support Greenfield and Brownfield environment
    • E.g., CNF on bare-metal, CNF on VM, VNF on VM, PNF
  • Day 0/1/2 configuration
    • Not just infrastructure orchestration
    • Configuration and Update
  • Standard alignment (ETSI, 3GPP) and beyond (ASD)
    • Evolve existing investment, no need to start from scratch
    • Common Infrastructure for model/package onboarding, design and distribution
    • Support both ETSI-Aligned and Cloud Native Orchestration
    • 5G slicing use case – 3GPP compliant

1.2 ONAP as a Cloud Native application

1.2.1 Relationship with SDOs

1.3.1 ETSI-NFV - Alignment on packaging

ETSI NFV SOL001 v4.2.1 based proposal

1.3.2 O-RAN Alliance

  • Application Service Descriptor (ASD) - the modelling and packaging approach for CNFs, rAPP/xApps. 
  • O-RAN: ASD solution

1.2.2 Alignment and integration with other Open Source Projects

  • EMCO
  • CNCF - K8S
  • 5G Super blueprint
  • Anuket

2. Work accomplished and available functionality

2.1 Jakarta

2.2 Istanbul

  • Deployment maturation and Day2
    • Improvement of Helm Distribution (SDC/SO)
  • Helm Deployment Maturity
    • Helm package validation
    • Helm 3.5
    • Helm pre-/post-installation/deletionhooks
  • Simple CNF Healthcheck
  • Basic AAI CNF Changes

2.3 Honolulu

3. Future roadmap

  • Nephio integration
  • Support for 5G Super Blueprint & Magma CNF orchestrations requirements
  • New joint onboarding package to design the NS with CNFs
  • Merging the paths of the Native Helm & ETSI flows
  • Enhance the CNF resource orchestration functionalities further
  • Multi-cluster deployment with inter-cluster connectivity setup
  • CNF Upgrade
  • Coordinated CNF components deployment
  • Runtime model evolution based upon the standard
  • AAI persistence of the CNF resources
  • Control loop enhancements for CNFs
  • Cluster management and CNF observability (integration with XGVela)
  • Prometheus based monitoring in DCAE

4. Getting started 

4.1 Documentation

End user section

Developer section

  • documentation
  • Jira items in progress for the current release

4.2 Demos

5. FAQ

Q: What is the value-add of ONAP for CNF orchestration (CNFO)? What does it provide on top of K8S?


  • hybrid config and data operations can work on both K8s and PNFs 
  • Can manage helm charts
  • Handling multi-cluster deployment on top of K8S
  • ONAP works in the service level, not just the resource level 
  • Still need to address coordination across different clusters and SW upgrades

Q: What can end users do with ONAP Honolulu? What operations are supported (service design? Deployment? Day-0 configuration? Day 1/2 configuration? LCM?), and what will be supported in Istanbul?


  • For the "native helm" path - on-boarding, Helm enrichment with CDS, meaning modifying values in Helm templates.
  • Day 2 operation config-assign/config-deploy - add/modify resources after the initial deployment, which may be used for upgrade.
  • CNF status checking is supported in Honolulu, will be enhanced in Istanbul.
  • SO merged the "native helm" and "ETSI" paths for a more 'Plug&Play'

Q: What is the format of CNF packaging? Is it based on Helm? Does it follow ETSI-NFV specifications?


  • packaging - SOL04 may need a bit of work still. Descriptors are still being discussed in ETSI about containerized models. Lots of discussion but no consensus yet.  Orchestration meetings on Mondays 8am Eastern
  • Packaging is based on the CSAR format (for both the 'helm native' and 'ETSI' Format
  • CNF Descriptor Proposal page: 
  • Magma CNF onboarding is following similar path than what we have implemented for CNF vFW

Q: Where is the documentation for CNF on-boarding and deployment? 


Q: How should end users report issues 


Q: Are there "CNF requirements" available in ONAP, similar to the "VNF Requirements"?


Q: How could developers get involved? Where do you mostly need help? Are there open Jira tickets people can start working on?


  • Call for developers to implement in Jakarta new features:
    • CNF Control Loop 
    • Integration with XGVela
    • Merging Native Helm/ETSI flows
    • Entreprise use cases
    • etc
  • Istanbul CNF Orchestrator Requirements:  REQ-627 - ONAP CNF orchestration - Istanbul Enhancements DONE
  • Those are the short term goals. Have a great deal more in the backlog for future released. refer to 2021-06-09 - ONAP TSC Taskforce: Cloud Native (Roadmap)

Q: What it is not supported today and is part of the roadmap?


Q: What do we need to ask to CNF Vendors to be onboarded on the ONAP Platform?


Q: What has changed in CNF packaging since Frankfurt?


  • In Frankfurt, the Helm chart was a 'second class citizen' in SDC. In Honolulu there is native support for Helm charts. SO understands Helm type now.

Q: Is there a plan to support NETCONF configuration, or will the solution be limited to CDS CBAs? Is there alignment with C&PS?


  • No integration with C&PS, but it may happen at a later stage. But this is a good approach and may be discussed further in the CNF Taskforce.

Q: Does the CNF Orchestration support only Openstack VF-Module?


  • VF Module is the design aspect of the SDC, we represent each helm with a VFM. The current processing is per VFM for CNF as it is with the other resources

Recent Presentation Material

2022-01-13 - ONAP: Orchestration of xNF Based 5G Service

2022-01-12 - ONAP: ASD and Application Onboarding and LCM Orchestration

2022-01-12 - ONAP: Application Service Descriptor (ASD) for K8s NFs

2022-01-11 - ONAP: CNF Orchestration Tutorial 

2021-10-12 ONE-Summit_Cloud_Native_Service_Orchestration_ONAP v0.4.pptx

2021-06-08 - ONAP TSC Taskforce: Cloud Native (Demos)

2021-06-09 - ONAP TSC Taskforce: Cloud Native (Roadmap)

2021-06-10 - ONAP TSC Task Force: Cloud Native (Ask Us Anything)


  1. Apparently, the meeting invites to these meetings is not getting distributed to the community.  I was not aware that there was a meeting of this Task Force on 3/17 and it does not appear on the ONAP community calendar.  The ONAP calendar had a CNF Task Force meeting scheduled for Wed (3/18) which a few people joined but not enough for a quorum.   Can someone post the meeting schedule or send a meeting notice to the TSC list and modify the ONAP calendar?

    1. Good morning Fernando Oliveira

      Currently the meeting invites are sent to the Task Force distro list -

      I have just added you to the distro list.

      Sorry for any inconvenience

  2. Hi Team,

    would you please add me ( in this list ?

    I spent some time on this , below my draft proposal

    1. Brinda Santh Muthuramalingam - Those diagrams look nice but could you please provide some more context? Is it about transforming ONAP itself to CNF? Something else? 

      1. My proposal is to reuse CNCF projects and develop only Network Service Packages ( Plans, Configs, Models, Templates, Control Loops, API's & Custom LCM implementations) as Kubernetes Operators using ( frameworks and distribute through operator Hub( So finally ending up in developing only reusable Controller framework and NS/VNF Packages.

        1. Thanks for clarifying. That is quite a radical change, compared to the current ONAP (wink)

          Are you aware of the "baby step" efforts to reuse CNCF projects, like this one:

  3. Catherine Lefevre Kenny Paul

    Could you upload recordings on Nov.19 ?
    I cannot find it in CNF-Taskforce 2020 Recordings