TSC Task Force - Cloud Native

• CNF Taskforce Meeting Minutes - 2021 and older
• CNF 2022 meeting Minutes

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 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.2 Honolulu

3. Future roadmap

• 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

• ReadTheDocs https://docs.onap.org/projects/onap-ccsdk-cds/en/latest/usecases/vfw-cnf-use-case.html?highlight=cnf#
• Wiki  - This space
• vFW use case - https://docs.onap.org/projects/onap-integration/en/istanbul/docs_vFW_CNF_CDS.html 
• Latest release notes - https://docs.onap.org/en/latest/release/index.html

Developer section

• documentation
• Jira items in progress for the current release

4.2 Demos

• Recording from June 2021 DDF
• ONAP: Orchestration of xNF Based 5G Service
• ONAP: CNF Orchestration Tutorial

5. FAQ

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

A:

• 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?

A:

• 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?

A: 

• 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:  https://wiki.onap.org/x/VwsqBg 
  
• 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? 

A:

• Documentation of the vFirewall CNF use case: https://docs.onap.org/projects/onap-integration/en/honolulu/docs_vFW_CNF_CDS.html
• Heat/Helm/CDS models: vFW_CNF_CDS Model
• Automation Scripts: vFW_CNF_CDS Automation

Q: How should end users report issues 

A:

• You can create a JIRA ticket - https://jira.onap.org/
• You can post any question on the #integration-team channel in the onapproject.slack.com Slack instance
• You can also join the CNF Task Force, every Thursday prior the ONAP TSC Call (1pm UTC) calendar link
• You can also write to the onap cnf mailing list - onap-cnf-taskforce@lists.onap.org

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

A:

• Helm 3 is supported in Honolulu (maintenance release). Helm hooks are not fully supported.
• CNF Descriptor Proposals: https://wiki.onap.org/x/VwsqBg 
• Architecture Review: [ONAPARC-709] (Istanbul-R9) - Func - CNF Orchestration – Istanbul Enhancements

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

A:

• 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?

A:

• Control loop, DCAE, A&AI, ASD implementation, Prometheus integration with VES, and more. Refer to 2021-06-09 - ONAP TSC Taskforce: Cloud Native (Roadmap) 

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

A:

• Vendors are welcome to test their CNFs, so we can have the solution validated with a larger set of Network Functions
• Security container logging requirement 2021-06-09 - ONAP: SECCOM activities for Istanbul release
  Also original presentation to ONAP TSC-  2021-02-22_LoggingRequirementEvents_v8 (1).pdf  

Q: What has changed in CNF packaging since Frankfurt?

A:

• 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?

A:

• 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?

A: 

• 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)