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 forONAP R1 use cases, and open lab

[Adityakar.Jha]

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) 
[ma...@research.att.com]
Sent: 2 June 2017 at 8:57:15 AM
To: yuan@zte.com.cn
CC: sulli...@mail.linuxfoundation.org, gil.hellm...@windriver.com, SULLIVAN, 
BRYAN L, onap-tsc@lists.onap.org
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, yuan@zte.com.cn 
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 Center II, No.50, Software Avenue,YuHua 
District,Nanjing,P.R.China 210012
T: +025 88013478
M: +86 13851446442
E: yuan@zte.com.cn
www.zte.com.cn
原始邮件
发件人： ＜bs3...@att.com＞;
收件人：＜gil.hellm...@windriver.com＞;＜onap-tsc@lists.onap.org＞;
日 期 ：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

From: onap-tsc-boun...@lists.onap.org 
[mailto:onap-tsc-boun...@lists.onap.org] On Behalf Of 

[onap-tsc] Use case subcommittee

[Alla Goldner]

Hi all,

Yesterday we approved creation of Use case subcommittee.
I propose to have bi-weekly conference calls, starting after next week’s f2f 
meeting.

I will ask Linux Foundation to send out invitation and create wiki page for 
this subcommittee.

Best regards,

Alla Goldner

Open Network Division
Amdocs Technology


[cid:image001.png@01D2DB6E.5290]
This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,

you may review at https://www.amdocs.com/about/email-disclaimer 

___
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 forONAP R1 use cases, and open lab

[GILBERT, MAZIN E (MAZIN E)]

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, yuan@zte.com.cn 
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 Center II, No.50, Software Avenue,YuHua 
District,Nanjing,P.R.China 210012
T: +025 88013478
M: +86 13851446442
E: yuan@zte.com.cn
www.zte.com.cn
原始邮件
发件人： ＜bs3...@att.com＞;
收件人：＜gil.hellm...@windriver.com＞;＜onap-tsc@lists.onap.org＞;
日 期 ：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

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 

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

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

[Hellmann, Gil]

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@01D2DAF9.B49018E0]
 [cid:image002.png@01D2DAF9.B49018E0] 
  
[cid:image003.png@01D2DAF9.B49018E0] 
  
[cid:image004.png@01D2DAF9.B49018E0] 
  
[cid:image005.png@01D2DAF9.B49018E0] 


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

[onap-tsc] Community Meetings

[Casey Cain]

The ONAP Community now has 8 Zoom licences available.
If you are hosting a community meeting, please allow me to migrate the
meeting to these community accounts.
If you can, please forward me the Meeting Time and recurrence schedule (if
there is one), Meeting Title, and a list of participants OR the mailing
list that you would like the meeting invite to be sent to.

I will also add the meeting to the meeting to the Community Meetings
 wiki page and the ONAP Meetings & Events
public Google Calendar

which
also syncs with the Confluence Calendar

for
those who have trouble accessing Google services.

Best,

Casey Cain
Technical Program Manager
Linux Foundation
_
IRC - CaseyODL
Skype - wrathwolfk
WeChat - okaru6
___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc

Re: [onap-tsc] Call for vCPE VNFs proposals

[ROSE, DANIEL V]

Viability to even be included is certainly an important point.

But I think oliver’s point is there is always some work to get a vnf to be onap 
ready, and then some more work to configure it to work in our use case. Someone 
in the ONAP project has to take ownership and agree to either do that work, or 
find someone (possibly the projects actual contributors) to do that work.  This 
is analogous to a vendor who agrees to support their vnf in the use cases we 
use them for.

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

From: onap-discuss-boun...@lists.onap.org 
[mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of SULLIVAN, BRYAN L
Sent: Thursday, June 01, 2017 10:31 AM
To: SPATSCHECK, OLIVER ; Zhou, Danny 

Cc: onap-discuss ; onap-tsc@lists.onap.org
Subject: Re: [onap-discuss] [onap-tsc] Call for vCPE VNFs proposals

***Security Advisory: This Message Originated Outside of AT ***
Reference http://cso.att.com/EmailSecurity/IDSP.html for more information.
Having support info in the table of open source VNFs, as well as notes on 
functional limitations / fitness for a particular purpose, and some consensus 
assessment [limited, viable] or status [experimental, lab-ready, deployed] that 
can change over time, would be useful. There are various types/levels of 
purpose here, and for the community’s need, functionally complete / 
production-ready open source VNFs while clearly a desired goal, are a 
would-be-nice.

Viability would include the level of community support for maintaining or 
further developing the VNF. But some VNFs may be still be viable for particular 
purposes (e.g. in tests for performance or lifecycle automation) even if they 
are incomplete or there is no active community.

Thanks,
Bryan Sullivan | AT

From: SPATSCHECK, OLIVER
Sent: Thursday, June 01, 2017 6:07 AM
To: Zhou, Danny >
Cc: SULLIVAN, BRYAN L >; KLUGER, YOAV 
>; 
onap-tsc@lists.onap.org; onap-discuss 
>
Subject: Re: [onap-tsc] Call for vCPE VNFs proposals


Could we also start listing who is supporting the open source VNFs? E.g. even 
the simple open source based VNFs we are using for the current ONAP demo  based 
on the seed code took a couple of people 2 months or so to get to work properly 
in the integration environment. I would assume that for commercial VNFs this 
support will be provided by the vendor. However, for open source VNFs we need 
volunteers to take on that role. I would track those on the Wiki or identify 
them as gaps. If we can’t find that support we can’t use that VNF.

Thx

Oliver

On May 31, 2017, at 11:36 PM, Zhou, Danny 
> wrote:

The wiki 
page
 already lists preferred and usable open source VNFs like below, but the ONOS 
vBNG as open source vBNG and OpenWRT as open source vHGW does not make sense to 
me. Specifically, the ONOS vBNG is essentially a L3 NAT without the 
capabilities to address requirement such as session management, traffic 
aggregation and routing, etc., and in addition to OpenWRT acting as vHGW, VPP 
based high performance Home 
Gateway
 as well 
asvRouter
 should be better.

  *   vDHCP: ISC DHCP
  *   vDNS:   ISC Bind
  *   vAAA:   FreeRADIUS

-Danny Zhou
Intel

From: onap-tsc-boun...@lists.onap.org 
[mailto:onap-tsc-boun...@lists.onap.org] On Behalf Of SULLIVAN, BRYAN L
Sent: Thursday, June 1, 2017 3:36 AM
To: KLUGER, YOAV >; 
onap-tsc@lists.onap.org; onap-discuss 
>
Subject: Re: [onap-tsc] Call for vCPE VNFs proposals

I recommend that any available open source implementations of these VNFs also 
be included. I am aware of several potential VNFs as used in the R-CORD 
project, and as being collected through the similar ODL VCO 

[onap-tsc] tsc merting

[roberto.kung]

dear all, i will not be able to attend the tsc today. But jamil will attend for 
me, with eric and vincent. Roberto

_

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.

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

Re: [onap-tsc] Call for vCPE VNFs proposals

[SPATSCHECK, OLIVER (OLIVER)]

Could we also start listing who is supporting the open source VNFs? E.g. even 
the simple open source based VNFs we are using for the current ONAP demo  based 
on the seed code took a couple of people 2 months or so to get to work properly 
in the integration environment. I would assume that for commercial VNFs this 
support will be provided by the vendor. However, for open source VNFs we need 
volunteers to take on that role. I would track those on the Wiki or identify 
them as gaps. If we can’t find that support we can’t use that VNF.

Thx

Oliver

On May 31, 2017, at 11:36 PM, Zhou, Danny 
> wrote:

The wiki 
page
 already lists preferred and usable open source VNFs like below, but the ONOS 
vBNG as open source vBNG and OpenWRT as open source vHGW does not make sense to 
me. Specifically, the ONOS vBNG is essentially a L3 NAT without the 
capabilities to address requirement such as session management, traffic 
aggregation and routing, etc., and in addition to OpenWRT acting as vHGW, VPP 
based high performance Home 
Gateway
 as well 
asvRouter
 should be better.

  *   vDHCP: ISC DHCP
  *   vDNS:   ISC Bind
  *   vAAA:   FreeRADIUS


-Danny Zhou
Intel

From: onap-tsc-boun...@lists.onap.org 
[mailto:onap-tsc-boun...@lists.onap.org] On Behalf Of SULLIVAN, BRYAN L
Sent: Thursday, June 1, 2017 3:36 AM
To: KLUGER, YOAV >; 
onap-tsc@lists.onap.org; onap-discuss 
>
Subject: Re: [onap-tsc] Call for vCPE VNFs proposals

I recommend that any available open source implementations of these VNFs also 
be included. I am aware of several potential VNFs as used in the R-CORD 
project, and as being collected through the similar ODL VCO (Virtualized 
Central Office) project. These are being collected and assessed for deployment 
on OPNFV reference platforms as part of the proposed “Edge” project: 
https://wiki.opnfv.org/display/PROJ/Multi-Access+Edge
 intended to expand reference VNF options for edge-focused service deployments 
such as residential broadband. As a part of this project we will also be 
building reference blueprints (TOSCA based) for these VNFs and orchestrating 
them using ONAP components as well as other projects we are currently using for 
this in OPNFV (Cloudify, and OpenStack Tacker).

OPNFV is acquiring the necessary hardware (e.g. OLT devices) to have a 
fully-functional edge-focused lab environment in which to complete this 
integration. I’ll add the related info to the ONAP wiki as the usability of the 
open source VNFs becomes clear.

Thanks,
Bryan Sullivan | AT

From: 
onap-discuss-boun...@lists.onap.org 
[mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of KLUGER, YOAV
Sent: Wednesday, May 31, 2017 12:23 PM
To: onap-tsc@lists.onap.org; onap-discuss 
>
Subject: [onap-discuss] Call for vCPE VNFs proposals

Dear ONAP community,

As we all know, the Residential Broadband vCPE use case is one of our two 
targeted use cases for R1.
Its wiki 
page
 has been significantly enriched recently, and more details are added on a 
daily basis.
A general residential broadband solution can be much more complex than what 
would be reasonably achievable by R1. We have narrowed down the description of 
the use case for R1, to something that should be both achievable and usable.
For the use case to 

[onap-tsc] Common Frameworks - Project Proposal

[Liron Shtraichman]

Hello Committee Members,

I would like to submit the following project proposal: 
https://wiki.onap.org/display/DW/Common+Frameworks?src=contextnavpagetreemode
This project is a consolidation of several other common projects that were 
already introduced to this committee


Thanx,

Liron




This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,

you may review at https://www.amdocs.com/about/email-disclaimer 

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