Skip to end of metadata
Go to start of metadata

ONAP Cloud Native Journey

Plan and Next Steps

  • Align ONAP Community on its role and relationship to the Cloud Native ecosystem
    • TSC Task force initiated to define on ONAP’s CNF strategy including

  #1 What benefits ONAP itself gained by going cloud native

  #2 How we want ONAP to enable CNFs (hybrid, ONAP Lite)

  #3 What ONAP's value proposition is in the overall LFN family (ONAP/CNTT/OPNFV etc.

  • Include “ONAP-CNCF” to the CNCF Cloud Native Interactive Landscape.
    • Discussion being kick-off with LF (Arpit Joshipura)
  • Promote ONAP’s CNF strategy through LF Events (ONES, DDF etc.) and press release(s)
    • CFP submitted for ONES NA
  • First implementation of ONAP CNCF as part of the Guilin Release (Nov 2020?)

OVP / Cloud Native Journey

2/12 (presented by Arpit): VNF-CNF OVP - 2 key slides.pptx

2/27 (updated deck with Ciaran, Ranny, Seshu, Timo, Alla): VNF-CNF OVP - 2 key slides_V3.pptx

2/28: (updated deck - orange box is now generic - was previously missing SDC (smile)): VNF-CNF OVP - 2 key slides_V4

3/3: (updated with CNF Task Force): VNF-CNF OVP - 2 key slides_V5

Role of ONAP

Role of ONAP (which is a central automation platform) across multiple Clouds & Edges.

  1. Distributed Applications: Telco world is known to have requirement to support ‘network services’ whose components (VNFs today) spread across multiple computing regions (Openstack based regions).  Hence, the need for central orchestrator that orchestrates various VNFs of the network service in multiple openstack based computing regions.  With edge-computing,  even normal applications are becoming distributed, where a few microservices of the application are deployed across multiple edges & a few in network edges and public clouds. Essentially, applications are becoming more like network services.
  2. Convergence of applications and network functions due to Edges : Edge world can’t afford to have two computing environments – One for normal applications and another one for network functions. This is due to resource constraints. Since many edge-computing efforts in Industry adopted K8s, it is natural to think about supporting network functions and use same K8s cluster for both. It appears that a few MEC applications even require some network functions to be deployed along with them (Example include MEC applications with network security functions).
  3. Network function deployments and life cycle management are more complex than the applications due to need for supporting multiple interfaces, provider networks,  service function chaining. ONAP is solving many of these challenges.
  4. Support for Multiple Cloud technologies :  Supporting legacy Openstack deployments with greenfield  K8s deployments are needed.  ONAP solves these multi-cloud challenges.
  5. Support for Telco infrastructure such as OSS/BSS – ONAP is already in the path to support various MEF standards on its north side to support standardization between OSS/BSS and Orchestrators.
  6. Support for monitoring of distributed applications and closed loops :  Monitoring distributed applications that are deployed across multiple edges/clouds is complex.  There is need for showing the comprehensive status at the application level instead of at each resource level.  ONAP monitors the services/distributed-apps and not only provides simpler view of the status, but also can run through various analytics engines and even act on the actionable insights.

Note:  ONAP4K8s is a profile of ONAP for Enterprise/IOT (Including Private-5G/LTE)  market that have requirement of deploying CNFs/VNFs along with normal applications in multiple K8s based clusters.

In addition, we believe that ONAP can provide additional values as follows:

#1 NF Control Loop

#2 NF Common Inventory

#3 NF Data collection and analytics

#4 Support of PNFs

#5 Cover the design of services as well as the orchestration of services, design of control loops

#6 Play a role in terms of standardizations (TMForum, ETSI ZSM, MEC etc.) through our ONAP Technical Coordinators

To recap, we can provide significant automation values to handle applications on top of the K8S environment.

Areas of Focus

#1 ONAP 'Light" Weight - Review our current ONAP projects (see Lifecycle review led by Jason/Chaker)

#2 ONAP4K8S, Containerization 

#3 Identify ONAP Requirements +  to support CNFs for Guilin

#4 E2E Integration (OVP)

#5 VNFREQS => CNFSREQS - Certification CNF requirements - need to align with the ONAP Architcture + ONAP SECCOM regarding Cloud Native.


Features/Capabilities - How We complement each other to support CNF?

Features/CapabilitiesK8S EnvironmentCNTT/Arch Ref.2  ONAP (Today)



CNF Scalability

From an Orchestration perspective: Cluster Autoscaler, HPA and VPA

Handling within its own cluster

From an Automation, Control Loop (CL) perspective

OOF, SO, Multi-Cloud

CL (DCAE, Policy, CLAMP + Triggered Action)

Adding value: Handling multiple K8S, Clusters

See "SO enhancements to support CNF" presentation (3/17)

Not ONAP Scalability itself otherwise MUSIC, OOM (Container Orchestration)

CNF Resiliency

From an Orchestration perspective: K8S Services

From an Automation, Control Loop (CL) perspective

OOF, MSO, Multi-Cloud

CL (DCAE, Policy, CLAMP + Triggered Action)

See "SO enhancements to support CNF" presentation (3/17)

Not ONAP Resiliency itself otherwise MUSIC, OOM (Container Orchestration)
 CNF AvailabilityPublic Cloud is currently offering <99.999

Opportunity for ONAPNot ONAP availability itself otherwise 99.9999+ built inside ONAP 


Design Time


 SDC/CDSONAP Portal/UUI to be re-assessed

Secured service-to-service communication

Additional SW to be uploaded on top of K8S:

Linkerd, ISTIO, 


(VNFs only)

Integrate our ONAP Apps to Service Mesh (question) while keeping AAF as optional

Service Mesh between ONAP/CNFs

Do we provide any certificate or shall we rely on a Certification Manager?


Stackdriver Logging





Centralization of Logging - ONAP feature or external system to ONAP?


K8S Dash.png

OOM - Consul


Events, Alarms, Analytics

Prometheus -

Open-source systems monitoring and alerting toolkit

Jaeger -

As on-the-ground microservice practitioners are quickly realizing, the majority of operational problems that arise when moving to a distributed architecture are ultimately grounded in two areas: networking and observability. It is simply an orders of magnitude larger problem to network and debug a set of intertwined distributed services versus a single monolithic application.

based on grafana technologies (UI part) 


Specific VES

Integration with Promotheus and Grafana technologies (UI) as POC by AT&T

-Check the CNF Conformance to understand what are the requirements

-Shall we integrate one of the open sources to DCAE (like we did with PNDA) or shall we create DCAE CNCF version?


CNFs Storage

  •  Secured mechanism to store/inject CNF images (Extension to Artifactory - Separate virtual repos)


CNF Inventory

A&AI could also be used for Control Loop (future feature candidate?) 

Under investigation

 K8S Airbag, kubectl


CNF Security Requirements 

Ingress Controllers

How to address Networking back to provider network (question)

Expansion of Container Security for K8S (out of scope from SECCOM?)


OpenTelemetry provides a single set of APIs, libraries, agents, and collector services to capture distributed traces and metrics from your application. You can analyze them using Prometheus, Jaeger, and other observability tools. -

DCAE DCAE - Telemetry under assessment

CNF Compliance:

The CNF supports OpenTelemetry-compatible tracing
– Does the CNF generate Open Telemetry compliant data?
– Is there traffic to Jaeger? 


 Network Interfaces

Dual Stack Network:

  •  IPv4 K8s cluster with IPv4 pods and services 
  •  IPv6 (question)

SDNC/APPC/CCSDK (CDS)Re-use K8S & existing infra (question)

We need to understand what role does ONAP play for CNF networking. Is it exposed to CNI plugin choice? Multiple interface containers? etc.

  • DPDK (question)
  • SRIOV (question)

Adapt our CI/CD - Toolchain

E2E Testing - Working jointly under OVP PH2 (OPNFV, CNTT, VTP, ONAP/VVP/VNFSDK)

Where are we on the CNCF Trail Journey?

CNF Deployment 

#1 Workload Considerations - POD and Host Strategies

  • Separate POD 
  • Shared POD
  • Shared Host (with VNFs)

#2 HW Requirements

  • Persistency
  • Performance Optimization (Compute, Storage) - Generic or Special HW?
  • Multi-Tenancy @Storage, Networking, Resource maangement
  • Security - check with SECCOM

#3 Testing Considerations

  • Canary Testing - Rolling upgrades
  • Chaos Monkey Testing
  • Performance



We need to identify non functional reqs for ONAP Itself and for ONAP to orchestrate CNFS 
(Rework the below reqs into these two categories)

#1 Need to deploy ONAP/ONAP CNCF on component basis not as a whole
#2 Move to Service Mesh
#3 Optimization of DB - leverage some storage, DB capabilities offered by existing Cloud solution
#4 Scalability, Reliability based on K8S services (?). 
   Not replacing K8S but built on top of K8S.
#5 API between components

Later on, how our "ONAP CNCF" will look like to support CNFs

First Use Case(s) for Guilin (Initial proposals)

Links -- K8S across multiple clusters


  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 Catherine,

    Could you please add me ( to the


  3. 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:

          1. Yes, there are changes, but it makes ONAP platform more simple with CNCF projects and scale/manage easily to meet the more dynamic nature of Network Services Lifecycle. I believe current ONAP deployment process(Helm based workload deployments), absence of continuous change managements, static modeling & policies, generic & heavyweight control loops, absence of end to end obserbility, analytics, metering & serverless functions in hybrid cloud environment won't solve the future complex 5G/IOT usecases. I will publish the case study or we shall discuss this in future calls.

  4. Current Onap to CNCF mappings.

  5. Just rechecked on the XGVela bridge details it was 951 3778 5359

  6. 951 3778 5359 is for the Friday meetings 13:00UTC (Global). 

    For the APAC time (8:00 UTC) the bridge seems to be 926 4138 8798


  7. Do any of you representing your respective companies in XGVela TSC?

  8. Hi Catherine,

    Could you please add me to the

    Thank you,

    BR Marian

  9. Hi,

    ONAP CNF Taskforce and ONAP members are kindly invited to information sharing workshop between ETSI NFV IFA WG and ONAP SO project on CNF topic. Detail information is below.



    From: ISG NFV: Interfaces and Architecture <NFV_IFA@LIST.ETSI.ORG> On Behalf Of Nguyenphu, Thinh (Nokia - US/Dallas)
    Sent: Friday, November 13, 2020 10:05 AM
    Subject: [NFV_IFA] IFA WG and ONAP CNF information sharing workshop, Nov-17, Announcement


    On behalf of ETSI NFV-ONAP contact, I would like to share upcoming IFA WG information sharing workshop with ONAP on November 17.

    • Date: November 17, 2020
    • Time: 14:00-15:00 CET
    • Format: information sharing only, no decision.  Mainly, for SO CNF project to present and Q&A.  Since ETSI NFV already presented our technical solution to ONAP-ETSI NFV Alignment work, there will be no presentation from ETSI NFV side.
    • Scope: The presentation will be covering technical overview of ONAP SO approach for supporting CNF, the packaging handling at on-boarding and distribution, helm chart generation, distribution and deployment, and CNF LCM operations, service or network service deployment with CNF and combination CNF,VNF, and PNF. And a bonus, if time permit a Day 0/1/2 configuration.
    • Goals: Technical solution awareness and to identify any common parts that all parties can be re-use or referencing it.
    • Additional info: Recently, ONAP SO project made a presentation at LF Networking, an overview solution is available at this link:

    The invitation will be extended to SOL WG too.

    Meeting link information:

    NFV IFA WG ONAP info sharing on CNFO call


    To register:

    To join:

    Access Code: 331-925-637

    Phone numbers
    United States: +1 (312) 757-3119
    Australia: +61 2 8355 1038
    Austria: +43 1 2530 22500
    Belgium: +32 28 93 7002
    Canada: +1 (647) 497-9376
    China (Toll Free): 4007 160008
    Denmark: +45 32 72 03 69
    Finland: +358 923 17 0556
    France: +33 170 950 590

    Germany: +49 692 5736 7300
    India (Toll Free): 000 800 100 8227
    Ireland: +353 15 360 756
    Israel (Toll Free): 1 809 453 019
    Italy: +39 0 230 57 81 80
    Japan (Toll Free): 0 120 242 200
    Korea, Republic of (Toll Free): 00798 14 207 4828
    Netherlands: +31 207 941 375
    New Zealand: +64 9 913 2226
    Norway: +47 21 93 37 37
    Poland (Toll Free): 00 800 1124748
    Portugal (Toll Free): 800 784 711

    Spain: +34 932 75 1230
    Sweden: +46 853 527 818
    Switzerland: +41 225 4599 60
    United Kingdom: +44 330 221 0097

    Joining from a video-conferencing room or system?
    Cisco devices: 331925637@



  10. Catherine Lefevre Kenny Paul

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

    1. Kenny Paul - can you please check if this recording was stored in the cloud or on your laptop? thanks