TSC Task Force - Cloud Native

Owned by cl664y@att.com
Last updated: Aug 24, 2022 by Ranny Haiby
6 min read







Meetings: 

Mailing List:  (Groups.io)

Calendar:  (Groups.io)

Slack Channel

Recordings

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

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)