Proposal Summary

Introduction

CNTT was formed in order to create a single spec for Openstack (1-stream) and a single spec for Kubernetes (2-stream).  The audience is the end-user companies that will become conformant to these specs.  CNTT needs to ensure that the end-user base can easily navigate and consume the documentation.

Problem statement

In the current CNTT documentation format, CNTT’s end user base will be challenged to figure out what they need to follow in order to be conformant to CNTT requirements and specs – should they follow what’s in RM or RA-1 or both ?  Maybe go look in some chapters of RI-1 or RC-1.  It’s a bit all over the place right now, hard to navigate.

Solution statement

Let’s make it easier for the end user to navigate !

Let’s make it easier for the end user to understand what they need to do !

• RA-1:  Consolidate requirements into the RA-1 as a single document; any other documentation can reference this content as a single source.  Some existing RI-1 and RC-1 content should be moved into RA-1; remaining RI-1 and RC-1 content may remain or be removed altogether.

• RI-1 only describes an example implementation of RA-1. 

• RC-1 only describes a test suite that is capable of verifying and validating the requirements in RA-1.

Deeper Detail of the Proposal

RA-1

What will the enhanced RA-1 look like ?

• Chapter 02

  • Section 2.2 (stays “Reference Model requirements”)

    • Need to include relevant RM requirements here going forward.  This will be a copy/paste, but there are < 10 and easy to manage since RM really doesn’t change that much.  This is one big step in consolidating requirements.

    • Strict approval process for those requirements can enforce aligning with RM requirements.

  • Section 2.3 (rename as “Architecture and ecosystem Requirements”)

    • Requirements will be only “must” (non-“must” will be moved to 2.4)

    • Add a column “RI-1 Applicability” to existing tables, indicating “yes” or “no” if applicable to the Implementation

    • Add a column “RC-1 Applicability” to existing tables,  indicating “yes” or “no” if applicable to the Conformance

    • Add a column “RC-1 Category” to existing tables,  indicating type of test in the Conformance

    • Note:  The existing tables in this section serve as a “requirements Table of Contents”, with a column “Traceability” that links to more detailed information about that specific requirement.  Maybe this column should be renamed to “Detailed information” or equivalent in order to avoid confusion.

    • Consider adding reference to OpenSource “project/test script” that covers this requirement for completeness (requirements fulfillment with project/test name, etc)

  • Section 2.4 (rename as “Architecture and ecosystem Recommendations”)

    • Requirements will be only “may” or “should” (this section will remain “Recommendations” as the title states)

    • Note:  The existing tables in this section serve as a “requirements Table of Contents”, with a column “Traceability” that links to more detailed information about that specific requirement.  Maybe this column should be renamed to “Detailed information” or equivalent in order to avoid confusion.

  • Link to RA-1 Ch 02

  • Link to current RTM draft proposal

• Chapter 09 will be a new chapter for “Implementation Requirements”

  • Introduction

    • Describe implementation intent, reference to RI-1 and its purpose

  • Requirements

    • Explain and refer to Traceability Matrix in Ch 02

    • Implementation specifications

      • Include OSTK setup / parameter / configuration details (references to RA-1 chapters as needed)

      • Include min hardware specs needed, software versions

  • Implementation Examples

    • hardware configurations, SDN, no SDN

  • Installer Selection

    • state that this is an end-user choice, provide link to RI-1 for an example

• Chapter 10 will be a new chapter for “Conformance Specs”

  • Introduction

    • Describe conformance intent, reference to RC-1 and its purpose

  • Requirements

    • explain and refer to Traceability Matrix in Ch 02

  • Verification

    • Make sure the manifests match the RA-1 configurations/specs

  • NFVi Validation

    • OSTK Services.  Make sure the OSTK services are correctly configured

    • OSTK API.  Make sure the OSTK APIs are matching the correct version / microVersion per RA-1 Ch 02/05

    • NVFI Validation using Golden VNF.  Make sure the infrastructure conforms to RA-1 Ch 02 requirements.

  • Badging

    • Description (not yet clear which group actually documents the requirements, so keep this as a placeholder section)

    • Include links to NFVi and VNF badging details in OVP

RI-1

What will the RI-1 look like based on proposed changes ?

• This document does not contain any CNTT requirements.

• Describes the OPNFV lab environment with relevant links. (“cookbook”)

• Describes the OPNFV Installer, usage and relevant links.  (“cookbook”)

• Describes any other tools used, provide links.

• Suggestion:  Lab interaction (login, operational tasks, etc) should be explained elsewhere, provide a link.

RC-1

What will the RC-1 look like based on proposed changes ?

• This document does not contain any CNTT requirements.

• Describes tools, processes and tests to verify and validate the reference implementation. (“cookbook”)

• Describes How to run the tests, analyze results. (“cookbook”)

• Provide links to tools and documentation.

• Describes badging process (?)

1. Introduction

   1. What

   2. Why

   3. Who

   4. Explain how to use and navigate docs

2. Requirements

   1. Explanation of traceability

   2. link to RA-1 Ch 02

   3. Implementation Specs

      1. <make sure that RA-1 Ch 02 has requirements that will link ("Traceability" column) to this section>

      2. Number of nodes, sizes, etc.

      3. Configuration info

      4. Software versions (eg libvirt version)

      5. <may contain references to other chapters, such as RA-1 Ch 04>

3. Examples for how to implement
   
   

   1. No SDN

      1. High transaction volume that needs a network node (eg)

      2. Low transaction volume

      3. Conformance lab (eg, 1 jump host, 3 controllers, etc)

   2. Yes SDN

      1. Production environment

      2. Conformance lab

   3. Specify hardware configurations

      1. Cores, etc

      2. Storage volumes

      3. Underlay Network

4. Installer Selection

   1. Explain the RI is provided as a example/guide if needed

   2. "It is the choice of the end user how to install, what installer, etc. 

   3. As a guide, here is a link to available installers as maintained by OPNFV."

1. Introduction

   1. What

   2. Why

   3. Who

   4. Explain how to use and navigate docs

2. Verification

   1. Make sure the manifests match the RA-1 configurations/specs

   2. Look at an example, eg Profile (link)

   3. Software versions, etc — this will refer back to RA-1 Ch 09

   4. This is currently a manual process to "verify accuracy"

3. NFVi Validation

   1. OSTK Services.  Make sure the OSTK services are correctly configured

      1. Describe the tests needed

      2. Functest implements the tests needed

      3. Reference to Current RC Ch 03 (3.3.4)

   2. OSTK API.  Make sure the OSTK APIs are matching the correct version / mVersion per RA-1 Ch 02/05

      1. Describe the tests needed

      2. Functest implements the tests needed

      3. Reference to Current RC Ch 03 (3.3.4)

   3. NVFI Validation using Golden VNF.  Make sure the infrastructure conforms to RA-1 Ch 02 requirements.

      1. Describe the tests needed

      2. Utilizes "Golden VNF" (eg, Clearwater IMS, VyOS vRouter and OpenAirInterface vEPC)

      3. Could use this "Golden VNF" to ensure NFVi meets min level of performance specified by RA-1 Ch 02 (TBD, pending Traceability Matrix PR and RM Cleanup PR).

4. OPNFV Badging

   1. Badging for NFVi (link)

   2. Badging for VNF (link)