Sponsored By
NFV initiatives shouldn't be rushed, suggests Joan Triay, technical manager and NFV Technical Steering Committee Chair at the European Telecommunications Standards Institute (ETSI). Instead, NFV best practices demand first a fundamental understanding of all of the capabilities and possibilities of the different layers and business processes, including automation.
In part one of this Q&A, Triay gave an overview of current and upcoming activities at European Telecommunications Standards Institute (ETSI) , along with some insight on NFV security and compliance. (See ETSI's Triay on NFV Plugtests, Spec-Fests, Tutorials.) Now, in part two, Triay talks about the inherent connection between NFV and automation, and the keys to proper NFV implementation while also defending the ETSI model.
Telco Transformation: How are you seeing NFV being leveraged today for automation? Why might this be important?
Joan Triay: I would say automation is in the DNA of NFV, and NFV is also in the DNA of automation. They need to go together. One is a good example of the other. As we envision from an ETSI NFV perspective, the way that we deal with NFV is fully taking into account how to ensure that we can automate all different tasks and how we can at the same time orchestrate all of the processes when we need to mix and match all the different tasks. NFV there plays a big role because orchestration is a good enabler for automating different tasks for the operator. At the same time, it's also a very good enabler for, when we understand the different tasks that need to be performed, understanding how to also orchestrate them.
Maybe in the past, it has not been very clear from an NFV perspective, but this is something that we now are reinforcing our message with: We deliver those tools that enable the automation and the orchestration to the operator and to the providers.
Automation can happen at many different layers and many different processes. The scope that we have always taken so far in NFV is more on providing all the tools for this automation and orchestration from the platform perspective and the virtualization perspective. Obviously, there are automations and business processes, and so the languages are also very important, but NFV has not dealt with those because we narrowed the scope to try to provide the platform to enable all of the deployment of virtualized network functions. On top of that, there are many other possibilities of automating many other tasks for end-to-end service delivery.
TT: To speak of the virtual functions, versus, say, physical functions, a lot of contemporary, functional-model NFV solutions have sometimes been criticized as not going very far -- "basically replacing a physical appliance with a general-purpose computer and some software instances." (See Analyst Nolle: Fundamental Errors Plague NFV.) What are your thoughts on that critique?
JT: I will say, practically speaking, the market and the first solutions that we saw clearly moved from the more physical appliances to the virtual appliances without changing that many concepts in the design of the function itself. But one thing that we did from the NFV perspective is that we provided that model that was flexible enough to actually encompass any kind of new ways to create functions. One good example is that, on interfaces, sometimes we don't really consider virtual machines [in the context of a specific] technology -- for example, containers. I speak to all our architects about containers. Whatever type of container it is, a VM could be a container. So we made a decision at that point that we didn't want to limit the interfaces that we were doing on the framework itself to any particular implementation of a virtualized function. A very good example is that now we are running a couple of work items as well in the ETSI NFV -- through which we have actually tried to go and move these concepts forward with the concepts of cloud-native VNFs and DAS (direct-attached storage) functionalities. We are basically trying to formalize it even more that the framework that we provide is a good opportunity for us to also provide deployment for these new, radical ways to create functions.
TT: For an organization that is beginning with or reevaluating its NFV efforts, how do you make sure you do NFV right?
JT: It's a good question. I guess the answer depends on; out of the different companies that want to deploy NFV what is their main objective? But I would say that it's very important for doing it right nowadays to make sure that you have the right platform with the right and good enough interfaces so resources can be leveraged from the platform. A good focus is also to pay attention to how to onboard the virtual network functions. So having a very good understanding on the possibilities of the interfaces that we offer, for example, the onboarding, and to understand them well -- because this is one of the most recurrent actions that will take place at the end for a solutions provider.
Understanding all the aspects of the orchestration and the management and having a very good understanding of the platform -- which by the way, ETSI NFV would provide the interfaces for the use of the virtualized resources -- are also important.
Organizations need a very good understanding of the capabilities of the management systems that help automate all of the processes and the tasks as well as how they can ask the VNF providers to package the VNFs in a certain way and how to onboard them.
These are the key three aspects. And maybe the fourth aspect is also having a very good understanding of the capabilities that we offer to connect all these functionalities of the organization to be reused and used by the current OSS and BSS systems. So as long as a company well understands those four aspects of NFV, it should be a "good to go." Obviously, that does not ensure everything works from the very beginning because there's still integration needed in a real deployment, but those four aspects will be key for someone who wants to embrace NFV.
TT: What are the primary or most common integration challenges that you see?
JT: Currently, the integration challenges might be a bit challenging because of the lack of standard APIs that have not helped so far using the integration. But we have the delivery of specifications for APIs coming. Likely, the integration should be maybe not 100% resolved, but at least alleviated. We see also that it's improving a lot, so the integration is likely to be alleviated because of the hands-on experience as well when we do the block tests, for example. Also, the capability of good descriptors, good specifications for packaging the VNFs, and good specifications for interfaces should help alleviate all those integration pain points.
— Joe Stanganelli, Contributing Writer, Telco Transformation
