Versions Compared

Old Version 3

changes.mady.by.user Olivier Smith

Saved on

compared with

New Version Current

changes.mady.by.user Taylor Carpenter

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

All members are encouraged to contribute directly into this working draft.  See also the OVP 2.0 Technical Ideas page

Table of Contents
absoluteUrltrue

Charter

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.

(Suggest that we include Rabi's overview diagram illustrating relationships between the different contributing organizations in LF)

The evolving architecture from VNFs to CNFs

(Needs describing and we should clarify that CNFs are orchestrated by Kubernetes and that MANO is utilized with VNFs.)

Image Removed

Source:  LF Networking

Compliance & Verification Program

OVP2.0 E2E Compliance and Verification Program adds additional collaboration with the CNCF in the testing and verification of Cloud Native Network Functions.

Image Removed

Source: LF Networking

Verification and Certification Process

OPV 2.0 will provide an open source test suite which enables both open and closed source CNFs to demonstrate conformance and implementation of cloud-native practices. Compliance to the verification process will result in a LFN Cloud Native CNF badge(s). The LFN CNF badges should provide value for both operators and commercial vendors.

(We should outline the types of testing as well as clarify where these tests belong.  Workload testing, Platform testing, etc.)

Image Removed

Cloud Native Network Function (CNF) Best Practices Criteria

Propose that the below should be aligned, agreed, and later decomposed into testable items.  We should sort with mandatory first and optional (but still verifiable) criteria at the end.  Organize into levels of Gold, Silver, Bronze if this makes sense.  What will the value of a Bronze be for operators and vendors?

...

CNF Best Practice Criteria

...

1

...

CNFs are decomposed into loosely coupled collection of services (e.g. use micro-services design).

...

2

...

Micro-services should, where possible, be independent of the host operating system.

...

3

...

Micro-services should utilize well defined declarative APIs

...

4

...

Micro-services should be designed with a clean separation between stateful and stateless services (have separation of state storage and business logic)

...

5

...

Clear separation should exist between micro-services (e.g. use of containers)

...

6

...

Micro-services should provide a mechanism to verify container content. Containers should not require root level permissions. It should be possible to secure API access to a micro-service using common methods.

...

7

...

Micro-services should be resilient (self-healing and distributed)

  • A strategy for self-healing accompanies the micro-service
  • Is compatible with declarative configuration and container orchestration

...

8

...

Micro-services should be elastic (vertical and horizontal scaling in response to load)

  • A strategy for auto-scaling accompanies the micro-service
  • Is compatible with a declarative configuration and container orchestration

...

9

...

Micro-services should be dynamic - where possible, have a small footprint and fast startup time enabling efficient use of resources and rapid scaling.

...

10

...

Micro-services may utilize a service mesh for service-to-service communication over a network

...

11

...

Micro-service/Container life-cycle is managed by an orchestrator (e.g. K8s)

...

12

...

Micro-services utilize immutable infrastructure:

...

A

...

  • Infra is easily produced and repeatable (automated)

...

B

...

  • Infra is consistent (infrastructure elements are identical each time they are implemented)

...

C

...

  • Infra is disposable (create, destroy, replace, resize, etc.)

...

D

...

  • Configuration of infra is protected from changes after deployment

...

E

...

  • Deployment process of infra is versioned, automated, and all dependencies packaged together with the application during build phase and then used in deployment

Vision

An end to end set of compliance/conformance tests and testing toolchain for independently verified Cloud Native Functions for use in Telco environments.

Image Added

Who are participating?

Linux Foundation Networking

  • Open NFVI project (OPNFV)
  • Open Networking Automation Project (ONAP)
  • Compliance and Verification Committee (CVC)

Common NFVI Telco Taskforce (CNTT)

  • Reference Architecture 2 workstream (RA2)
  • Reference Implementation 2 workstream (RI2)

Cloud Native Computing Foundation (CNCF)

5G Cloud Native Network Demo (Brandon Wick)


How to engage

  1. Join the mailing list:  https://lists.opnfv.org/g/OVP-p2
  2. Subscribe to the calendar for the meetings: https://lists.opnfv.org/g/OVP-p2/ics/7337234/1823902251/feed.ics
  3. Engage in the discussions at the weekly meetings
  4. Share your ideas on these wiki pages and comment sections at the bottom of every page


What is the Minimum Viable Program

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:

E2E CNF Conformance Cycle 

In the below diagram the “?” indicate processes that need definition and refinement for the differing execution environment of OVP Phase 2.

Image Added


Categories of Conformance:

  • A. Cloud Platform Conformance
    • A1. Functional (i.e. CNTT RA-2 Compliance)
  • B. CNF Conformance
    • B1. Cloud Native (i.e. CNF Conformance)
    • B2. Functional (i.e. CNTT RA-2 Compatibility)
    • B3. ONAP
    • B4. Performance
  • C. Cloud Platform Benchmarking

MVP proposal

Not every thing can be tackled in the MVP, here are two elements that can be tackled for MVP.  

    • A1: Cloud Platform Conformance (may be partial)
    • B1 & B2: CNF Compliance

What needs to happen/Decided on:

  • Decide on Tooling:
    • Cloud installation tools into a given lab.
    • Basic Testing Tools.
    • what open source project is responsible of this.
  • Decide on Lab:
    • Community development resource access
    • Platform details - specific HW details, login info,etc.
    • what open source project is responsible of this.
  • Decide on Badging Process:
    • Test results review process
    • Portal and badging process
  • Decide on OpenSource Testing Projects
    • What project will deliver what test category (A, B, and C)
      • A: ?
      • B: ?
      • C: ?

Workstreams Proposal (see OVP 2.0 Workstreams)

MVP Roadmap - NEEDS COMMUNITY REVIEW/UPDATE

  • Define MVP - by April 1
  • Validate approach with partners (CNTT, CNCF, LFN projects) - during weekly OVP p2 meetings <ADD LINK>
  • Implement “HelloWorld” sampleCNF test - Hackfest at June Developer and Testing Forum
  • Implement MVP - by Q1/Q2 2021

Immediate tasks and AIs:

  1. Identify cloud infrastructure installation tools.
  2. Identify Labs for testing and human resources who will manage the labs (in addition to the testers)
  3. Identify projects to develop test scripts and tools to perform Cloud infrastructure functional testing and agree on scope.
  4. Agree on scope of CNF Onboarding testing.
  5. Identify projects to develop test scripts and tools to perform CNF testing and agree on scope.
  6. Agree on CVC portal.

OLD: Workstreams Proposal


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

  • On-boarding/Lifecycle Management testing - What are the preferred tools/methodologies for repeatably creating an NFVI environment supporting containers? Can CNFs be deployed and respond to basic lifecycle events? 
  • Platform test - What is the source for the tests and toolchains for developing and verifying the NFVI platform for container based CNFs? Are there existing CNCF infrastructure tests/standards that should be co-opted? What level of micro-services should be integrated into the standard platform? How do we validate each of the micro-services against a specific version of the platform?
  • CNF test - What is the source for the tests and toolchains for developing and verifying the CNFs as the SUT atop a verified NFVI? How does the CNCF test bed integrate into the OVPp2 workflow and test process? With many micro-services as “helper functions”, how do we validate each of the micro-services against a specific version of the CNF?
  • Performance testing - Both the infrastructure and CNF performance characterization would be useful - this is very difficult to cooperatively define/execute (DEFER)

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

...

F

...