Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 317 Next »

Meetings: 

Mailing List:  (Groups.io)

Calendar:  (Groups.io)

Slack Channel

Recordings

Thursdays, 13:00 to 14:00 UTC 

Meeting Minutes 

onap-cnf-taskforce@lists.onap.org

List URL: https://lists.onap.org/g/onap-cnf-taskforce 
Sticky Post: https://lists.onap.org/g/onap-cnf-taskforce/message/11
Hashtag: #cnf

https://lists.onap.org/g/onap-meetings/calendar 

#sub-cnf

CNF-Taskforce 2022 Recordings

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.x Jakarta

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

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

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:

Q: How should end users report issues 

A:

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

A:

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:

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

A:

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)



  • No labels