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 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. 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 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. 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. 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 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: [email protected]
Twitter: @DJHunt
----- Original message -----
From: "GILBERT, MAZIN E (MAZIN E)" <[email protected]>
Sent by: [email protected]
To: "Haiby, Ranny (Nokia - US/San Jose USA)" <[email protected]>
Cc: "[email protected]" <[email protected]>, "SPATSCHECK, OLIVER \(OLIVER\)" <[email protected]>
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) <[email protected]> wrote: 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 original lab proposal to try and work out the details of a virtual lab. 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 Bottom line, we need like a subcommittee to make an assessment quickly before we start creating big projects under Integration. On May 19, 2017, at 12:37 PM, Haiby, Ranny (Nokia - US/San Jose USA) <[email protected]> wrote: 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. I support the view of separating the Lab from the Integration project for all the reasons mentioned below. 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 This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement,
_________________________________________________________________________________________________________________________ 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.
|
