All members are encouraged to contribute directly into this working draft. See also the OVP 2.0 Technical Ideas page
The LFN OPNFV Verification Program Phase 2 (OVP 2.0) is an open source, community-led compliance and verification program to promote, enable, and evolve a thriving ecosystem of cloud-native telecoms where Cloud Native Network Functions (CNFs) from different vendors can inter-operate and run on the same immutable infrastructure. It includes CNF compliance and verification testing based on requirements and best practices put forth by both the CNCF and CNTT. These requirements feed tool-sets and testing scripts developed within OPNFV, ONAP and CNCF communities.
An end to end set of compliance/conformance tests and testing toolchain for independently verified Cloud Native Functions for use in Telco environments.
Linux Foundation Networking
Common NFVI Telco Taskforce (CNTT)
Cloud Native Computing Foundation (CNCF)
5G Cloud Native Network Demo (Brandon Wick)
The end state vision is spelled out above and since it is likely a multi-year endeavor, what can we do this year to chart the direction and set in motion the program that achieves the vision?
First, the envisioned process is diagrammed below:
In the below diagram the “?” indicate processes that need definition and refinement for the differing execution environment of OVP Phase 2.
Not every thing can be tackled in the MVP, here are two elements that can be tackled for MVP.
• Compatibility - CNFs should work with any Certified Kubernetes product and any CNI-compatible network that meet their functionality requirements.
• Statelessness - The CNF's state should be stored in a custom resource definition or a separate database rather than requiring local storage. The CNF should also be resilient to node failure.
• Security - CNF containers should be isolated from one another and the host.
• Scalability - CNFs should support horizontal scaling (across multiple machines) and vertical scaling (between sizes of machines).
• Configuration and Lifecycle - The CNF's configuration and lifecycle should be managed in a declarative manner, using ConfigMaps, Operators, or other declarative interfaces.
• Observability - CNFs should externalize their internal states in a way that supports metrics, tracing, and logging.
• Installable and Upgradeable - CNFs should use standard, in-band deployment tools.
• Hardware Resources and Scheduling - The CNF container should access all hardware and schedule to specific worker nodes by using a device plugin.
(Should note that these are currently not characteristics that will be sufficient and/or accurate for Telecom use. As an example, in 5G the CHF (Charging Function) will be required to provide stateful transaction processing for services that are monetized on a metered basis – e.g. charging per minute for a live video chat session to a healthcare professional. It is unclear if these types of distinctions will be specified as work coming from CNTT.).
Development/Lab environment [Primary Owner OPNFV+CNTT] - What are the lab resources for hosting configurations for developing the NVFI and running on-going CI/CD verification tests? How can a “Lab as a Service” (LaaS) be instantiated for CNF/NFVI testing, development, and validation efforts? Does the CNCF TestBed meet the needs?
Test Tooling/Test Suite Development Based on Above Categories [Primary Owner: OPNFV]: Understand dependencies and what can be parallel processed. Also, what is the overall program test framework (e.g., Dovetail or something similar) that can plug in tests from projects and communities….
CVC portal [Primary Owner: CVC] - Define the UI for consumers of the CVC and on-ramp for producers of NFVIs and CNFs to publish their successful validation process results? How to the CNF compliance tests (CNCF) figure into the telco focused OVPp2 process?
Governance/Structure/Mktg Framework [Primary Owner: CVC] - Includes 3rd party labs, white papers, slide decks. With input from MAC