The recent announcement about HPE acquiring Juniper, and my blogs on it, raised a lot of discussion on LinkedIn about the combined company’s likely telco strategy, and as it happened there was also a discussion on an Omdia paper called “Telcos must take charge of their cloud native vision”. This in turn referenced a CNCF white paper called “Accelerating Cloud Native in Telco”. All of this hearkens back to the old discussions of the Network Functions Virtualization work within ETSI, launched back in 2012. I’ve blogged about it many times, but some of the discussions and the paper raise some new points worthy of consideration, especially given the HPE move.
All the initiatives being discussed here relate to ways that telcos could use hosted software elements as part of service creation. In the NFV project, the original notion was to convert the physical devices (physical network functions or PNFs) into software-implemented virtual network functions (VNFs). 5G included the use of VNFs to perform some of the control-plane handling of mobile networks, and the more recent activity is more generalized, aiming simply at software-created features of any sort. This has gradually exposed some important subdivisions in the way we think about hosted features.
Obviously, the major subdivision is the separation between the “what” and the “how”. A “service feature” isn’t homogeneous in terms of its requirements. You don’t hear much about this point today, nor did we hear much about it in the early days of NFV. But keep this what/how thing in mind; it’s important for reasons you’ll see.
The “what” is perhaps the thing we hear the least about. That’s too bad, because missions determine requirements. For example, packet forwarding in the data plane is clearly a more demanding task than processing control-plane packets. Per-user features are less demanding than features that would be applied to traffic involving many users. Demanding features would logically require more capable hosting capabilities, which means that if we have indeed spread out the breadth of stuff we’re calling a “virtual network function”, we have to spread out our hosting options.
What are our “How” options? Well, starting with the least-stringent, we have serverless/function hosting, followed by containers, followed by VMs, then bare metal servers, and finally specialized platforms that we might call “white boxes”. Generally, as we move from the first things on my “How” list to the last, we’re moving to lower levels of performance and determinism.
You might wonder what all this has to do with the “cloud native” discussions, and as well you might because that discussion is what everyone seems to want to have, and to think of as critical. Not so, and the reason is that as we progress through our list from the least-capable “How” to the most, we’re progressing from something that’s intended to be highly sharing-optimized to something that really isn’t shared at all. The cloud is about sharing resources, a resource pool, so it follows that cloud-native as a concept is most important to the early “Hows” on our list, and likely not important at all to the last ones.
What is important? We need to go back to the what/how point for that.
A hosted feature has two personalities. The first is mission-related, functional, meaning related to the “What” piece, and the second is platform-dependent, structural, and related to the “How.” In its role as an element in a service, a VNF has to assert its functional personality, meaning to allow its behavior to be controlled. In its role as a hosted component, it has to assert the properties needed to manage its relationship with what’s hosting it, including deployment and “feature FCAPS”. A given VNF should have the same functional face no matter what “How” is associated with it, and not only should a given “How” be operationalized the same way no matter what VNF is on it, all “Hows” should share as much operational behaviors as possible to maximize opex efficiency.
I submit that discussions about “cloud native” relating to VNF hosting are of little or no value. Not only can’t we really define what that means, we can’t expect all hosting options to be related in any way to the cloud. The later on my “How” list we are, the less cloud matters…except for that goal of common operations.
What is important here, in my view, is not “cloud” but Kubernetes. Kubernetes is most associated with container deployments, but there are extensions that make it work on bare metal, and the Nephio project aims at bringing it to manage specialized network devices, something like the NFV’s PNFs. The real goal of all these “cloud-native” initiatives should be to create Kubernetes-centric operations. We should deploy and manage “Hows” through Kubernetes/container-like tools, providing add-on enhancements to the Kubernetes framework as required.
On the “What” side, of course, we can’t expect to define a single functional management approach. What we could and should do is to define a single implementation model. For that, I fall back on the “derived operations” approach I suggested back in 2012, which was based on an IEFT proposal called “i2aex”, which stood for “infrastructure-to-application exposure” (it never went anywhere in the IETF, by the way). The i2aex model of derived operations could also handle the common operations goal of the “How” side.
This proposal said that all devices (in our case, whether real or virtual) contributed its actual control parameters to a MIB database, using a standard structure. The management phases of the “What” feature attributes would be handled by linking an arbitrary management API to a query to that database. Not only would this make presenting management interfaces very flexible, it would isolate actual real and virtual devices from the risk of being subject to what would look like a denial of service attack should a bunch of management systems trying to manage features end up hitting the same software/hardware elements.
It’s possible that we could see a “How” MIB and “What” MIB standard develop, just as we see today’s MIBs a bit of a hierarchy where a base is expanded upon with extensions. That would encourage common management practices and tools, though I believe that the i2aex query-based “derived” operations would make customization easier.
What should we take away from all of this? First, there is no point having general discussions about “cloud native” in hosting things. We need instead to divide features by what hosting options are suitable for them, and then operationalize them both at the functional level and the hosting level. Second, the real focus of bodies like the NFV ISG should be on the functional side, and they should limit their hosting “How” side behavior to identifying requirements. Finally, we should accept that it’s the operational issues on both the “What” and “How” sides that will present the real challenges…and opportunities.
Maybe the “Where” will, too. Would NFV, or feature hosting in general, promote edge computing? Right now that’s a tough question, because lacking definitive “How” and “What” answers, we can’t really say for sure. Edge hosting is a tough slog, though, because the further out you go, the smaller the number of users you can draw on and the smaller any pool of resources would have to be. We can have ten thousand servers in the cloud, maybe a thousand in the metro, but there’s only one smartphone pressed against each person’s ear. Somewhere between one and a thousand, the edge will have to find its place.
