...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
****** Moved to actual landing page - please make all edits there and not here! ******
CNF Taskforce Meeting Minutes
Table of contents:
| Table of Contents |
|---|
1. Problem statement and scope
What exactly is the task force focusing on?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
TODO: Break digram into two sections.
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
...
- 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
TODO: Add diagram from - ONAP CNF_Cloud Native Roadmap_V2.pptx
- 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
...
End user section
- ReadTheDocs (including "API documentation", usage, etc.)Wikihttps://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
- TODO: Add pointer to the latest release notesLatest 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
...