Overview & Goals & Scope

Primary owner: CVC

Contacts: Rabi Abdel Lincoln Lavoie Heather Kirksey

Scope & Goals:

• Definition of the minimum initial program (MIP) - that we will launch a Cloud Native OVP badge with
  • Note the other work streams MUST deliver on their components, i.e. minimum requirement set, tooling to implement the testing of requirements, etc.
• Cloud Native OVP Charter - eg. program operation, define the review criteria, program processes
• Portal and submissions.
• Approval/Review process.
• Relationship with other industry initiatives (CNCF, CNTT, OPNFV).
• Longer term road map(s) for the evolution of the programs.

Program Governance Working Draft

The following is taken from the existing OVP documentation (as of April 16, 2020), and we can use this work space / page to update the documentation for the Cloud Native program as needed.

Executive Summary

LF Networking is offering compliance verification through its OPNFV Verification Program™ (OVP). The OVP verifies products (“Offerings”) that claim compliance to OPNFV, ONAP, and/or other LFN projects.

The LFN OVP is a compliance verification program intended to increase the awareness and adoption of LF Networking technology by demonstrating the readiness and availability of commercial products based on LFN Projects.

The key objectives and benefits of the LFN OVP are to:

• Help build the market for
  • LFN-based SDN/NFV/automation infrastructure
  • applications or other devices designed to interface with that infrastructure
• Reduce adoption risks for end-users
• Decrease testing costs by verifying hardware and software platform interfaces and components
• Enhance interoperability

Verified Offerings submitted by respective vendors are expected to differentiate themselves with different features and capabilities but remain compliant by implementing explicitly defined interfaces, behaviors, and key features.

Purpose of This Document

This document defines the framework and governance of the LFN OVP, including the scope and objectives of the program, maintenance of program materials, compliance verification requirements and processes, program mark usage guidelines, requirements for systems under compliance verification, and escalation procedures.

This document does not define compliance verification procedures. Compliance verification procedures are defined by the community under the oversight of the Technical Steering Committee.

The current scope of compliance verification is based on multiple sources:

• The latest release of OPNFV Dovetail, which incorporates tests from LFN projects including OPNFV, ONAP, and others
• Informative ETSI NFV ISG specifications, specifically:
  • Pre-deployment Testing: Report on Validation of NFV Environments and Services http://www.etsi.org/deliver/etsi_gs/NFV-TST/001_099/001/01.01.01_60/gs_NFV-TST001v010101p.pdf
  • ONAP VNF Requirements

Please note that these sources are subject to further revisions and may be updated at some future time. The current compliance verification procedures are published by LF Networking.

Program Management & Maintenance

Role of C&V Committee

The Compliance & Verification (C&V) Committee, hereafter referred to as the Committee, serves as the OVP administrator on behalf of the Linux Foundation Networking (LFN) Board of Directors. The Committee is responsible for defining program governance, compliance verification strategy, and the overall scope of the compliance verification procedures.

Maintenance of Program Documents

Program documents, such as this document, produced by the Committee will be labeled using semantic versioning. That is, they will be labeled using MAJOR.MINOR.PATCH notation, where MAJOR, MINOR, and PATCH are non-negative integers.

1. MAJOR version. Note: to avoid market confusion, the scope of compliance verification and other project documents is tied to the major version, and once approved by the Board of Directors, will not change until the next major release.
2. MINOR version is used to denote significant functionality changes (e.g., addition/subtraction of compliance verification procedures and/or document sections). Changes to a minor version of an approved document require Board approval. It is a goal that minor changes should not affect the ability of a product to achieve compliance/qualification status.
3. PATCH version is used to indicate error corrections or editorial changes.

The scope of a particular version of the OVP requirements, test-cases, compliance verification checks, tools and results is tied to an OVP release.

Maintenance of OVP compliance verification procedures

The overall OVP compliance verification scope is determined by the Committee, and will be updated on a regular cadence (e.g., approximately twice per year). The LFN Series LLC TSC(s) defines and maintains the compliance verification procedures and associated tools. The scope is constrained to features, capabilities, components, and interfaces included in an OPNFV, ONAP, or other LFN project release that are generally available in the industry (e.g., through adoption by an upstream community). The scope also includes software designed to work with such projects and supporting requirements defined in the project(s), e.g., VNFs. Compliance verification is evaluated using functional tests that focus on defined interfaces and/or behaviors without regard to the underlying system under test. In practice, testing exercises interfaces and/or behaviors developed or exposed by OPNFV, ONAP, etc.

LFN Program Marks Usage Guidelines

Because of its position in the industry as an Open Source Project maintained by the Linux Foundation, LFN cannot endorse any products or appear to endorse any products.

Use of the Term “OPNFV Verified” and/or related program marks

Products that pass the OVP compliance verification suite may be labeled as “OPNFV Verified”. Products that are “OPNFV Verified” expose key features/behaviors of the OPNFV release.

• “OPNFV Verified” asserts that a specific system under test
  • Supply the key behaviors, functions, and related APIs of the OPNFV release
  • Promotes the key values of an OPNFV release, e.g. based upon the open source project components that comprise the OPNFV release
  • Performs basic NFV functions
  • Is interoperable with OPNFV
  • Suitable for further trials in an operator network
• “OPNFV Verified” does not assert:
  • Readiness for commercial deployment

The C&V Committee on behalf of the Board of Directors can award a product “OPNFV Verified” or related status. “OPNFV Verified”, therefore, may not be used in relation to a vendor’s product without first having met the requirements outlined in this document and the LF Networking Terms and Conditions.

Use of “OPNFV Verified” is determined by the Terms and Conditions and the OPNFV Branding Guide. The OPNFV verified standard will evolve over time as the OPNFV platform matures.

Organizations applying for compliance verification shall use the Program Marks solely for the Qualified Offering that was verified to have met the requirements designated by The Committee with respect to the appropriate category.

They shall not use the Program Marks for any product/technology other than the Product/Technology submitted for compliance verification even if it belongs to the appropriate category.

They shall only use the Program Marks solely for the following purposes in order to:

• promote LF Networking series of projects;
• indicate to procurers and users the information of interoperability for NFV infrastructure and applications; and
• indicate that the verified product meets all requirements set by the Committee for use of the Program Marks.

Organizations shall not use the Program Marks in any way that would associate it with any individual or company logo or brand, beyond the association to the specific platform to which it was awarded.

They shall use the Program Marks solely in accordance with the OPNFV Branding Guide which is prepared and amended by the Committee from time to time. Other than in association to the specific platform to which it was awarded, they shall not frame, post, upload, transmit or modify in any way, all or any part of the Program Marks, unless expressly authorized in writing by the Committee.

Organizations shall immediately notify the Committee if they suspect or discover that the Program Mark(s) is or will be used for any purposes other than the confirmed purposes or that the use conflicts with any of the representations hereof as a result of upgrading of its submitted product/technology. In the event that the above notification is provided, they shall provide the Committee with any and all information requested by the Committee in relation to the upgrading of the confirmed product/technology and all information in order to confirm the revised product/technology actually meets the requirements designated by the Committee with respect to the appropriate category. They shall not use the Program Marks for any product/technology which does not meet the requirements designated by the Committee with respect to the confirmed category.

Note: Such organizations will be held responsible for any illegal use of the Program Marks by others.

Organizations participating in the LFN OVP do not own any intellectual property rights in relation to the Program Marks, program documents, or compliance verification procedures.

Compliance Verification & Application Requirements

Compliance Verification Procedures Requirements

OVP compliance verification procedures leverage tests, compliance verification tools, test infrastructure and compliance verification program infrastructure defined and maintained by LF Networking projects which are included in an open source release of one of the related Series LLC. The Series LLC TSC defines which compliance verification procedures are included as part of the OVP. Once published, the compliance verification procedure suites will not change until the next OVP/CVP release (except to fix bugs or errors), as described above.

OPNFV compliance verification is applicable to one or more of the following categories:

1. Hardware Platform
2. Software Platform (e.g, Virtual Infrastructure – NFVI, VIM, etc.)
3. Applications (e.g., VNFs)
4. Orchestration (End to End management)

The scope of the criteria and requirements for each OVP release is set forth in an addendum to this document, available at http://verified.opnfv.org/.

Self-Compliance Verification

Organizations may conduct compliance verification using the LF Networking-designated tools at their facilities. The LF Networking-designated tools will ensure that the results were produced by an unaltered version of the tools, and that the results were unaltered. For example, this could be accomplished by digitally verifying the tools themselves, and signing the results file(s). Results MUST be submitted for review with application documentation and the logo usage agreement to LF Networking.

Qualified Verification Labs

Vendors may request service from third parties to conduct LF Networking compliance verification and collect results. Compliance verification occurs as documented in “Self Compliance Verification” above. The compliance verification results and documentation may be submitted by the third party on behalf of the vendor requesting the use of LF Networking Program Marks.
LF Networking may identify organizations providing third-party verification as Qualified Labs and list them on the LFN web site. LF Networking does not endorse or sponsor Qualified Labs’ services. Vendors are not required to use LF Networking Qualified Labs.

Compliance Application Requirements

The use of the OVP logo is not restricted to LF Networking member companies. The request for use of LF Networking Program Marks must state the organization, a contact person (email and telephone number); their postal address; the location where the verification results and documentation was prepared, the category or categories the product is requesting an OPNFV Program Marks(s) for; the attestation stating they will abide by OPNFV policies and procedures for use of an OPNFV Program Marks; any third-party lab conducting the verification; and the product identifier.

Review Process

The compliance verification results and documentation submitted will be reviewed by the Committee for completeness and validity. Based on the determination of the Committee, a recommendation will be made to the LFN Board of Directors regarding the approval of the granting of permission to use an OPNFV Program Marks.

The Committee may request additional information regarding the application for use of an OPNFV Program Marks.
OPNFV may charge a reasonable fee for reviewing results. Reviews will be conducted by LFN member companies participating in the review committee (a C&C subcommittee). No member company may review its own compliance verification results.

In the event of a dispute, the submitting organization has a right to appeal the decision with the LFN Board of Directors. An appeals process is documented in the Escalation Process below.

System Under Compliance Verification Requirements

The compliance verification environment (hardware and software) is defined by the OPNFV TSC.

Similarity Policy

Hardware platforms identified as similar to platforms that have passed OVP compliance verification procedures may apply to use the OVP Program Marks. The C&C Committee can decide to grant “OPNFV Verified” to products designated “under similarity”. The Committee will consider similarity in the following areas (for example):

• Compute
• Network
• Storage

Hardware platforms receiving rights to use the Program Marks “under similarity” will be so designated on the website.

Escalation Process

If, after submitting compliance verification results and documentation, a vendor believes its results were evaluated unfairly or if it identifies issues with the test plan, tools, or third party lab, it may send an appeal in writing to the Committee. The Committee will review the appeal and respond in writing within 30 days.

If the vendor wishes to appeal further, it may send a further appeal in writing to the LFN Board of Directors. The Board will evaluate the appeal at its next regular meeting.

Exceptions and Exemptions Process

Any program participant may apply for an exception or exemption from the inclusion, requirement, or test metrics of one or more test cases within a testing program covered within the LFN compliance programs. As an example, an exception or exemption might be granted for a commercial product, where the product design or requirements do not align with or all the test case or cases to execute or perform as expected. The following guidelines provide a process by which a participant might be granted such an exception or exemption. Exceptions or exemptions shall be granted to a specific product, for a specific test run. Generalized exceptions or exemptions to all products or a company at large shall not be granted. This ensures the technical integrity of the programs remains at their peak potential.

1. The participant shall first present a technical overview of the proposed exception or exemption to the project(s) responsible for the development and maintenance of the testing program (i.e. exceptions or exemptions within the OPNFV OVP program shall first be presented to the Dovetail project team).
2. The project team(s) shall determine is the proposed exception or exemption is an error, bug, or technical oversight within the testing, where a change to the requirements for all testing is required or if the proposal is specific to this instance of testing and product.
3. If project team(s) finds the proposal to be a general case, where changes to the technical testing program are required, the project team shall follow their normal process in the development of the corrective action, and shall release a patch to the current, in-force program, per maintenance guidelines within this document.
4. If the project team(s) finds the proposal be specific to this instance of testing, the project team(s) shall present the proposal to the LFN CVC committee. The CVC committee shall be responsible to ensure the proper due diligence has been taken and any requirement or supporting documentation is captured.
5. Once the CVC committee is satisfied, the proposed exception or exemption shall be presented to the appropriate TSC, who shall be responsible for the final approval / grant of the exception or exemption.
6. Any granted exception or exemption shall be documented, with appropriate technical details, in such a way to link the exception or exemption with the public compliance listing, thus allowing external users of the program to understand the nature and scope of the exception or exemption.

It shall also be allowed for a preferred lab to submit a request for an exception or exemption on behalf of a participant, without disclosing the participant’s identity to the open community. In such cases, the preferred lab shall work with the LFN staff to provide the full details of the participant, until such time the exception is granted.