Re: [onap-tsc] Usage of commercial VNF and NFVI+VIM solutions for ONAP R1 use cases, and open lab

[Lingli Deng]

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 ; SULLIVAN, BRYAN L 
; 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 
  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) < 
 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:   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 

Re: [onap-tsc] Usage of commercial VNF and NFVI+VIM solutions for ONAP R1 use cases, and open lab

[Christopher Donley (Chris)]

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

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

Re: [onap-tsc] Usage of commercial VNF and NFVI+VIM solutions for ONAP R1 use cases, and open lab

[ROSE, DANIEL V]

Gil,


From vendor side:
There is some talk here: https://wiki.onap.org/display/DW/Lab+Resource
However most of the stuff written so far has been about physical labs. If you 
are interested more in virtual labs, theres not so much written but there is an 
understanding we may need a virtual lab (ie hardware not owned by us) at some 
point.
Integration project welcomes feedback about that.

From code support side:
https://wiki.onap.org/pages/viewpage.action?pageId=3247262 has vim support that 
being discussed



Hope that helps,
Daniel Rose
ECOMP / ONAP
com.att.ecomp
732-420-7308

From: Hellmann, Gil [mailto:gil.hellm...@windriver.com]
Sent: Friday, June 02, 2017 10:06 AM
To: ROSE, DANIEL V ; GILBERT, MAZIN E ; 
Dhananjay Pavgi ; 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

Hi Daniel,

Do we have a place where we can review the list of requirements ONAP need 
commercial VIM/Cloud vendors to comply with and by when in order to allow them 
to be part of release 1?

I am confident that there are commercial VIM/Cloud vendors which will be happy 
to review them and work toward providing support for release 1.

Best regards,
Gil Hellmann

From: "ROSE, DANIEL V" >
Date: Friday, June 2, 2017 at 9:52 AM
To: Gil Hellmann 
>, "GILBERT, 
MAZIN E" >, Dhananjay 
Pavgi >, 
"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

https://wiki.onap.org/pages/viewpage.action?pageId=3247262
 mentions org.onap.multicloud/openstack, org.onap.multicloud/vmware, 
org.onap.multicloud/azure as output so I don’t think commercial vims are out of 
scope. I don’t even think there is a fundamental intolerance to commercial vims 
even in release 1 but like mazin said a release 1 commercial vim may not happen 
if we don’t get everything we need both on the code side to support it and 
vendor side to enable it.


Thanks,
Daniel Rose
ECOMP / ONAP
com.att.ecomp
732-420-7308

From: onap-tsc-boun...@lists.onap.org 
[mailto:onap-tsc-boun...@lists.onap.org] On Behalf Of Hellmann, Gil
Sent: Friday, June 02, 2017 8:10 AM
To: GILBERT, MAZIN E >; 
Dhananjay Pavgi 
>; 
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

Hi Mazin,

Thanks for the replay. All the points and requirements in your replay below 
make a lot of sense, and should address the use of commercial VNFs in R1, but 
what about the use of commercial infrastructure (NFVI+VIM) as part of R1? The 
VNFs need to run on an infrastructure?

I see that the same rules should be applied to the usage of commercial 
infrastructure. What is the TSC thinking about this?

Best regards,
Gil Hellmann

From: "GILBERT, MAZIN E (MAZIN E)" 
>
Date: Friday, June 2, 2017 at 7:50 AM
To: Dhananjay Pavgi 
>, 
"onap-tsc@lists.onap.org" 
>
Cc: Rajesh Gadiyar >, 
Gil Hellmann >
Subject: Re: [onap-tsc] Usage of commercial VNF and NFVI+VIM solutions for ONAP 
R1 use cases, and open lab

Gil,

Thanks for the kind words regarding the ONAP community.
Let me make sure I respond to your question and put this subject to rest
as it was discussed numerous times by the TSC.

1. Our first integrated release (ONAP seeded by ECOMP and Open-O) will be the 
first week of Nov.
This is our goal and the TSC community is committed to this.
2. Two broad sets of services have been identified for vetting the integrated 
release; vEPC/VoLTE and vCPE
3. Each broad use case will have options of open source VNFs and several 
commercial VNFs.
4. It is our desire to use commercial VNFs if we can make our release date; 
otherwise we will revert to Open Source. This means
a. licenses are available in time that is aligned with our release planning,
b. VNFs can be stood up in 

Re: [onap-tsc] Usage of commercial VNF and NFVI+VIM solutions for ONAP R1 use cases, and open lab

[GILBERT, MAZIN E (MAZIN E)]

Gil,

Thanks for the kind words regarding the ONAP community.
Let me make sure I respond to your question and put this subject to rest
as it was discussed numerous times by the TSC.

1. Our first integrated release (ONAP seeded by ECOMP and Open-O) will be the 
first week of Nov.
This is our goal and the TSC community is committed to this.
2. Two broad sets of services have been identified for vetting the integrated 
release; vEPC/VoLTE and vCPE
3. Each broad use case will have options of open source VNFs and several 
commercial VNFs.
4. It is our desire to use commercial VNFs if we can make our release date; 
otherwise we will revert to Open Source. This means
a. licenses are available in time that is aligned with our release planning,
b. VNFs can be stood up in the ONAP OpenLabs in time that align with our 
release.
c. Developers get complete support during testing, dev and certification
d. VNF vendors are willing to further extend their VNFs to meet our ONAP VNF 
requirements for R1.

I encourage VNF vendors who are interested in meeting those guidelines to sign 
up on our wiki asap.

The TSC is excited about the first release and look forward to working with the 
entire community to
make this a huge success.

Thanks
mazin



On Jun 2, 2017, at 12:27 AM, Dhananjay Pavgi 
> wrote:

+1. For lab having commercial ecosystem of VNFs; we may consider Tech 
Mahindra’s VNFXchange lab.

thanks & regards,
Dhananjay Pavgi
Mobile : +91 98220 22264
   
www.techmahindra.com
 Platinum Member. Visit : 
http://www.onap.org

From: onap-tsc-boun...@lists.onap.org 
[mailto:onap-tsc-boun...@lists.onap.org] On Behalf Of Gadiyar, Rajesh
Sent: Friday, June 02, 2017 2:48 AM
To: Hellmann, Gil (Wind River) 
>; 
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

+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: > 
on behalf of Gil Hellmann 
>
Date: Thursday, June 1, 2017 at 2:08 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 

Re: [onap-tsc] Usage of commercial VNF and NFVI+VIM solutions for ONAP R1 use cases, and open lab

[Dhananjay Pavgi]

+1. For lab having commercial ecosystem of VNFs; we may consider Tech 
Mahindra’s VNFXchange lab.

thanks & regards,
Dhananjay Pavgi
Mobile : +91 98220 22264
[cid:image002.png@01CE7323.F2727500]   [ONAP_logo_Sig]
www.techmahindra.com Platinum 
Member. Visit : http://www.onap.org

From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] 
On Behalf Of Gadiyar, Rajesh
Sent: Friday, June 02, 2017 2:48 AM
To: Hellmann, Gil (Wind River) ; 
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

+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: > 
on behalf of Gil Hellmann 
>
Date: Thursday, June 1, 2017 at 2:08 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:image009.png@01D2DB86.AE5C4970]
 [cid:image010.png@01D2DB86.AE5C4970] 
  
[cid:image011.png@01D2DB86.AE5C4970] 
  
[cid:image012.png@01D2DB86.AE5C4970] 
  
[cid:image013.png@01D2DB86.AE5C4970] 


[cid:image014.gif@01D2DB86.AE5C4970]
“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


Disclaimer:  This message and the information contained herein is proprietary 
and confidential and subject to the Tech Mahindra policy statement, you may 
review the policy at http://www.techmahindra.com/Disclaimer.html 
 externally 
http://tim.techmahindra.com/tim/disclaimer.html 
 internally within 
TechMahindra.


___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc

Re: [onap-tsc] Usage of commercial VNF and NFVI+VIM solutions for ONAP R1 use cases, and open lab

[SULLIVAN, BRYAN L]

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

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@01D2DAF7.CCB53290]
 [cid:image002.png@01D2DAF7.CCB53290] 

  [cid:image003.png@01D2DAF7.CCB53290] 

  [cid:image004.png@01D2DAF7.CCB53290] 

  [cid:image005.png@01D2DAF7.CCB53290] 

Re: [onap-tsc] Usage of commercial VNF and NFVI+VIM solutions for ONAP R1 use cases, and open lab

[Gadiyar, Rajesh]

+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:  on behalf of Gil Hellmann 

Date: Thursday, June 1, 2017 at 2:08 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@01D2DAE1.D4307D10]
 [cid:image002.png@01D2DAE1.D4307D10] 
  
[cid:image003.png@01D2DAE1.D4307D10] 
  
[cid:image004.png@01D2DAE1.D4307D10] 
  
[cid:image005.png@01D2DAE1.D4307D10] 


[cid:image006.gif@01D2DAE1.D4307D10]
“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