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
南京市雨花区软件大道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]
www.zte.com.cn
原始邮件
发件人： ＜[email protected]＞
收件人： ＜[email protected]＞ ＜[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]]
On Behalf Of Hellmann, Gil
Sent: Thursday, June 01, 2017 2:09 PM
To: [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
“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
[email protected]
https://lists.onap.org/mailman/listinfo/onap-tsc
