Verizon's Oliveira: NFV Needs Orchestration, Openness

Many of the challenges and problems facing NFV innovation and deployment fundamentally come down to the orchestration layer, according to Fred Oliveira, a Fellow in Verizon's Network & Technology Planning Group for both wireline and wireless technologies.

Oliveira is representing Verizon this week as a featured speaker at Light Reading's NFV and Carrier SDN event, so Telco Transformation reached out to him to get his take on the most pressing NFV issues.

In part one of this two-part Q&A, which was lightly edited, Oliveira provided a preview of what he expects to both present about and learn about at Light Reading's NFV and Carrier SDN event. He talks about the orchestration challenges of NFV, and the roles of open standards and open source communities in solving these NFV challenges.

In part two, look for Oliveira to bring this all together to address the hopes and challenges surrounding NFV and VNF automation.

Telco Transformation: What are you planning on covering in your presentation at the NFV and Carrier SDN event?

Fred Oliveira: I'm actually looking at the challenges involved with NFV orchestration and a potential solution.

TT: What are you hoping to get out of the NFV and Carrier SDN event in Denver? Is there anything in particular you and your colleagues are looking for?

FO: My goal is basically to get a better view of what other operators and other vendors are developing and presenting in this space, and see if I can get a better feel for where the industry is going in general, and which areas that Verizon should be looking at further to leverage some of the capabilities that we are working on in the industry.

TT: What are some of Verizon's current projects in regards to the challenges of NFV orchestration?

FO: We have several projects going on in the orchestration space. We have worked with our orchestration vendors on a set of interface requirements. We have asked all of our orchestration and VNF manager vendors to comply with the ETSI standard. There's a specific ETSI standard called SOL 003, and that's an interface between the orchestrator and the VNF manager. So we're working with the vendors and our various standards organizations to enhance the standards, and then validating that those actual operations help us automate some of these tasks.

We're also looking at some of the open source tools. We are monitoring both the [Linux Foundation] ONAP projects and [ETSI] OSM projects to find out when they would be usable in our network both in terms of capabilities and reliability, and enhancing some of the open source work that is going on.

In the VNF world itself, we're working with our vendors to potentially architect their VNFs to be more cloud native. Most of the early VNFs we have deployed are using direct ports off of their hardware environment. We're not, I'll say, "cloud-friendly," but we're working with our VNF vendors to adapt and re-architect our VNFs to be much more cloud-friendly.

TT: What are these "cloud-hostile" factors that you are working to get rid of? What do you see in your partners and clients in regards to their own cloud-hostile factors in their VNF architectures or orchestrations?

FO: I think that one of the biggest issues we see would be the networks' lack of ability to dynamically scale and heal themselves because of the way they were developed on their hardware environment. They were limited to operating within the specific hardware that they were deployed on.

Now in a cloud environment we actually have, potentially, a very dynamic execution environment -- and the scaling out of the processing as a load from a particular service increases is possible, and it will work. We've managed to do that. Conversely, when the traffic on a particular service decreases we can scale those services back down to consume less cloud resources, which we can then allocate to a different service.

TT: You mentioned ETSI earlier. Did Verizon have a presence at the NFV Plenary Meeting that they had earlier this month in Denver? (See ETSI's Triay on NFV Plugtests, Spec-Fests, Tutorials.)

FO: Yes. We actually had a presence. I think there were at least two people there. We are actively members and we actively contribute to various committees. One of our key points right now is to work with a group called IFA -- the Interfaces and Architecture Working Group -- particularly to enhance the information model so that we can describe all of the functionality we want to process within the VNF descriptor and the network-services descriptor. So basically just to get all of the information into the various descriptors that would come along with a VNF or with a network service such that we can implement the functionality that we want in the VNF. The existing information in the current implementation is a little bit lacking.

TT: How so?

FO: Some of these are details, in a sense. There is no consistent way to ask parameters between the orchestrator and the VNF manager that would describe how the VNFs should behave. There is kind of a lack of a way to specify the behavior on a specific lifecycle event. Those are critical items that we're trying to address.

TT: What other standards issues are you working on? What is fundamentally missing in NFV standards, with whom are you working on these issues and what is the goal so that we don't have 15 competing standards?

FO: I think one of the questions we have is: How many of the new standards will be developed in existing standards organizations versus the creation of de facto standards that were created in the open source world? We're seeing lots more rapid development of standards, standards tools and standards frameworks being done in the open source world. What we're trying to understand is whether these open source developments replace some of the standards organizations. We don't have any preconceived notion about when, or whether, that will happen or not, but that's one of the things that we're following.

In that same vein, one of the things that seems to be happening quickly is the move from monolithic virtual machines to deployment of containers. We're working with several of our vendors and some of the open source groups to understand whether there's a standard stack that could be deployed to support this container framework so that we don't have several different container frameworks that our vendors are using. We need a common container environment to deploy these new applications that are being re-architected in containers.

— Joe Stanganelli, Contributing Writer, Telco Transformation