We’re getting a lot of NFV commentary out of the World Congress event this week, and some of it represents NFV positioning. Most network and IT vendors have defined at least a proto-plan for NFV at this point, but a few are just starting to articulate their positions. One is Juniper, whose reputation as a technical leader in networking has been tarnished over the last few years by insipid positioning and lack of management direction. Juniper’s story is interesting because it illustrates one of the key problems with NFV today—we can’t easily assess what people are saying.
Juniper, in an interview published HERE, is promoting an open NFV architecture, meaning multi-vendor and exploiting open-source software. OK, I’m with them so far. They define three layers to NFV, the data center layer, the controller layer, and the services layer. That sort of corresponds with the three areas of NFV I’ve been touting from the first—NFV Infrastructure, management/orchestration, and VNFs—so I can’t fault that structure either. The problem with the Juniper position comes when you define the layers in detail to map them to the architecture.
NFVI is more than just a collection of hardware, or every data center and network would be NFVI and we’d be a long way toward deploying NFV already. The key requirement for NFVI is that whatever resources you represent to be your contribution to NFVI, they have to be represented by a Virtual Infrastructure Manager. A VIM takes a resource requirement from the management/orchestration of a service order and translates it to a set of commands/APIs that will actually commit the resource and establish the desired behavior. Thus, any time a vendor says that they support NFV and tout a data center or infrastructure layer, they should offer a specific NFVI.
Does Juniper? Well, this illustrates the next level of complexity. Remember that the middle level of NFV is the management/orchestration (MANO) function. This is where a service, specified in some abstract form, is decomposed into resource requests which are passed through the VIMs. The Orchestrator function is explicit in the ETSI NFV ISG’s end-to-end model, so it has to be explicit in any vendor NFV architecture as well. Juniper’s control layer, which sits where MANO sits in the real model, is based on their Contrail SDN controller.
SDN controllers are not Orchestrators, whoever’s you may be talking about. In fact, SDN controllers could probably be placed in the NFVI zone given the fact that they are one way of commanding network service creation. So you need a VIM to drive an SDN controller, and you still need an Orchestrator to drive a VIM.
Orchestrators are a pet peeve of mine, or should I say “lack of Orchestrators” are. If you look closely at NFV you see that there are really two levels of orchestration—service orchestration and resource orchestration. The latter is used to commit resources to a specific service feature, and the former to meld service features into a cohesive service. OpenStack is a resource orchestration approach, and you know that because you can’t define every possible service in OpenStack, you can define pieces of service that are cloud-hosted. Even there, the ISG specs call for things like horizontal scaling and optimization of hosting selection based on service criteria that OpenStack doesn’t offer.
There are some vendors who offer their own Orchestrators. HP and IBM on the IT side and Alcatel-Lucent on the network vendor side have presented enough to demonstrate they actually have orchestration capability. I’ve contended that you can combine open-source functionality (OpenTOSCA, Linked USDL, and implementations of the IETF’s i2aex) to produce most of orchestration (80% in my estimate based on my ExperiaSphere project work), so I’d have no objection to somebody calling out an open and integrated strategy based on this or some other credible combination of components. Juniper doesn’t do that, however, and that’s true of most vendors who claim “orchestration”.
Then we get to the VNFs, and here we have issues that go beyond vendor representations. One of the biggest holes in the current NFV approach is that it never took a top-down look at what it expected VNFs to be, or where they’d come from. As I pointed out a couple of blogs back, VNFs should be considered as running inside a platform-as-a-service framework that was designed to present them with the management and connection features the software was written for. There is no way to make NFV open and generalized if you can’t provide a framework in which VNF code converted or migrated from some other source can be made to run. What exactly does it take to run a VNF? What do we propose to offer to allow VNFs to be run? If either of those questions could be answered, we could then say that code that met a given criteria set could be considered VNF code. We can’t say that at the standards level at this point, nor do vendors like Juniper indicate what their framework for a VNF is. Thus, nothing open is really possible.
What’s frustrating to me about all of this is that here we are getting the third annual white paper on the progress of NFV and we’re still dancing with respect to what makes up an NFV product. I can’t believe that Juniper or the other vendors who are issuing NFV PR don’t know what I’ve just outlined. I can’t believe that people covering the vendors’ announcements don’t know that you have to prove you’re doing something not just say you are. Yet here we are, with relatively few actual NFV implementations available and any number of purported ones getting media attention.
We think NFV is a revolution. Likewise SDN. They’re not going to be if we can’t distinguish between a real implementation of NFV (which right now could be obtained from Alcatel-Lucent, HP, and perhaps Overture) and something that’s still more vaporware than software. Juniper, if you have something do a PowerPoint that maps what you offer to the ETSI document and defend your mapping. Same for the rest of the vendors. I’m waiting for your call.