Projects
Space shortcuts
Page tree
Skip to end of metadata
Go to start of metadata

/*

On 10/29/2019, the CNTT-RI project proposal changed to the official name of, "Common Infrastructure Realization and Validation (CIRV)", with permanent homepage of CIRV (https://wiki.opnfv.org/pages/viewpage.action?pageId=47284396). 

*/

Reference Implementation for CNTT (Common NFVi Telco Taskforce)

Project Name:

  • Proposed name for the project: reference implementation for CNTT
  • Proposed name for the repository: CNTT-RI 

Project description:

This project aims at creating NFVi reference implementations (RI) based on the Common NFVI reference model （RM） and reference architectures (RA) defined in CNTT (Common NFVi for Telco Taskforce). The CNTT was officially announced in Jun. 2019. Co-supported by GSMA and LF, CNTT will operate as an open committee responsible for creating and documenting a Common NFVi Framework. This NFV industry initiative aims to help accelerate deployment across the entire telecommunications stack, from infrastructure (NFVi) to Virtual Network Functions (VNFs).

CNTT is currently working on the common NFVi reference model and reference architecture. The goals of CNTT can only be achieved if the model and architecture specifications end up being implemented as a reference for vendors to compare their commercial products against. Therefore, it is this project’s goal to work with upstream communities and other related projects in OPNFV to create reference implementations as one or several scenarios of OPNFV, along with required test cases and test frameworks.

Detailed mission for this project includes:

  • This project will act a feature project which is responsible for defining RI scenarios that comply with the CNTT reference model and reference architectures.
  • Work with upstream projects to defined RI details including detailed scenario descriptions and integration strategies.
  • Work with relevant projects in OPNFV, including installer projects, testing projects, infrastructure projects, to integrate, deploy and test RIs as part of OPNFV release life-cycle.
  • Implement a limited number of RIs that address CNTT reference architectures to meet operators’ requirements. Limit the number of RI to ensure limiting the VNF verification effort
  • Develop test-cases for testing RI. These test cases could be used by the compliance program for verification and compliance.
  • Work with LF Compliance and Verification Committee (CVC) to integrate RI, test cases and test frameworks within OVP compliance Framework.

As the Common NFVi initiative matures, project scope is expected to grow significantly. This project will periodically review scope and make recommendations to the TSC as to whether it should be split into multiple projects focusing on different areas, or whether it should remain a single project of OPNFV.

Scope:

The project will act as the landing space for CNTT RA within OPNFV, and will be a starting point for creating RIs. The scope of this project includes:

  • Work with communities of upsteam ingredients and with CNTT, to adopt Reference Architectures defined in CNTT
  • Translate RAs into deployable scenario descriptions, which can be considered as Reference Implementations for CNTT
  • Figuring out gaps for current components of RA, and work with upsteams or related projects in OPNFV to close the gap.
  • Work with installer projects, to generate scenarios and deployable code packets for specific installers
  • Work with testing projects, provide test requirements and test cases for RI testing, including the identification, and documentation of needed test cases.
  • Work with LFN Compliance and Verification Committee (CVC) to integrate RI, test cases/frameworks with OVP Framework.

OPNFV Testing Projects that are already looking to meet CNTT requirements with new features should continue to do so.

Testability:

  • This project intends to follow and adhere to the gates and quality criteria used by OPNFV.

Documentation:

Documentation will be available on official OPNFV Documentation portal and will include:

  • Pointers to CNTT Reference Architectures for Common NFVi with related information on ingredients and configurations
  • Gaps discovered from experience with integrating, deploying and testing RIs
  • Reference implementation description for Common NFVi
  • Test requirements for Common NFVi
  • All documentation generated by CNTT-RI project will reside in CNTT main repository (migrate to OPNFV CNTT-RI repo in future).

Dependencies:

  • This project depends closely on the progress of CNTT.
  • Much work can be done while the CNTT finishes its first RA

Committers and Contributors:

Committers

Fu qiao (China Mobile) fuqiao@chinamobile.com

Mike Fix (AT&T) <mf4716@att.com>


Contributors

Bin Hu (AT&T) bh526r@att.com

Cédric OLLIVIER (Orange)  cedric.ollivier@orange.com

Kyle A Greenwell (Verizon) <Kyle.Greenwell@verizonwireless.com>

Manuel Buil<MBuil@suse.com>

MURTUZA KHAN (AT&T) <mk721p@att.com>

MARK SHOSTAK (AT&T)<ms749f@att.com>

Rabi Abdel (Vodafone) <abdel.rabi@vodafone.com>

William Bonnett (Verizon) william.bonnett@verizon.com

Zhang Hongli (China Mobile) zhanghongli@chinamobile.com

Trevor Cooper (Intel) trevor.cooper@intel.com

Li Ying (China Mobile) liyingyjy@chinamobile.com

Zhao Qihui (China Mobile) zhaoqihui@chinamobile.com

Georg Kunz (Ericsson) georg.kunz@ericsson.com

Pierre Lynch (Keysight) pierre.lynch@keysight.com

Shiby Parayil (Iconectiv) sparayil@iconectiv.com

Arif Khan (Voereir) arif@voereir.com 



Planned deliverables:

  • Reference implementation for Common NFVi
  • Test Requirements for Common NFVi

Proposed Meeting Frequency:

  • This project will meet on a weekly basis.

Proposed Release Schedule:

  • This project is planned for the first release in 2020 Q1.

Key Project Facts

Project Name: Reference Implementation for CNTT Project Proposal
Repo name: CNTT-RI
Lifecycle State: Proposal
Primary Contact: Mike Fix (AT&T) <mf4716@att.com>

Project Lead: Mike Fix (AT&T) <mf4716@att.com>

Jira Project Name: CNTT-RI
Jira Project Prefix: [CNTT-RI]
Mailing list tag [CNTT-RI]
Committers:



  • No labels

5 Comments

  1. Rabi Abdel

    Hi Qiao Fu , added few lines, hope it is OK.

    Rabi

  2. Trevor Cooper

    Hi Qiao Fu... I have made edits to the proposal for clarification. Please see if you agree with these changes. 

  3. Rabi Abdel

    Hi Qiao FuI have added one line to clarify where the documentation will live as per request from the commjnity


  4. Manuel Buil

    I have some comments about the proposal:

    1. One of the mission points says "Develop test-cases and tools for testing RI". However, I don't think the intention of this project is to develop testing tools, right?
    2. Regarding the same point, it says it will develop test-cases and then, in the documentation, it only talks about "Test requirements for Common NFVi". Could you clarify if it will develop test-cases or test requirements or both?
    3. In the scope, I can read "Figuring out gaps for current components of RA, and work with upstreams or related projects in OPNFV to close the gap". How you intent to collaborate with upstream communities? Is this project going to flag the gaps to upstream communities? Or is it also proactively going to contribute code to upstream communities? If the former, I wonder how the upstream community will prioritize these gaps over others.
    4. If I understand correctly, this project will basically provide documentation: list of gaps, pointers to CNTT RA, RI Scenario description and test usecase/requirements... All the documentation of this project "will reside in CNTT main repo". However, if this project wants to be part of OPNFV, shouldn't the deliverables be in a OPNFV repo instead? For example, how can this project "follow and adhere to the gates and quality criteria used by OPNFV" if everything generated by it is outside of OPNFV?
    5. In the dependencies, it says "much work can be done while the CNTT finishes its first RA", could you provide an example?

    1. Al Morton

      We've exchanged several messages to discuss and resolve Manuel's comments. I'm posting them below, but the colored text was not preserved. I think we've reached closure on all items, and I have edited the proposal to address actionable points.

      MB=Manuel, MFix=Mike, RA=Rabi

      • 1 - One of the mission points says "Develop test-cases and tools for testing RI". However, I don't think the intention of this project is to develop testing tools, right?  MFix:  That is correct.  The proposal has been updated to remove the tools reference.
      • [MB] - Ok, thanks
      • 2 - Regarding the same point, it says it will develop test-cases and then, in the documentation, it only talks about "Test requirements for Common NFVi". Could you clarify if it will develop test-cases or test requirements or both?  MFix:  Test requirements implies the identification, and documentation of needed test cases.
      • [MB] - Ok. thanks. It would be nice to write this clarification in the description
      • 3 - In the scope, I can read "Figuring out gaps for current components of RA, and work with upstreams or related projects in OPNFV to close the gap". How you intent to collaborate with upstream communities? Is this project going to flag the gaps to upstream communities? Or is it also proactively going to contribute code to upstream communities? If the former, I wonder how the upstream community will prioritize these gaps over others.  MFix:  Proposing weekly RI project calls to trap issues, gaps, and resolve logistics gaps with upstream partners for any test projects which need to be augmented to meet the needs of specific RI testing.  In short, via the weekly calls and status emails to impacted upstream partners.
      • [MB] - Ok. Note that in the past, some OPNFV projects identified gaps and then went to upstream projects asking the committers to fill those gaps. In most cases, that did not work and the item stayed in the backlog of the upstream project forever and thus the OPNFV project became stuck. This project has not even started so it is hard to predict how the upstream community will react to the missing requirements/features identified by CNTT-RI but I think this is one of the biggest hurdles you will find.
      • 4 - If I understand correctly, this project will basically provide documentation: list of gaps, pointers to CNTT RA, RI Scenario description and test usecase/requirements... All the documentation of this project "will reside in CNTT main repo". However, if this project wants to be part of OPNFV, shouldn't the deliverables be in a OPNFV repo instead? For example, how can this project "follow and adhere to the gates and quality criteria used by OPNFV" if everything generated by it is outside of OPNFV? MFix:  Short term, we will keep documentation in the CNTT Repo to maintain momentum, and ensure no artifacts become stale, or fragmented across diff repos.  Long term, we will more/store the artifacts in respective OPNFV repos.

      [MB] - Being part of OPNFV and have the deliverables somewhere else is something a bit weird to me. Some questions that come to my mind:


      4.1 Are you planning to be part of the OPNFV release? In that case, how will you add your deliverables to the release? As of today, the documentation for a release (e.g. https://docs.opnfv.org/en/stable-hunter/) is fetched and aggregated from OPNFV repos. I am not sure whether this is possible to do using external repos.

      4.2 To verify the quality criteria in OPNFV we are using gates that are triggered per commit in OPNFV repos. If this project commits stuff outside of OPNFV repos, how can the OPNFV quality criteria be verified?

      [RA] Totally Agree with the need to align with OPNFV release, gating, documentation, etc. The thinking behind  keeping it under CNTT repo is to flexibly align with CNTT RM and RA as they are being developed. Having all them under same GitHub repo makes it much easier to develop, accelerate, align, and spot dependences, etc. (which is very critical at this stage)

      • In terms of Documentation: I imagine OPNFV Releases should be able to fetch .md file from other repositories for documentation purposes only. (can we double check this please!)
      • In terms of Gating and Quality Assurance: CNTT-RI is not expected to generate source code at this moment and will focus on the documentation only.  For that reason I imagine gating and code assurance is less of an issue.

      Finally, totally agree with the need to move to OPNFV in near future, it is just the fact we would like to keep things de-fragmented until things are more stable before we move to GSMA, OPNFV.


      • 5 - In the dependencies, it says "much work can be done while the CNTT finishes its first RA", could you provide an example? MFix:  e.g. Finalization of RI requirements.  Finalization of RA alignment and definition.  Continued work on build-out of Verification Partnerships, flow, and respective documentation.  Keep in mind, until now, there has been no formal project engagement to work directly with the OPNFV, and respective partners.  The CNTT-RI effort formalizes this communication medium while the task force and the delivery efforts continue to evolve and mature.

      [MB] - OK. Let me ask you one extra question,


      5.1 why did you decide to categorize this project as "feature project"? I think OPNFV has also the term "requirements project" which probably fits better here. If I understand correctly, ideally, this project should facilitate the communication between CNTT and OPNFV. I can imagine CNTT coming with some requirements and then OPNFV people can give feedback about those and then start discussions all together about how to handle those requirements across the different OPNFV projects.

      MFix (9/13): It was explained to us from OPNFV TSC reps that there were three types of OPNFV projects:  Installer, Feature, Test.  As such, our implementation efforts, which include defining test scenarios/cases, and providing architecture guidelines most aligned with Feature.