To clarify, I fully agree to the considerations on having different types of 
physical/virtual/CICI labs. However, not having a strong opinion on whether or 
not to consolidate the different teams. 

 

OPEN-O operated with one lab with Release 1 and added another in Release 2, we 
had separate sub-teams for labs because the tasks and people involved are 
rather different from CI/CD integration team. 

Considering the interest we have so far, ONAP is likely to start with several 
physical labs, and virtual labs in the same time. It might make sense to 
separate it from CI/CD integration.

 

Lingli

 

From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] 
On Behalf Of Lingli
Sent: 2017年5月27日 7:01
To: Chen Yan <chenyan....@chinatelecom.cn>
Cc: xiexj...@chinatelecom.cn; onap-tsc@lists.onap.org
Subject: Re: [onap-tsc] [onap-tsc-private] Lab and Intgeration

 

+1 

Lingli

 

 

China Mobile Research Institute 

On 05/26/2017 23:33,  <mailto:chenyan....@chinatelecom.cn> Chen Yan wrote: 

Dear TSC,

 

>From the above discussions we learned the opinions of the ONAP members on Open 
>Lab. As Xiaojun mentioned, China Telecom would like to provide a physical lab 
>for ONAP. Actually,  in last year, China Telecom has already established a 
>Physical Lab for Open-O mercury release, and finished the E2E connection test 
>for vCPE extension use case.

 

In the near future, a Physical Lab is still important and necessary, especially 
for operators with intention to deploy operational systems to manage not only 
the NFV networks/VNFs but also PNFs.

China Telecom is going to introduce SDN techniques in our Backbone Network, 
e.g. Segment routing and TE. In this case, SDN enabled Physical Network and a 
corresponding Lab is our scope of works.

 

I would suggest to build up multiple labs, including Virtual labs and Physical 
labs, and solving connectivity issues under integration team/LF governance, in 
order to address on different use cases covering most of the operators 
interests.

 

Best Regards

Chen Yan

 

发件人: xiexj...@chinatelecom.cn <mailto:xiexj...@chinatelecom.cn>  
[mailto:xiexj...@chinatelecom.cn] 
发送时间: 2017年5月23日,星期二 09:56
收件人: Deng邓灵莉/Lingli; roberto.k...@orange.com <mailto:roberto.k...@orange.com> ; 
Haiby, Ranny (Nokia - US/San Jose USA); Christopher.Donley; 'Jason Hunt'; MAZIN 
E GILBERT; sunqiong.bri
抄送: tsc-priv...@lists.onap.org <mailto:tsc-priv...@lists.onap.org> ; 
SPATSCHECK, OLIVER \(OLIVER\); 'Yunxia Chen'
主题: Re: Re: [onap-tsc-private] Lab and Intgeration

 

China Telecom also has a lab for OPEN-O. Based on this lab, China Telecom is 
willing to provide a physical lab for ONAP too.

 

Best Regards,

 

Xiaojun 

 

From: Lingli Deng <mailto:denglin...@chinamobile.com> 

Date: 2017-05-23 09:05

To: roberto.k...@orange.com <mailto:roberto.k...@orange.com> ; 'Haiby, Ranny 
\(Nokia - US/San Jose USA\)' <mailto:ranny.ha...@nokia.com> ; 'Christopher 
Donley \(Chris\)' <mailto:christopher.don...@huawei.com> ; 'Jason Hunt' 
<mailto:djh...@us.ibm.com> ; ma...@research.att.com 
<mailto:ma...@research.att.com> 

CC: tsc-private <mailto:tsc-priv...@lists.onap.org> ; spatsch 
<mailto:spat...@research.att.com> ; 'Yunxia Chen' 
<mailto:helen.c...@huawei.com> 

Subject: Re: [onap-tsc-private] Lab and Intgeration

China Mobile is willing to provide a physical lab too, based on the existing 
OPEN-O lab and do enhancement as needed.

 

Lingli

 

From: onap-tsc-private-boun...@lists.onap.org 
<mailto:onap-tsc-private-boun...@lists.onap.org>  
[mailto:onap-tsc-private-boun...@lists.onap.org] On Behalf Of 
roberto.k...@orange.com <mailto:roberto.k...@orange.com> 
Sent: 2017年5月23日 8:28
To: Haiby, Ranny (Nokia - US/San Jose USA) <ranny.ha...@nokia.com 
<mailto:ranny.ha...@nokia.com> >; Christopher Donley (Chris) 
<christopher.don...@huawei.com <mailto:christopher.don...@huawei.com> >; Jason 
Hunt <djh...@us.ibm.com <mailto:djh...@us.ibm.com> >; ma...@research.att.com 
<mailto:ma...@research.att.com> 
Cc: Yunxia Chen <helen.c...@huawei.com <mailto:helen.c...@huawei.com> >; 
tsc-priv...@lists.onap.org <mailto:tsc-priv...@lists.onap.org> ; 
spat...@research.att.com <mailto:spat...@research.att.com> 
Subject: Re: [onap-tsc-private] Lab and Intgeration

 

Orange is willing to provide a physical lab with connectivity from remote, or 
be part of the set up of the virtual lab.

 

I think that what is important is to have clear specification of what is 
required (Open-O experience would help) asap, so that we can start to 
implement. This may be independent from the integration project if it allows us 
to be more efficient. 

 

RK

 

PS: actually, today we have an operation lab that is shared (from our internal 
research, our work with universities to our testing for deployment). So the set 
up would be done marginally. We need to see the tooling of course. 

 

De : onap-tsc-private-boun...@lists.onap.org 
<mailto:onap-tsc-private-boun...@lists.onap.org>  
[mailto:onap-tsc-private-boun...@lists.onap.org] De la part de Haiby, Ranny 
(Nokia - US/San Jose USA)
Envoyé : mardi 23 mai 2017 02:03
À : Christopher Donley (Chris); Jason Hunt; ma...@research.att.com 
<mailto:ma...@research.att.com> 
Cc : tsc-priv...@lists.onap.org <mailto:tsc-priv...@lists.onap.org> ; 
spat...@research.att.com <mailto:spat...@research.att.com> ; Yunxia Chen
Objet : Re: [onap-tsc-private] Lab and Intgeration

 

Chris,

 

You actually bring up an excellent point. In order to demonstrate and test real 
life scenarios we will need to tie in physical equipment. 

 

However, it may not be practical to have all the necessary physical equipment 
in the lab. Therefore a more practical approach could be providing connectivity 
from the lab to physical equipment located on an operator or vendor premise. 
This could be done using some sort of VPN or secure tunnels over the internet. 
Consider the vVoLTE use case. It could be possible to test and demonstrate 
calls between handsets on an operator premise and ECP/IMS in the ONAP lab using 
tunnel connectivity (see attached diagram for a high level concept).

 

So solving the remote equipment connectivity is a requirement for any ONAP lab, 
and once we address this, it does not matter anymore if the lab is physical or 
virtual.

 

I am putting together a draft proposal for a virtual lab, it should be ready 
for discussion later this week.

 

Regards,

 

Ranny.

 

 

From: onap-tsc-private-boun...@lists.onap.org 
<mailto:onap-tsc-private-boun...@lists.onap.org>  
[mailto:onap-tsc-private-boun...@lists.onap.org] On Behalf Of Christopher 
Donley (Chris)
Sent: Monday, May 22, 2017 2:34 PM
To: Jason Hunt <djh...@us.ibm.com <mailto:djh...@us.ibm.com> >; 
ma...@research.att.com <mailto:ma...@research.att.com> 
Cc: Yunxia Chen <helen.c...@huawei.com <mailto:helen.c...@huawei.com> >; 
tsc-priv...@lists.onap.org <mailto:tsc-priv...@lists.onap.org> ; 
spat...@research.att.com <mailto:spat...@research.att.com> 
Subject: Re: [onap-tsc-private] Lab and Intgeration

 

Bringing in Helen.

 

In OPEN-O, we did find it valuable to have physical labs (not just virtual) to 
demonstrate integration with PNFs (not just VNFs).  I think we may want to 
consider the same approach in ONAP. That is, there’s a place for virtual labs 
for our CI/CD environment, but I think we want to extend into physical 
community labs to demonstrate real-world integration and interoperability.

 

Chris

From: onap-tsc-private-boun...@lists.onap.org 
<mailto:onap-tsc-private-boun...@lists.onap.org>  
[mailto:onap-tsc-private-boun...@lists.onap.org] On Behalf Of Jason Hunt
Sent: Monday, May 22, 2017 2:23 PM
To: ma...@research.att.com <mailto:ma...@research.att.com> 
Cc: tsc-priv...@lists.onap.org <mailto:tsc-priv...@lists.onap.org> ; 
spat...@research.att.com <mailto:spat...@research.att.com> 
Subject: Re: [onap-tsc-private] Lab and Intgeration

 

 

I'll be happy to help Ranny, Oliver, and Alla on a virtual lab solution

 

To answer Ranny's question, Softlayer does offer bare metal servers by the hour 
or by the month.  Our telco labs team is currently in the process of installing 
ONAP and OpenStack on those servers and will document the process that they 
used to get it up-and-running.  This would be a good option to give a flexible 
hardware-based lab in addition to a pure virtualized deployment.



Regards,
Jason Hunt
Executive Software Architect, IBM

Phone: +1-314-749-7422
Email: djh...@us.ibm.com <mailto:djh...@us.ibm.com> 
Twitter: @DJHunt

 

 

----- Original message -----
From: "GILBERT, MAZIN E (MAZIN E)" <ma...@research.att.com 
<mailto:ma...@research.att.com> >
Sent by: onap-tsc-private-boun...@lists.onap.org 
<mailto:onap-tsc-private-boun...@lists.onap.org> 
To: "Haiby, Ranny (Nokia - US/San Jose USA)" <ranny.ha...@nokia.com 
<mailto:ranny.ha...@nokia.com> >
Cc: "tsc-priv...@lists.onap.org <mailto:tsc-priv...@lists.onap.org> " 
<tsc-priv...@lists.onap.org <mailto:tsc-priv...@lists.onap.org> >, "SPATSCHECK, 
OLIVER \(OLIVER\)" <spat...@research.att.com <mailto:spat...@research.att.com> >
Subject: Re: [onap-tsc-private] Lab and Intgeration
Date: Mon, May 22, 2017 10:29 AM
 
Thanks.  

 

Alla also offered to help and may be starting that. Can we have few folks work 
together on this. + Oliver. 

Let’s put a project proposal for a virtual lab to be considered and reviewed by 
the TSC.

 

Mazin 



 

  

On May 19, 2017, at 2:14 PM, Haiby, Ranny (Nokia - US/San Jose USA) 
<ranny.ha...@nokia.com <mailto:ranny.ha...@nokia.com> > wrote:

  

Hi,

 

IBM SoftLayer offers bare metal servers as a service, that can address some of 
the concerns. Perhaps Jason can shed some more light on this.

As for cost, my personal experience indicates that on-prem labs seem cheaper 
than cloud services, until you have your first crisis. On-prem labs are not 
free, even if the equipment and real-estate are donated. They still need to be 
operated and that comes with a cost.

 

Anyway, I am willing to work with Helen, Oliver and Catherine who created the  
<https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.onap.org_pages_viewpage.action-3FpageId-3D4718718-26preview-3D_4718718_4719929_Integration-2520Open-2520Labs-25200.7.pdf&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=2dwD7a5k4V9cZl09O7uTpejnZMF8aa01W3yMqrrZC5Y&m=P2Qg_7w2YearDYbQ64Jg3JZGELvHMykpYPHyxVqJJRw&s=_A-h0_M4eW2spzGR9PDCjliae-d-e4qlwJoXruEdoyI&e=>
 original lab proposal to try and work out the details of a virtual lab.

 

Ranny.

 

From: GILBERT, MAZIN E (MAZIN E) [ <mailto:ma...@research.att.com> 
mailto:ma...@research.att.com] 
Sent: Friday, May 19, 2017 10:53 AM
To: Haiby, Ranny (Nokia - US/San Jose USA) < <mailto:ranny.ha...@nokia.com> 
ranny.ha...@nokia.com>
Cc: GOLDNER, ALLA < <mailto:alla.gold...@amdocs.com> alla.gold...@amdocs.com>;  
<mailto:tsc-priv...@lists.onap.org> tsc-priv...@lists.onap.org
Subject: Re: [onap-tsc-private] Lab and Intgeration

 

Ranny,  

 

I am all good with a lab-less approach as this is how we put out ONAP initially 
with RackSpace.

But we need to understand what we are getting ourselves into

and make an assessment quickly. Here are few issues that come to my mind.

 

1. What is the cost of running on 3rd part cloud versus our own lab. Does LF 
have the budget to do 

that in support of the entire community. What cap do we enforce.

2. Will vendors be willing to have their commercial VNFs run on some commercial 
clouds

3. ONAP today runs on open stack. Azure, for example, uses ARM and it is not 
trivial to 

translate heat templates to ARM. We still need to certify ONAP on OPenStack 
solution.

4. Our requirements must match third party cloud requirements. It is not 
trivial 

to run VNFs on some cloud environments neither will they make changes to 
accommodate for your

need.

 

Bottom line, we need like a subcommittee to make an assessment quickly before 
we start 

creating big projects under Integration.

 

Mazin

 

 

On May 19, 2017, at 12:37 PM, Haiby, Ranny (Nokia - US/San Jose USA) < 
<mailto:ranny.ha...@nokia.com> ranny.ha...@nokia.com> wrote:

 

Hi,

 

I would like to suggest an idea of going lab-less for ONAP. (at least 
physical-lab-less). ONAP is a software project, designed for orchestrating 
software network functions and applications. We must be able to avoid 
dependency on any hardware. My practical suggestion is to set up only virtual 
“labs” on some public cloud services such as Azure, SoftLayer, or other, and 
make them available to the community. This way we avoid:

*       Long hardware and real estate lead times as indicated by Mazin.
*       Limited elasticity when there is a need for extra testing capacity 
(E.g. before a release).
*       Susceptibility to downtime due to hardware failure and long RMA process 
of hardware.

 

I am honestly failing to see the benefit of running a physical lab and having 
community members dedicating time to maintaining it. Perhaps I am missing 
something, so if someone would like to enlighten me, please do so.

 

Thanks,

 

Ranny.

 

 

From:  <mailto:onap-tsc-private-boun...@lists.onap.org> 
onap-tsc-private-boun...@lists.onap.org [ 
<mailto:onap-tsc-private-boun...@lists.onap.org> 
mailto:onap-tsc-private-boun...@lists.onap.org] On Behalf Of Alla Goldner
Sent: Friday, May 19, 2017 4:10 AM
To: GILBERT, MAZIN E (MAZIN E) < <mailto:ma...@research.att.com> 
ma...@research.att.com>;  <mailto:tsc-priv...@lists.onap.org> 
tsc-priv...@lists.onap.org
Subject: Re: [onap-tsc-private] Lab and Intgeration

 

Hi Mazin, all,

 

I support the view of separating the Lab from the Integration project for all 
the reasons mentioned below.

 

 

Best regards,

 

Alla Goldner

 

Open Network Division

Amdocs Technology

 

 

<image001.png>

 

From:  <mailto:onap-tsc-private-boun...@lists.onap.org> 
onap-tsc-private-boun...@lists.onap.org [ 
<mailto:onap-tsc-private-boun...@lists.onap.org> 
mailto:onap-tsc-private-boun...@lists.onap.org] On Behalf Of GILBERT, MAZIN E 
(MAZIN E)
Sent: Friday, May 19, 2017 2:05 PM
To:  <mailto:tsc-priv...@lists.onap.org> tsc-priv...@lists.onap.org
Subject: [onap-tsc-private] Lab and Intgeration

 

TSC Members,  

 

I wanted to bring this question to you before sharing our view with the larger 
community.

I would like to get your feedback on separating the Lab from the integration 
project.

Our goal for 4Q release is to have at least 2 labs up and running. One in Asia 
and the 

other in the USA. From my experience at AT&T, the single big factor to delaying 
development, 

testing, certification and deployment is lab availability. This is a major 
undertaking to ensure all hardware, 

software, networking, software versioning, licensing, etc are all ready to go. 
As we mature, 

I expect we will have other labs around the world. These labs can be LF 
operated, other

open source operated or company operated but they meet our requirements, 
vendor/operator neutral and open to

our community. The labs will need to be identical and run multiple VIMs.

 

Given that practically any progress we do depend on the availability of this 
lab, I see that 

it is important that we separate the Lab effort from the Integration effort. 

 

I wanted to get your views on this. Either way, it will be feedback we will 
provide to the 

Integration team. 

 

Mazin

 

 

 

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

you may review at  
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.amdocs.com_about_email-2Ddisclaimer&d=DwMFAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=IKSC5mg8GeOiSar1dax3GQ&m=TV7LQug-8FNgG9lE4dg9ig8VjTRxABlOQONwe9cuJWo&s=GCPsDIptVnMtojpdwjG853pZLnIFcqo3DeMmcghqCBg&e=>
 https://www.amdocs.com/about/email-disclaimer

_______________________________________________
onap-tsc-private mailing list
 <mailto:onap-tsc-priv...@lists.onap.org> onap-tsc-priv...@lists.onap.org
 
<https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.onap.org_mailman_listinfo_onap-2Dtsc-2Dprivate&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=IKSC5mg8GeOiSar1dax3GQ&m=TV7LQug-8FNgG9lE4dg9ig8VjTRxABlOQONwe9cuJWo&s=tffoDrqiSykedE5j4sSyYoSnQI1dDGGNDBr9D36q7zg&e=>
 
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.onap.org_mailman_listinfo_onap-2Dtsc-2Dprivate&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=IKSC5mg8GeOiSar1dax3GQ&m=TV7LQug-8FNgG9lE4dg9ig8VjTRxABlOQONwe9cuJWo&s=tffoDrqiSykedE5j4sSyYoSnQI1dDGGNDBr9D36q7zg&e=

_______________________________________________
onap-tsc-private mailing list
onap-tsc-priv...@lists.onap.org <mailto:onap-tsc-priv...@lists.onap.org> 
https://lists.onap.org/mailman/listinfo/onap-tsc-private

 

 

_________________________________________________________________________________________________________________________
 
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

Reply via email to