Skip to end of metadata
Go to start of metadata

The CNTT and OPNFV communities agree to follow the premises below and subscribe to the associated RACI chart for scope boundaries:

  1. CNTT defines specifications and provides only the specifications to OPNFV
    • CNTT: Reference Model, Reference Architecture, Reference Implementation 
    • OPNFV: Reference Implementation, Reference Compliance
    • OVP: Testing, Badging 
  2. OPNFV performs builds from the Reference Implementation specifications.  
  3. "Cookbook" artifacts are the domain of OPNFV, CNTT should participate in the management of the cookbooks, and selects the Test cases to be executed.
  4. A release management method including feedback loops is needed between OPNFV and CNTT. LFN/OPNFV has an existing meeting in which some members of the CNTT community will participate. 
    • CNTT Participants that will participate include Scot Steele, etc
  5. Cross Community Collaboration must increase without overloading the participants.
    • Recommendation: WS Leads should identify WS participants that can attend the other community TSC meetings
    • Regularly held cross community meetings should be held. Community Chairs should schedule/delegate to community participants to implement/manage


General group agreement 

  • The RACI doc and other docs related to the organization are all living docs.  
  • Long term there will need to make a decision related to the final home for CNTT project work. – Vincent Danno
  • We need to see how successful "1" arrangement is. → no need to rush in thinking about "2" and we still didn't figure out "1". I STRONGLY SUGGEST NOT TO RUSH INTO THIS WITHOUT FIGURE OUT "1" AND PROVE MODEL WORKS. Rabi Abdel


Questions need to be answered: Current Mode OPNFV/CNTT RACI Chart

  • Cedric Ollivier How can it help the short term issues? an implementation is needed for the conformance on the VNF side and we need additional relevant resources in both sides: specifications (CNTT) and OPNFV (OPNFV)
  • Cedric Ollivier How would be leverage on it in a long term view? We shouldn't reinvent the wheel every release - the current model works and the separation between CNTT and OPNFV is clear for a few main CNTT contributors
  • What happens when CNTT develops a requirement in, say, RI-1?
    • does CNTT goes directly to prospective OPNFV project and get it implemented (via that project PTL).
      • how will the implementation link back to CNTT releases? 
      • Cedric Ollivier : CNTT RC lists the deliverables (containers/tags/testcases) from OPNFV. What's the additional point here? Could we detail the gap targeted?
      • Will each project have their own release cycle (with appropriate baggings) or will OPNFV have an overall release cadence ? how does the model work?
      • Cedric Ollivier I think the model works already.
        • CNTT is in charge of test case description/selection and playbooks (see RC) and then CNTT selects the test cases from OPNFV according to them.
        • OVP should implement the test result verification from the archive produced by CNTT playbook - Compared to first OVP model the test case selection is now in RC
    • or will CNTT has to follow some kind of process to get their requirements implemented?
      • Cedric Ollivier : we may consider the classical opensource model here and then the answer could be straightforward: by putting developpers
      • Cedric Ollivier : opensource cannot follow a subcontractor model by design
    • or will OPNFV itself regularly get CNTT releases and find the right OPNFV projects to implement any new requirements.
      • via CIRV? Cedric Ollivier: CIRV is mostly an umbrella for incubation projects. It should be done at the project level possibly between CNTT RI/RC leaders and the PTLs/core developpers
    • what is the role of OPNFV TSC on all this? who is accountable for what?
    • we need to talk about accountability and make it clear who is accountable for what!
  • How does OVP fit into this matrix?
  • Given the GSMA process is it mostly a consumer and ratifier of the output from CNTT, or does it have a role in providing feedback?  I.e. how can this be set up to be a two way street? 


Scott Steinbrueck proposal 6/9/2020

The challenge is how to organize the content in an efficient way that reduces complexity for the authors/implementors to create, while also producing a quality product that is simple for the end user base to navigate, read and comprehend.

Seeking agreement to the following premise:

  • RA-1 is the requirements and specs
  • RI-1 is an example implementation (“example” word is used because no company is required to follow this exact lab setup / installer approach – it’s an example)

Cedric Ollivier

Does it mean that RI-1 would be strictly removed from CNTT repository?

Yes why not considering Airship as an implementation amongst others which tries to implement the CNTT requirements (RC is currently rather verified thanks to Functest SUT and Field trials).

I would agree to fully remove RI1 from CNTT but CNTT needs a reference implementation somewhere which passes RC successfully for the next steps (conformance of VNF/CNF).

By the way, it's becoming urgent to take CNTT results into account to find the best path (RI1 doesn't pass RC - we can't leverage on the existing resources allocated to Functest for the VNF conformance)

If FMO targets to improve the process, having an implementation fulfilling CNTT requirements is a very short term key issue 

  • RC-1 is a test conformance suite

Scott Steinbrueck proposal 6/16/2020


Big Picture

Cedric Ollivier

Sorry I'm lost here. It's introduced as an executive summary but I would rather consider that it increases so much the complexity both regarding the collaborative work and the end users.

If we target an executive summary it could rather be a minor change in the top CNTT document listing (it could be a new Executive summary bullet in between Governance and Technical specifications)

  • RA1 requirements
  • additional relevant requirement details  (e.g. RA1 chapter 5)
  • the related mandatory test cases (please see 3.4 Test Cases Traceability to Requirements)
  • RC playbook (please see 4.3 NFVI Testing Cookbook)

RA1 would decide for everything which is not right regarding the current work and false from a collaborative mindset.

I'm lost by considering RI1 as an example. Why should we increase the complexity of RA1 in that case? 

If the overall work is about the separation between CNTT and OPNVF, everyone should know that RC1 Baldy and older is only driven by the CNTT part:

  • testcase descriptions, selection and integration are part of CNTT RC
  • OPNFV implements the test cases and offers the deliverables (e.g. containers) as asked by CNTT (see first bullet)

In my view, Ch 10 is just complexifying the current model which should firstly be demonstrated as false to avoid any sophism as it seems here.




 Click here to expand for more explanation...

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.


Document

Owner

What

RA-1

CNTT

  • Ch 02 is “Requirements Traceability Matrix” (proposal already in progress)
  • (new) Ch 09 – Implementation Requirements
  • (new) Ch 10 – Conformance Requirements

RI-1

OPNFV

  • ("Cookbooks") Describes lab environment, installer, tools, and any other process
  • No CNTT requirements

RC-1

OPNFV

  • ("Cookbooks") Describes test tools, test cases created, running the tests, analyzing results.
  • Describe how the created test cases match to CNTT RA-1 Ch 10/02
  • No CNTT requirements

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 (?)


More Detailed View of RA-1, Ch 09 and 10



 Click here to expand the proposal for Chapter 09...
  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."

 Click here to expand the proposal for Chapter 10...
  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)
  • No labels

3 Comments

  1. I'm quite lost here and sorry I don't understand the overall target.

    They are a few sophisms (we should first clearly demonstrate the current issues) and knowlegde gaps in the overall processes (opensource model/principles) between the CNTT actors which doesn't help understanding the overall target.

    It could be a short term view mostly fixing our current problems: need a compliant implementation for RA1 and RA2, ask for new contributors in both CNTT and OPNFV, ask OVP to take RC into account, etc.

    It could be rather a long term view (we shouldn't reinvent the wheel every release) clarifying what goes to GSMA (do we extend the first scope?) and where the remaining part and the community land (OPNFV as firstly mentioned, ot the 2 new alternatives).


  2. I note that we are blocking ongoing actions due to FMO (see the RC discussions for the common requirements accross RC1 and RC2) which could be tagged as an higher priority.

    Could we all agree to continue the ongoing work until any major and well agreed outcome from the FMO discussions?

  3. I have not been as involved in the FMO and associated conversations as I would like to have been.  What I would like to say is this appears to be a clear definition and I really appreciate the work that has gone into this.  Processes are never easy to create, especially when ideas are continuously changing as we move forward.

    We are at the point where this needs to scale, we need more new people to enter into the community.  Without this level of clarity and a place for information sharing, I don't think we will be successful in growth.  A lot of good work has been done already, and a lot of progress has been made.  Now the challenge is to open this up in such a way that makes it easier to add newcomers without having a steep learning curve.

    Perhaps because I have not been as involved, I can look at this with a newcomer's set of eyes and say that it clarifies things for me, and I feel like I know more about where things belong than I did before.

    We have also been talking in the OPNFV TSC about the overall release process and strategy for OPNFV.  A way of looking at it is CNTT would be able to provide a set of requirements that OPNFV would respond to.  There would be a master tracking of what requirements are already met by the different projects, and what the gaps are.  For the gaps, there is a suggestion that we create project definitions, similar to what we do for intern projects, that would have a estimated duration, skill set and definition of how we know it is complete.  This also would allow for newcomers to scan a list of work items and contribute according to their skills and time.