Page tree
Skip to end of metadata
Go to start of metadata

Related talks from the summit:

Collected ideas from the Beijing summit on how OPNFV can add value to ONAP. Please add rows to the table and indicate which you are willing to actively support, or comment as needed.

Area of CollaborationDescription of goals/approachSupportersComments
Infra convergence


  • processes
  • tools
  • best practices
  • labs
    • OPNFV Cloud / LaaS: ONAP developer access to OPNFV NFVI deployments in physical/virtual labs for CI/CD or testing with OPNFV variants / specific features. See a draft concept for one use case at ONAP-OPNFV lab sharing.png and on the Lab as a Service page.



Take benefit from OPNFV experience
Cross-community CI (X-CI)Enable ONAP to detect asap when a change breaks a test scenario, e.g. use of an NFVI API or internal feature



Avoid duplicate work

A potential use case for Lab as a Service

ONAP interop for OPNFV reference platforms/scenarios (variants)Round-robin test of current (e.g. weekly or daily builds) of ONAP+NFVI (OPNFV variants) to validate interop, using end-to-end VNF test scenarios.



OK, but it is an ambitious program. To be done after ONAP R1

A potential use case for Lab as a Service

Reference VNFs

Build catalog of open source VNFs implementing typical features of the VNF type as needed for specific test objectives, e.g.:

  • NFVI: support for the feature, performance/characterization, resiliency, regression, demos/training
  • MANO+NFVI: basic end-to-end deployment/functional tests, lifecycle management, regression
    • VNFs are adapted to meet current ONAP requirements, e.g. VNF package
    • Multi-site / Multi-VIM
  • use of the VNF as a test tool in testing ONAP features (e.g. VES, CLAMP) or other VNFs


  • supporting mobility service e.g. VoLTE: EPC, IMS
  • supporting broadband residential service: OLT, AAA, DHCP, ACS, PCRF, BNG, HGW, Router
  • carrier ethernet: PE, CE
  • appliances: Router (e.g. Vyatta), DHCP, DNS, FW, LB, CG-NAT, IDS, CDN



We should focus on a subset of VNF that covers all the requirements (eg vIMS Clearwater)

Clearwater is a good open example of the "complex" VNF. However, we'll also need something(s) that require high performance datapath functionality / EPA features etc. to exercise integration of those aspects.

Work of the SampleVNF and Models projects will support this goal.

ONAP+NFVI certificationCertified interoperability of ONAP and OPNFV variants



Limit the ONPV variants

Propose R2

Will add to Compliance and Verification Program (CVP) roadmap.

VNF certificationUse of OPNFV variants as NFVI test resources for VNF certification by ONAP, e.g. with NFVI features as needed by the VNF under test.OrangeProbably also a good use case for  Lab as a Service
VNF performance benchmarking

Use of OPNFV test tools (e.g. Yardstick) to assess VNF performance:

  • in generic OpenStack
  • under specific OPNFV variants
  • with presence of specific NFVI features

Yardstick focus on NFVI infra.VNF performance benchmark may require specific tool per VNF type


Advanced use case tests for ONAP featuresLeverage ONAP features/components, e.g. MSO, VES, CLAMP, Policy, APP-C, in OPNFV use case tests to provide feedback to ONAP on the effectiveness of the implementation for specific test use cases.



To clarify if possible de leverage ONAP feature alone

In scope for the proposed ONAP-Automated OPNFV (Auto) project.

Create integrated ONAP + VIM/NFVI Scenarios for OPNFV Opera project might be the right place to drive this. MANO will work with multiple of the existing scenarios. See scenario lifecycle concept for the proposal to integrate MANO via a separate layer in the scenario definition. Thus a MANO deployment can be tested to orchestrate various scenarios of OPNFV's VIM+NFVI layer. Orange

Various ONAP deployment scenarii will exist. Select the minimal one for first integrated ONAP+NFVI/VIM

Integration and Verification of key components from ONAP into OPNFV
Will build integration of ONAP, and verification of the following.
• How APP-C meets VNFM standards, interact with different vendors’ VNF
• How SDN-C makes use of OPNFV existing results, e.g. NetReady, forming two layer controller architecture, upper layer global controller is replaceable, lower layer can use different vendor’s domain controller to interact with SDN-C
• What data collection interface VNF and controllers provide to DCAE



Probably closely related to the goal "Advanced use case tests for ONAP features" above.

Will work closely with following projects:




Dependency on external project/committee:


Open Lab 

Kubernetes ONAP Deployment

  • No labels