Sponsored By
Deploying NFV and working with VNFs demands "some level of automation," according to Fred Oliveira, a Fellow in the Network & Technology Planning Group at Verizon -- and those organizations that fall behind in the technological demands of optimized NFV models and NFV automation will see less value from their efforts.
Previously, in part one of this two-part Q&A -- lightly edited for length and clarity -- Oliveira covered the relationship Verizon Communications Inc. (NYSE: VZ) has with NFV standards bodies and open source communities, the role of standards and open source in NFV development and the relationship between orchestrators and VNF managers. (See Verizon's Oliveira: NFV Needs Orchestration, Openness .)
Here in part two, Oliveira -- a keynote speaker at today's Light Reading's NFV and Carrier SDN event -- ties all of the previous elements up in the context of NFV automation.
Telco Transformation: At what point is an NFV model fairly criticized for merely replacing the proprietary physical appliance for no particular reason? When should you use NFV, and when is it not necessarily needed?
Fred Oliveira: I think Verizon's goal is basically to transition to NFV to enable flexibility and agility around deploying applications. But we're taking a very pragmatic approach to that. And we're only deploying virtualized applications in cases where there are performance problems or capacity problems that we have, or there's a particular PNF [physical network function] already deployed that is going end of life, or there's some potentially new greenfield opportunity that would enable some new service.
We don't have any specific targets that will be all VNFs by some particular date. We're taking it very pragmatically, by asking: When does it make sense to transition to a virtual cloud environment, when is it economical and what would the flexibility of a virtual environment enable?
TT: Are there are any particular classic use cases for NFV that you see frequently come up?
FO: It's pretty general. We see our services constantly increasing. And so one of the areas we see as valuable is being able to take incremental traffic and send it to a virtualized instance of some service. We see this in several services. What we'll do is we'll enable several of those services to be enabled in a virtualized form and then take the traffic from a physical environment and segment some of that traffic into a virtual instance.
TT: What is the connection that you see between NFV and automation?
FO: I think in order to get automation in an environment we need to have a level of orchestration -- both at the virtual level and the physical level. So I think it's all driven from the orchestration environment.
TT: What have been the challenges in the orchestration environment thus far to get to that automation utopia?
FO: I think there are several. So, in some kind of order: I think lack of standards is one area. The proprietary nature of the current orchestrator limits some of the functionality and limits the ability of VNF vendors themselves to provide some of the functionality that they need to supply for our networks.
Other challenges are the interface environments. The NFV MANO organization at ETSI is working on a standard for interfaces between the orchestrator and all of the VNF managers and the VNF itself. Those interfaces are currently in their infancy, and so there is lack of compliance with those standards. It becomes difficult for one vendor to provide a component that will work with another component in this context. It really is an orchestrator with a VNF manager.
Then the third level of things are the tools for designing your outfacing services. Some combination of NFV or VNFs and physical network functions is not there yet. It takes a significant effort by Verizon and our vendors to design a service that includes all the multiple VNFs for multiple units.
TT: It sounds like the common theme that keeps coming up in our ongoing conversation is that of clearing this pathway and making this communication between the orchestrators and the VNF managers more clear and more efficient.
FO: I'd agree with that. And I think we need it to be complete, clear, and standardized so that the multiple vendors can both produce it and consume it correctly.
TT: Which types of VNFs are people and organizations struggling with the most right now when it comes to some of these orchestration challenges?
FO: So I think that there is a broad range. Certainly almost all of these applications, certainly in the SD-WAN space, were initially meant to be deployed through a manual deployment effort. Once you try to scale that it becomes inordinately difficult without some level of automation. That automation has to be driven by, in this case, a standardized orchestration interface. But we also have challenges on many of our other network applications -- both wireline and wireless applications. We have covered all those environments within our orchestration environment and none of them have well defined interfaces that allow us to automate them easily.
TT: So I have a chicken-and-egg sort of question for you: In talking about all of the obstacles for NFV automation, something that frequently comes up is culture and people's fear of being replaced. But then you have all of these orchestration challenges. Do the orchestration challenges just add to this so that the cultural considerations are just noise? Or do the cultural obstacles and FUD surrounding automation in turn lead to this orchestration laissez-faire attitude?
FO: I'd say that there are issues in all of these areas. We have to adapt our organization within Verizon to enable automation. I think as you mentioned, people are concerned that their jobs are going to be affected by this. We think that there are many new services and that people can be trained to operate on these new services and new areas. I think that's kind of a false worry.
But I think that, by enabling automation, we are enabling the operations teams and the service assurance teams to be more aware at a higher level and to let the automation actually deal with the day-to-day trivial problems while the humans are involved in some of the more difficult challenges that require significant knowledge and innovation.
TT: What would it take to get NFV and NFV-driven automation to the place where we could have a truly intelligent self-organized network [SON] where it's little to no human touch at all?
FO: That's a challenging ask. I think there are many things that would be required. So our approach is to do this incrementally and to start automating here the simple aspects of the environment and then slowly integrate the different service-assurance tools and the different interfaces that are becoming available such that we can automate more and more between all of these tools.
I think that it won't be a quick transition to this nirvana of full automation, but I think we see there is opportunity for doing this and significant value in automating some of these tasks and then learning what works, what doesn't, and adapting our framework and our tools to behave better.
— Joe Stanganelli, Contributing Writer, Telco Transformation
