Hi Oliver,
I am afraid I agree that we are already behind schedule, and need to finalize the use case for Release 1 as soon as possible. Hence we must be cautious in including any more complexity besides the existing usecase documentation, which is already mature and endorsed by interested and committed participants. We can certainly have more complex usecase discussion for further releases in parallel in usecase sub-committee while the implementation projects doing their coding for release 1. Lingli From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] On Behalf Of SPATSCHECK, OLIVER (OLIVER) Sent: 2017年6月3日 2:27 To: jamil.cha...@orange.com Cc: Hellmann, Gil <gil.hellm...@windriver.com>; SULLIVAN, BRYAN L <bs3...@att.com>; 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 I have stated this before but I strongly believe we need to separate the discussion between what ONAP needs or should support and what are the ecosystem components (both VNFs and cloud infrastructure) which are gating for the first release. The first category is easy. ONAP should support every VNF and every cloud. The second is more complex. Considering that we are already behind schedule on the project plan we had just agreed on only a few weeks ago: https://wiki.onap.org/display/DW/Release+Planning I am against adding any more complexity then absolutely necessary to release 1 at this point. As we are running late on the project plan we already either have to cut features or deliver late and adding more is not going to improve that situation. We should start talking about release 2 use cases soon so we are not in the same situation 5 months from now. Oliver On Jun 2, 2017, at 2:00 PM, jamil.cha...@orange.com <mailto:jamil.cha...@orange.com> wrote: Hello I agree with Chris comment and we need to have an open source reference implementation for ONAP including VNF and infrastructure to validate in CI/CD mode the Rel-1 components. After that we can use any commercial VNF and NFV infrastructure with ONAP components. Best Jamil Le 2 juin 2017 à 19:27, Christopher Donley (Chris) < <mailto:christopher.don...@huawei.com> christopher.don...@huawei.com> a écrit : 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: <mailto:onap-tsc-boun...@lists.onap.org> onap-tsc-boun...@lists.onap.org [ <mailto: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; <mailto:onap-tsc@lists.onap.org> 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: <mailto:onap-tsc-boun...@lists.onap.org> onap-tsc-boun...@lists.onap.org [ <mailto: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: <mailto: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 <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=> <image001.png> <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=> <image002.png> <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=> <image003.png> <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=> <image004.png> <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=> <image005.png> <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=> <image006.gif> “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 <mailto:ONAP-TSC@lists.onap.org> ONAP-TSC@lists.onap.org <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.onap.org_mailman_listinfo_onap-2Dtsc&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=3WBYkehchaQg0p_gO26aU_ahomnFHCk_-us7kcQebm4&m=wyY1B33JhrySJvwm-lSMlFVthkQRgxVPTx73EPspikg&s=wrfFMP4UWH_lPe8aAWIGnfHqpW4jroGiEVZ0mFy0DDw&e=> https://lists.onap.org/mailman/listinfo/onap-tsc _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. <image001.png><image002.png><image003.png><image004.png><image005.png><image006.gif>_______________________________________________ ONAP-TSC mailing list <mailto:ONAP-TSC@lists.onap.org> ONAP-TSC@lists.onap.org <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.onap.org_mailman_listinfo_onap-2Dtsc&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=3WBYkehchaQg0p_gO26aU_ahomnFHCk_-us7kcQebm4&m=wyY1B33JhrySJvwm-lSMlFVthkQRgxVPTx73EPspikg&s=wrfFMP4UWH_lPe8aAWIGnfHqpW4jroGiEVZ0mFy0DDw&e=> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.onap.org_mailman_listinfo_onap-2Dtsc&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=3WBYkehchaQg0p_gO26aU_ahomnFHCk_-us7kcQebm4&m=wyY1B33JhrySJvwm-lSMlFVthkQRgxVPTx73EPspikg&s=wrfFMP4UWH_lPe8aAWIGnfHqpW4jroGiEVZ0mFy0DDw&e=
_______________________________________________ ONAP-TSC mailing list ONAP-TSC@lists.onap.org https://lists.onap.org/mailman/listinfo/onap-tsc
