The ONAP Amsterdam release is out, and while there are reports that the modular structure eases some of the criticisms made of ONAP, I can’t say that it’s done anything to address my own concerns about the basic architecture. I’ve tried to answer them by reviewing the documentation on ONAP, without success. They’re important, basic, questions, and so I’ll address them here and invite someone from ONAP to answer them directly.
Let me start by talking about a VNF, which is the functional unit of NFV. A VNF is a hosted feature, something that has to be deployed and sustained, like any software component. VNFs have network connections, and these can be classified into three general categories. First, there are the data-plane connections that link a VNF into a network. Firewall VNFs, for example, would likely have two of these, one pointing toward the network service and the other toward the user. Second, there are management connections representing portals through which the management of the element can be exercised. SNMP ports and CLI ports are examples. Third, there may be a connection provided for user parametric control, to do things like change the way a given TCP or UDP port is handled by a firewall.
When we deploy a VNF, we would do a bunch of stuff to get it hosted and make whatever connections it has accessible. We would then exercise some sort of setup function to get the management and user parametrics set up to make the function operational. Lifecycle processes might have to renew the connections and even change management and user parameters. The connection management part of deployment involves making the connections addressable in an internal (private) address space, and exposing into the “service address space” any connections that are really visible to the user.
I think it’s clear that the process of “deployment”, meaning getting the VNF hosted and connected, has to be a generalized process. There is no reason why you’d have to know you were doing a firewall versus an instance of IMS, just to get it hosted and connected. A blueprint has to describe what you want, not why you want it.
In the management and user parameterization area, it is possible that you will not have a generalized interface. All SNMP MIBs aren’t the same, and certainly all the possible firewall implementations don’t have the same interface (often it’s a web portal the device exposes) to change its parameters. If we don’t need to set up the VNF because the user is expected to do that, then management and parameterization are non-issues. If we do have to set it up (whether there’s a standard interface or not) then we need to have what I’ll call a proxy that can speak the language of that interface. Logically, we’d ask that proxy to translate from some standard metamodel to the specific parameter structure of the interface.
Given this, the process of onboarding a VNF would be the process of describing the hosting/connection blueprint (which probably can be done with existing virtualization and DevOps software) and providing or identifying the proper proxy. I would submit that there is nothing needed that’s VNF-specific beyond this, and nothing that’s specific to the mission of the VNF.
OK, so given this, what are my concerns with Amsterdam? The answer is that a good, promotional, industry-responsive description of VNF-specific processes would look like what I just offered. I’d start with that, a powerful comment on my generalized approach. I might then say “We are releasing, with Amsterdam, the metamodel for VoLTE and residential gateway (vCPE), and also a proxy for the following specific management/parameter interfaces.” I’d make it clear that any VNF provider could take one of the proxies and rebuild it to match their own interfaces, thus making their stuff deployable. This would be a highly satisfactory state of affairs.
ONAP hasn’t done that. They talk about the two “use case” applications but don’t say that their support for them is a sample adaptation of what’s a universal VNF lifecycle management capability. So is it? That’s my question. If there is any degree of VNF or service specificity in the ONAP logic, specificity that means that there really is a different set of components for VoLTE versus consumer broadband gateway, then this is being done wrong and applications and VNFs may have to be explicitly integrated.
The blueprint that describes deployment is the next question. Every VNF should deploy pretty much as any other does, using the same tools and the same set of parameters. Every service or application also has to be composable to allow that, meaning a blueprint has to be created that describes not only the structure of the service or application, but also defines the lifecycle processes in some way.
People today seem to “intent-wash” everything in service lifecycle management. I have an intent model, therefore I am blessed. An intent model provides a means of hiding dependencies, meaning that you can wrap anything that has the same external properties in one and it looks the same as every other implementation. If something inside such a model breaks, you can presume that the repair is as hidden (in a detail sense) as everything else is. However, that doesn’t mean you don’t have to author what’s inside to do the repair. It doesn’t mean that if the intent-modeled element can’t repair itself, you don’t have to somehow define what’s supposed to happen. It doesn’t mean that there isn’t a multi-step process of recommissioning intent-modeled components, and that such a process doesn’t need to be defined.
I don’t see this stuff either. I’m not saying it’s not there, but I do have to admit that since operators tell me that this is the sort of thing they’d need to know to place a bet on ONAP, it’s hard to see why it wouldn’t be described triumphantly if it is there.
ONAP may not like my criticism and doubt. I accept that, and I accept the possibility that there’s some solid documentation somewhere on the ONAP wiki that explains all of this. OK, ONAP people, assume I missed it (there is a lot of stuff there, candidly not structured to be easily reviewed at the functional level), and send me a link. Send me a presentation that addresses my two points. Whichever you do, I’ll read it, and alter my views as needed based on what I find. If I didn’t miss it, dear ONAP, then I think you need to address these questions squarely.
While I’m offering ONAP an opportunity to set me straight, let me do the same for the NFV ISG. This is how NFV deployment should work. Show me where this is explained. Show me how this model is referenced as the goal of current projects, and how current projects align with it. Do that and I’m happy to praise your relevance in the industry. If you can’t do that, then I humbly suggest that you’ve just defined what your next evolutionary phase of work should be targeting.
To both bodies, and to everyone else in the NFV space who talks with the media and analyst communities and wants publicity, I also have a point to make. You are responsible for framing your story in a way that can be comprehended by the targets of your releases and presentations. You should never presume that everyone out there is a member of your group, or can take what might be days or weeks to explore your material. Yes, this is all complicated, but if it can’t be simplified into a media story then asking for publicity is kind of a waste of time, huh? If it can’t be explained on your website with a couple diagrams and a thousand words of text, then maybe it’s time to revisit your material.
