Meetings
The compliance and verification committee meets on a regular basis.
Monday, 0600 Pacific Standard Time/ 1500 Central European Time / 2200 China Standard Time/1400 UTC with the following Zoom meeting information.
Join Zoom Meeting
https://zoom-lfx.platform.linuxfoundation.org/meeting/99028671010
There is a mailing list and calendar on groups.io.
Subscribe to the calendar here: https://lists.lfnetworking.org/g/lfn-compliance/ics/3684108/1233804156/feed.ics
Committee Charter:
The Compliance and Verification Committee (“C&V Committee”) is the community driven body within LF Networking which defines policies and oversight for compliance and certification program. The C&V Committee operates under the guidelines established by LF Networking and Governing Board for meeting organization and rules of order. The C&V Committee will meet either by conference call or in face to face session. Meetings will be announced in accordance with the processes and procedures established by LF Networking. Participation in the C&V Committee is open to all participants (members and non-members) of LF Networking, and the target makeup of the C&V Committee is to include a balance of representatives with active testing experience as well as end user requirements. Elected leadership positions and eligible voters within the C&V Committee shall be from LF Networking member companies.
Responsibilities include:
- Communicate with Governing Board on compliance and verification business tasks;
- Define the governance of compliance and verification programs, subject to Governing Board approval;
- Define the target for the mark or marks: network software platform, Infrastructure, applications etc.;
- Define the interoperability promise;
- The most practical and desirable degree of verification testing (e.g., self-certification vs 3rd party lab);
- Approval of Certification Test Labs; and
- Makes all decisions regarding granting and maintaining the verification mark(s) as well as the violation and appeal processes.
Leadership
CVC Chairperson: Olivier Smith
CVC Co-vice-chairpersons: Yan Yang
2021 CVC Voting Committee Members
NAME | COMPANY |
Andrei Kojukhov | Amdocs |
Anil Guntupalli | Verizon |
Beth Cohen | Verizon |
Davide Cherubini | Vodafone |
Lingli Deng | Chinamobile |
Frank Brockners | Cisco |
FERNANDO OLIVEIRA | Verizon |
Fu Qiao | Chinamobile |
Furqan Ahmad | UNKNOWN |
Ganesh Kumar | Verizon |
Georg Kunz | Ericsson |
Gergely Csatari | Nokia |
Ignacio Perez | IBM |
Kanagaraj Manickam | Huawei |
Atuchukwu, Kodilinye | Vodafone |
Lincoln Lavoie | University of New Hampshire |
Mandeep Singh Kalra | Accenture |
Mustafa Ozden | Netsia |
Ramesh | |
Olivier Smith | Matrixx |
Patric Line | VoerEir |
Phil Robb | Ericsson |
Paul Lancaster | Redhat |
Prayson Pate | Adva Optical Networking |
Remi Bars | Orange |
Ryan Hallahan | AT&T |
Saeid | UNKNOWN |
Serena Feng | ZTE |
Sridhar K. N. Rao | Spirent |
Tim Irnich | SUSE |
Perala, Timo (Nokia - FI/Espoo) | Nokia |
Tom Kivlin | Vodafone |
Trevor Cooper | Intel |
Trevor Lovett | AT&T |
Gaoweitao(Victor) | Huawei |
Vincent Scharf | Deutsche Telekom |
Vincent Seet | Globe Telecom |
Dan Xu | Huawei |
Yangguanzhi | Huawei |
Yan Yang | Chinamobile |
Yue Yuan | ZTE |
Blue highlighting == Voting member
List as of
Governance
The Chair and Vice-Chair positions are appointment for a 1-year term each April. Typical nomination period will be 2 weeks, followed by a 1 week voting period, similar to the typical project TSC processes.
- Additionally, subcommittee leadership positions shall be elected with the same timing.
- A single list of eligible voters shall be used for all elections (chairs and subcommittees), with the following requirements:
- The designated voter must work for an LFN member company and be a participant of the CVC or a subcommittee.
- There shall be one designated voter per company.
- For an election to complete, at least simple majority of the eligible voters must cast ballots (similar to the LFN board / TSC processes).
4 Comments
Abhay Narayan Katare
Hi ,
Sorry for some naive queries.
Would be helpful if you provide some more study materials.
Regards
Abhay Narayan Katare
Lincoln Lavoie
Hello Abhay Narayan Katare
For your first question, I think the answer is slightly more gray. To "replace" a VNF between vendors, you would need to verify the functions provided by the VNF are "equal" in addition to ensuring the VNF runs on top of the infrastructure. For example, if your VNF is providing an IP routing function, both VNFs need to provide the same IP routing capabilities to support the swap. Because there are a huge (un-countable) number of possible functions provided by VNFs, the program is not able to solve that problem. The program is focused on verification of the VNF running within the infrastructure, including MANO. This is the next logical step, beyond the tests currently run by the VVP and VNFSDK projects cited by Victor.
For the second part, Victor is correct, that would require testing of all the individual interfaces for each component. The current NFVI program (https://nfvi-verified.lfnetworking.org/#/) does cover this topic to a degree, treating the NFVI as a "component" and testing it supports the set of capabilities, agreed by the OPNFV project for the specific test release. The tests for the capabilities are pulled from a combination of the Functest and Tempest, Bottlenecks, and yardstick. The tests are designed to run on both the vanilla open source installs, as well as commercial installs, which I think would give you part of what you are referring to, in terms of "swapping" or "comparing" one NFVI with another.
Weitao Gao
Hi, Abhay Narayan Katare
Please See my answer inline。
Is this verification program is for VNF level ( let say i on-boarded and deployed one VNF from vendor X and it will continue to run if in future i replace product with vendor Y ) ? OR
Victor: Yes, ONAP has two projects for VNF verification call VNFSDK(for tosca based VNF) and VVP (for Heat Based VNF). For the VNF Replacement, currently, in my opinion, the answer is No. we are try to define the common requirements for VNF LCM and Performance and Compliance Check. currently, the compliance test is available.
this verification program will support in components level ( let say i have a product ( specifically if ONAP) of different component VNFM, Orchastrator, etc and if i want to replace VNFM with another vendor products and it will continue running as a system etc ) OR
Victor: I think the answer is No. This is more like the API compliant between multiple components. Maybe you can have a quick look on ONAP VF-C projects which could talk with multiple VNFM via the driver.
Something else to my understanding then please let me know.
CVC Vision Reference: Meeting Minutes and Materials
CVC MVP on ONAP EI Alto Release:VNF Validation Minimum Viable Product
Abhay Narayan Katare
Hi Weitao Gao, Lincoln Lavoie
Thanks for your quick response.
Let me again try to put my query as seems i could not clearly elaborate it.
First Query: Is this verification program will support in VNF level ( let say i on-boarded and deployed one VNF from vendor X of ONAP (here i am not replacing VNF , i am just replacing Vendor of ONAP after it is on-boarded and deployed ) and in future due to cost or any other factor i want to replace this vendor with another Vendor of ONAP ( Let Say "Y" ).
So, should this VP will support this feature of Vendor replacement.
Second Query:
I am agree that in order to support interoparability in component level ( i.e. replacing particular component (SO, SDC, APC etc ) of ONAP from one vendor or even to integrate vendor specific support of VNFM in ONAP etc) we have to first adopt standardization in interfaces ( SOL002, SOL003 etc Interfaces ) and even standardization in packaging of VNFs (SOL001, SOL004 etc support).
So this VP will also support this feature after adopting standardization.