ADVA Ensemble team members participated in the first ETSI NFV Plugtests™ event sponsored by Telefonica in Madrid earlier this year. More than that – they and the Ensemble MANO and VIM products excelled. Why? A big part of the reason is experience – not just that of ADVA, but of all of the participants.

The ETSI report is available online, and a picture of the participants is shown below.

I wanted to get some additional insight. My colleagues Irv Stetter and Brian Callanan were two of the ADVA engineers involved in the event. Irv attended the test sessions in person, and Brian was providing support from the ADVA office in Westford, Massachusetts. I chatted with each of them to get some of their insights.

Experience Improves Products

Irv also attended the Light Reading interop event in May 2016 at BCE, so he has firsthand experience with how far ADVA and the rest of the industry have advanced since that time. “Last year at BCE, we wanted to use our MANO with other VIMs, but most of them were not ready to be integrated with third-party orchestrators. At the Spain event, we were able to make that work.”

I asked Irv to expand a bit on how we accomplished that integration. He laughed and said, “When I got on the plane on Saturday we had no interoperability. Brian worked over the weekend to get this to work. To do that, he had to convince some of the VIM suppliers to open up their interfaces to enable support for third-party orchestration. We managed to get through the testing and gained valuable knowledge that we can apply to making the Ensemble solution better in future releases.”

Openness Needed

Irv’s comment about the other VIMs piqued my curiosity. What changes were needed to enable our orchestration to access those VIMs? Brian told me, “While standards are emerging, some suppliers have locked down their cloud implementations and prevented orchestration access to some key OpenStack features. For example, many VNF Providers have started to standardize VNF initialization using the OpenStack Metadata Service and CloudInit, which is based on the EC2 standard. However, in cases where VNFs do not support CloudInit, we felt it necessary to support other programmatic VNF configuration mechanisms. In this way, we can provide a truly VNF-agnostic orchestration platform. We had to work with the VIMs supplier to enable this. That cooperation was very much appreciated.”

Lessons Learned

I wondered about what lessons we learned in the testing. Irv told me, “We didn’t bring any equipment, so all testing was done over the internet using a VPN. At times, the connection was slow and flaky. I would never do that again!” He also highlighted that “Brian was making required improvements on the fly,” underscoring the need for developer support during events like this.

Brian also had some thoughts on why we were successful, and why the integration and testing went quickly: “We’ve been at this for three years and have seen everything. Our product is mature, and we have a set of features for just about every use case. Our list of tools is extensive. Our ability to import and export VNF descriptors and service descriptors is powerful. Our orchestration platform enables rapid development of new services, including remote development as a professional service. We were able to get a lot of testing done, and we anticipate even more breadth of tests as the whole industry matures.”

Moving Forward

Events like this Plugtest show how far we have come, along with the work we still have to do. In particular, the success of this event depended on the skills and energy of the participants. Brian observed, “I was talking to somebody who said that OpenStack and MANO were too complex. To address that argument, we support the full capabilities of OpenStack, and we simplify and abstract away the complexity.” That’s the type of simplification that will be needed to make NFV truly successful and interoperable.