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

Oops, it seems that you need to place a table or a macro generating a table within the Table Filter macro.

The table is being loaded. Please wait for a bit ...

NAMECOMPANY
Andrei KojukhovAmdocs
Anil GuntupalliVerizon
Beth CohenVerizon
Davide CherubiniVodafone
Lingli DengChinamobile
Frank BrocknersCisco
FERNANDO OLIVEIRAVerizon
Fu QiaoChinamobile
Furqan AhmadUNKNOWN
Ganesh KumarVerizon
Georg KunzEricsson
Gergely CsatariNokia
Ignacio PerezIBM
Kanagaraj ManickamHuawei
Atuchukwu, KodilinyeVodafone
Lincoln LavoieUniversity of New Hampshire
Mandeep Singh KalraAccenture
Mustafa OzdenNetsia
RameshGoogle
Olivier SmithMatrixx
Patric LineVoerEir
Phil RobbEricsson
Paul LancasterRedhat
Prayson PateAdva Optical Networking
Remi BarsOrange
Ryan HallahanAT&T
SaeidUNKNOWN
Serena FengZTE
Sridhar K. N. RaoSpirent
Tim IrnichSUSE
Perala, Timo (Nokia - FI/Espoo)Nokia
Tom KivlinVodafone
Trevor CooperIntel
Trevor LovettAT&T
Gaoweitao(Victor)Huawei
Vincent ScharfDeutsche Telekom
Vincent SeetGlobe Telecom
Dan XuHuawei
YangguanzhiHuawei
Yan YangChinamobile
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

  1. Hi ,

    Sorry for some naive queries. 

    1. 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
    2. 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
    3.  Something else to my understanding then please let me know.


    Would be helpful if you provide some more study materials. 

    Regards

    Abhay Narayan Katare


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

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

    1. Hi Weitao GaoLincoln 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.