I think there’s a difference between using proprietary software in the production of the platform (e.g., incorporating proprietary code into ONAP) and testing to make sure that ONAP will work in an ecosystem including commercial products (e.g., bringing commercial VNFs, VIMs, etc. into the lab). I see the latter as the point of the open lab project – testing integration with third-party components (including commercial) to prove out our use cases. I expect that we will have separate labs (e.g. hosted by LF) for software development and unit test purposes. This was generally the approach we used in OPEN-O, where we had labs in China Mobile and China Telecom integrating commercial VNFs and PNFs with OPEN-O to prove out our vCPE and VoLTE use cases, and I think it’s effective.
Chris From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] On Behalf Of SULLIVAN, BRYAN L Sent: Thursday, June 01, 2017 5:06 PM To: Hellmann, Gil; onap-tsc@lists.onap.org Subject: Re: [onap-tsc] Usage of commercial VNF and NFVI+VIM solutions for ONAP R1 use cases, and open lab For an open source community, the use of proprietary software in the production of the platform (including tools, NFVI platforms, or VNFs used as use cases for developing the platform in open labs), or as part of the released platform, takes the project into a tricky space. It will complicate how “open” the labs actually are, e.g. who has the ability to use what where, and the transparency of test results with/against specific proprietary components. Certainly it would be useful to provide some environment in which commercial NFVI platforms or VNFs are tested against the ONAP platform, and takeaways from that used to help improve the project. But that environment would probably need to be separate from the main “open” labs or more tightly controlled, as access to the proprietary components/VNFs would be problematic. An alternative to using proprietary NFVI platforms is to focus the integration testing in the OPNFV, where open source versions of NFVI platforms are freely available for testing with. Integrating/testing with these (currently RedHat/RDO, Ubuntu, Mirantis, and Huawei) can address probably the vast majority of issues in ONAP-NFVI interop, and a side benefit is that any gaps would be addressed in an open source space (avoiding the temptation to address gaps by adding proprietary feature compatibility into ONAP). We are planning to drive ONAP-NFVI integration in OPNFV for that purpose over the current and next release. I will be giving a talk on this at the OPNFV Summit the week after next, so invite any more detailed discussion on what’s planned. Thanks, Bryan Sullivan | AT&T From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] On Behalf Of Hellmann, Gil Sent: Thursday, June 01, 2017 2:09 PM To: 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@01D2DB8A.08964000]<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.windriver.com_email_sigs_blog-2Dnetwork.html&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=2-FskNSRL5sc9nQutgafCDIk3JbYrtcUwMwT5Zs1Tnk&m=2gZi-04__6PYt0X1iWRX4WCR_ODRd9mydvF-aDI1da0&s=4lpxit7VdJO13x24ze5htRR2dU_XPFpRFLwNtWnR-Eg&e=> [cid:image002.png@01D2DB8A.08964000] <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.linkedin.com_company_wind-2Driver&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=2-FskNSRL5sc9nQutgafCDIk3JbYrtcUwMwT5Zs1Tnk&m=2gZi-04__6PYt0X1iWRX4WCR_ODRd9mydvF-aDI1da0&s=-hOxZJMRPt908cLXX_LXO65qmnypVRg232YMHPrkh7c&e=> [cid:image003.png@01D2DB8A.08964000] <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.windriver.com_email_sigs_facebook.html&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=2-FskNSRL5sc9nQutgafCDIk3JbYrtcUwMwT5Zs1Tnk&m=2gZi-04__6PYt0X1iWRX4WCR_ODRd9mydvF-aDI1da0&s=CFeaMgiB6J0Udi6PMuYF7zPW9kytZKlgCCTjufVIdOU&e=> [cid:image004.png@01D2DB8A.08964000] <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.windriver.com_email_sigs_twitter.html&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=2-FskNSRL5sc9nQutgafCDIk3JbYrtcUwMwT5Zs1Tnk&m=2gZi-04__6PYt0X1iWRX4WCR_ODRd9mydvF-aDI1da0&s=ytknQKhfAP9haQE6AXVe0C50KIG2NhiTmiFRik_i5wc&e=> [cid:image005.png@01D2DB8A.08964000] <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.windriver.com_email_sigs_youtube.html&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=2-FskNSRL5sc9nQutgafCDIk3JbYrtcUwMwT5Zs1Tnk&m=2gZi-04__6PYt0X1iWRX4WCR_ODRd9mydvF-aDI1da0&s=9T5RF3Ip6bUd5M9Zj--VJG3FTu7co_es05VHm32Cj0U&e=> [cid:image006.gif@01D2DB8A.08964000]<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.windriver.com_&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=2-FskNSRL5sc9nQutgafCDIk3JbYrtcUwMwT5Zs1Tnk&m=2gZi-04__6PYt0X1iWRX4WCR_ODRd9mydvF-aDI1da0&s=dpkVxnRhMMqybAda22Q1iJYX9gE-czMoRfJZmp-T95g&e=> “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
