+1 I was taking this as a given. We need a robust vendor/commercial ecosystem of VNFs and NFVI software, in addition to open source. I see that the vCPE and vVoLTE use case documents on the wiki already incorporate this; which I am supportive.
From: <onap-tsc-boun...@lists.onap.org> on behalf of Gil Hellmann <gil.hellm...@windriver.com> Date: Thursday, June 1, 2017 at 2:08 PM To: "onap-tsc@lists.onap.org" <onap-tsc@lists.onap.org> Subject: [onap-tsc] Usage of commercial VNF and NFVI+VIM solutions for ONAP R1 use cases, and open lab Dear TSC members, It is very exciting to see the great momentum and grow in the ONAP community, I hear that there is different opinion / debate with regard to whether release 1 of ONAP should be using commercial VNFs & NFVI+VIM’s solutions for the implementation of the proposed use cases and open lab / integration in release 1 or should it be strictly limited to use only open source. I would suggest that the TSC will consider the following before making a decision: As it was agreed by both the TSC and the wider ONAP community, using real life use case like the proposed VoLTE and vCPE use cases for release 1 is very important to ensure that ONAP is built from day 1 in a way that will provide close implementation to a real-life use case which can provide proper foundation to use ONAP in commercial deployment, and implementation of real life use case can have a great contribution to the success of this project. ONAP as orchestration / MANO project require NFVI+VIMs (clouds) to run on, and VNFs to run to create the services. The use of commercial NFVI+VIMs and VNFs for the use case implementation and open lab / integration can have a big positive impact on our ability to be as close as possible to a real-life usage scenario. Limiting the usage *to only open source* solutions will limit dramatically the ability to get there. Not saying we should not use open source VNFs and NFVI+VIMs, but I hope we wouldn’t limit ourselves to only open source VNFs & NFVI+VIM in the open lab / integration lab and for the release 1 use cases, same like we would not limit yourself to only use open source hardware. I hope this can be considered, and thanks for your consideration. Regards, Gil Hellmann, VP - Solutions Readiness direct 289.553.5815 mobile 905.409.6878 skype ID gil.hellmann [cid:image001.png@01D2DAE1.D4307D10]<http://www.windriver.com/email/sigs/blog-network.html> [cid:image002.png@01D2DAE1.D4307D10] <http://www.linkedin.com/company/wind-river> [cid:image003.png@01D2DAE1.D4307D10] <http://www.windriver.com/email/sigs/facebook.html> [cid:image004.png@01D2DAE1.D4307D10] <http://www.windriver.com/email/sigs/twitter.html> [cid:image005.png@01D2DAE1.D4307D10] <http://www.windriver.com/email/sigs/youtube.html> [cid:image006.gif@01D2DAE1.D4307D10]<http://www.windriver.com/> “If you will it, it is no dream.” Theodor Herzl “If you want to go fast, go alone. If you want to go far, go together.” An old African proverb “The only way to avoid making mistakes is not to do anything. And that.. will be the ultimate mistake” Goh Keng Swee
_______________________________________________ ONAP-TSC mailing list ONAP-TSC@lists.onap.org https://lists.onap.org/mailman/listinfo/onap-tsc
