+1
Lingli From: [email protected] [mailto:[email protected]] On Behalf Of Danny Lin Sent: 2017年6月2日 14:10 To: [email protected]; [email protected] Cc: [email protected]; [email protected]; [email protected]; [email protected] Subject: Re: [onap-tsc] Usage of commercial VNF and NFVI+VIM solutions forONAP R1 use cases, and open lab Hi, Thanks Mazin for driving the clarity on this issue, and also Adityakar for further comment. I do want to touch base on another aspect that was brought up by Gil in his original thread, which is about NFVi+VIM. I hope we are not limiting ourselves to only open source NFVI+VIM for the release 1 use cases. To follow the same line that Mazin highlighted below that VNFs need to evolve towards supporting ONAP VNF requirements, we should also be open to any NFVi+VIM which aligns with overall ONAP architecture framework and model driven principal. To this point, I want to mention that this is the fundamental goal of our Multi VIM/Cloud project, which is to allow cloud providers (either from pure open source or from commercial 3rd party vendors) to integrate into ONAP in a way where it follows ONAP principal and requirements, driven through the community effort and open collaboration. We are also prioritizing the project scope to ensure MultVIM supports R1 use cases through integration lab Thanks Danny From: <[email protected] <mailto:[email protected]> > on behalf of "[email protected] <mailto:[email protected]> " <[email protected] <mailto:[email protected]> > Date: Thursday, June 1, 2017 at 9:19 PM To: "[email protected] <mailto:[email protected]> " <[email protected] <mailto:[email protected]> > Cc: "[email protected] <mailto:[email protected]> " <[email protected] <mailto:[email protected]> >, "[email protected] <mailto:[email protected]> " <[email protected] <mailto:[email protected]> >, "[email protected] <mailto:[email protected]> " <[email protected] <mailto:[email protected]> >, "[email protected] <mailto:[email protected]> " <[email protected] <mailto:[email protected]> > Subject: Re: [onap-tsc] Usage of commercial VNF and NFVI+VIM solutions forONAP R1 use cases, and open lab Dear Mazin, I understand that "VNF Requirements" project is meant for the same. I propose that we make a Generic Requirements (GR) document covering all aspects and interfaces including FCAPS. The document shall be version controlled and will mature alongside ONAP. While on boarding test/demo and commercial VNFs, we may seek compliance document from the VNF provider with respect to the GR. Regards, Adityakar Jha _____ From: GILBERT, MAZIN E (MAZIN E) [[email protected]] Sent: 2 June 2017 at 8:57:15 AM To: [email protected] <mailto:[email protected]> CC: [email protected] <mailto:[email protected]> , [email protected] <mailto:[email protected]> , SULLIVAN, BRYAN L, [email protected] <mailto:[email protected]> Subject: Re: [onap-tsc] Usage of commercial VNF and NFVI+VIM solutions forONAP R1 use cases, and open lab Team, I will put together a set of expectations for ONAP to consider commercial VNFs in R1 or future releases. We can then discuss and have them vetted by the TSC. Having access to the VNF in a testing lab with continuous support is necessary but not sufficient. We need to ensure that VNFs evolve towards supporting ONAP VNF requirements so we harmonize telemetry, alarms, etc. This is crucial to avoid writing custom code for each service, and each VNF. Mazin On Jun 1, 2017, at 11:09 PM, [email protected] <mailto:[email protected]> wrote: To make our discussion simple, I'd like to separate ONAP with the infrastructure and VNFs which is not in the scope of the open source project. I do not find any improper to leverage commercial VNFs or infrastructure for testing open source code. I do not object introducing open source infrastructure and VNFs for ONAP testing. I just have the same concern with Oliver in previous mail, that is if someone can commit the support to the open source infrastructure or VNFs. I believe efficient support with quick response is critical for testing. Otherwise developers might struggle in the mire of bugs in ONAP and also bugs in infrastructure or VNFs. ZTE have committed to provides our commercial vEPC for voLTE use case that means we also committed support during testing. So we need volunteers commit their support on any open source infrastructure or VNFs. Thanks, 袁越 yuanyue 资深战略规划师 Senior Strategy Planner 技术规划部/技术规划部/系统产品 Technology Planning Dept./Technology Planning Dept./System Product <9ae3e214c17d49ed935d87c674ba3ee2.jpg> <24242e5637af428891c4db731e7765ad.jpg> 南京市雨花区软件大道50号中兴通讯3号楼 1/F,Building 3, ZTE Nanjing R&D Center II, No.50, Software Avenue,YuHua District,Nanjing,P.R.China 210012 T: +025 88013478 M: +86 13851446442 E: [email protected] <mailto:[email protected]> www.zte.com.cn <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.zte.com.cn_&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=IKSC5mg8GeOiSar1dax3GQ&m=avgzWIvsa6Z2D_k7RnytojLZMEJEtw5l_0PzGTkUa7g&s=hWVuC6wclcUTzUVNp4L9L3FkCtMokQ8ttoxJKANiPkk&e=> 原始邮件 发件人： ＜[email protected] <mailto:[email protected]> ＞; 收件人：＜[email protected] <mailto:[email protected]> ＞;＜[email protected] <mailto:[email protected]> ＞; 日 期 ：2017年06月02日 08:06 主 题 ：Re: [onap-tsc] Usage of commercial VNF and NFVI+VIM solutions forONAP 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: [email protected] <mailto:[email protected]> [mailto:[email protected]] On Behalf Of Hellmann, Gil Sent: Thursday, June 01, 2017 2:09 PM To: [email protected] <mailto:[email protected]> 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:[email protected]> [email protected] <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.onap.org_mailman_listinfo_onap-2Dtsc&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=IKSC5mg8GeOiSar1dax3GQ&m=avgzWIvsa6Z2D_k7RnytojLZMEJEtw5l_0PzGTkUa7g&s=we1_ozleQz6Ux_0jOAjWqap7U8XLsKxwWXy-X9fASPo&e=> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.onap.org_mailman_listinfo_onap-2Dtsc&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=IKSC5mg8GeOiSar1dax3GQ&m=avgzWIvsa6Z2D_k7RnytojLZMEJEtw5l_0PzGTkUa7g&s=we1_ozleQz6Ux_0jOAjWqap7U8XLsKxwWXy-X9fASPo&e= "Confidentiality Warning: This message and any attachments are intended only for the use of the intended recipient(s), are confidential and may be privileged. If you are not the intended recipient, you are hereby notified that any review, re-transmission, conversion to hard copy, copying, circulation or other use of this message and any attachments is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this message and any attachments from your system. Virus Warning: Although the company has taken reasonable precautions to ensure no viruses are present in this email. The company cannot accept responsibility for any loss or damage arising from the use of this email or attachment."
_______________________________________________ ONAP-TSC mailing list [email protected] https://lists.onap.org/mailman/listinfo/onap-tsc
