Finally, a decade after the concept of NFV was first introduced, we may be on track to creating a useful implementation of function hosting. The Linux Foundation and Google Cloud announced Nephio, a project that would create an open-source framework for cloud-compatible function hosting and operations automation. It could realize the goals of the “Call for Action” paper operators put out in 2012, and create a model for at least the lower level of edge computing software deployment. It might also help Google along the way.
Everyone who works in or with the cloud at least knows about Kubernetes, it’s the container orchestration and DevOps tool that has almost swept everything else out of the market. Those who have followed my blog know that I’ve been a proponent of using cloud technology as the foundation of function hosting from the first. I’ve lost faith in the NFV ISG as the driver behind a useful implementation of function hosting, and even suggested that an open-source body like the Linux Foundation would be better. Well, we may find out now.
The Nephio framework presumes that function hosting is best viewed as three layers. At the bottom is cloud infrastructure, the real stuff that hosts functions. Then comes the virtual function workload resources, and then the virtual function workload configuration. Nephio proposes that Kubernetes orchestrate all three of these layers. All of this is managed through a series of Custom Resource Definitions (CRDs).
The bottom layer of Nephio is fairly classic in terms of Kubernetes use; CRDs are the ultimate direction here because they’re Kubernetes-centric, but there are accommodations for other models and APIs planned to make Nephio compatible with current function-hosting directions, like NFV, and also to link back to things like ONAP, via a “K8S Operator” function set.
The same approach is supported for the other layers. The middle layer is designed to replace the customized onboarding and infrastructure-as-code model used for network functions in NFV, with a declarative configuration model that’s again Kubernetes-centric. This is done through the same sort of K8S Operator technique. The top layer configures the functions, and so it will support things like Yang and the 3GPP 5G RAN functions (via a K8S Operator), and will talk to network elements via Netconf.
Overall, everything is built as an intent model, and Google contributed both source code and a reference architecture that would virtually assure that implementations would be open. It’s a major advance in network function virtualization. It doesn’t do everything, though, and so we have to look at the “does” and “doesn’t”
sides to assess the impact and when that impact could be expected. Keep in mind as you read on that the material now reflects my analysis more, and objective data from Nephio’s website is only an input to my views.
The first thing that comes to mind is that Nephio creates an abstraction of a function host that’s broadly applicable to any application of NFV, and also any application of edge computing. It provides for the creation of an abstract “host” that can include almost anything on which software can be run, no matter what it is (as long as it can host Kubernetes node control) and where it is.
One thing that means, I think, is that the Open RAN RIC function could be implemented through Nephio, and that could be of enormous value to 5G deployments, in operations and efficiency terms. If everything is a Kubernetes resource, be it hosting or deployable asset, it makes orchestration of service features much easier.
Similarly, IoT could be facilitated with Nephio. Edge assets for IoT could be on-prem near the processes under control, or distributed variously depending on hosting economy and latency budget. It appears that Nephio could handle this variable mix of stuff and stuff-residence, and that could not only support current IoT models but also facilitate the use of edge computing to support IoT as those resources become available. And, of course, it would support edge computing applications.
It also appears that Nephio could serve as a bridge that existing NFV could cross to reach a rational cloud-centric architecture. Certainly, the virtual functions (VNFs) of NFV could be deployed via Nephio, and they could also be configured, which would mean onboarding would be facilitated. Whether there would be any value to the specific NFV interface points for MANO, VNFM, VIM, and so forth remains to be seen given the minimal use of NFV today, and given the level of the current Nephio documents. I suspect that a lot could be done.
I think Nephio could also be used for white-box switch function deployment and orchestration. If that’s the case, then for sure you could use it for deployment and orchestration of proprietary network elements like switches and routers, which would essentially join these devices to the generalized resource pool created by Nephio. That would go a long way toward creating universal service operations.
But that gets us to the “don’ts” In its current form, Nephio does not do end-to-end service orchestration. If we try to map Nephio to NFV, what we get is something that creates a kind of universal, intent-based, NFVI (infrastructure) with a kind-of-VIM (virtual infrastructure manager) and MANO (management and orchestration). The VNFM (VNF manager) function is addressed peripherally, but there is no model or process designed to define a service or to manage its lifecycle. However, that model doesn’t exist in the NFV specs either, nor in fact is it part of ETSI ONAP.
Could there be a service layer to Nephio down the line? It seems to me that if we have intent-modeled elements, multi-layer orchestration through Kubernetes, and CRDs to describe things, we could add a kind of CRD to describe a service and functional logic to treat that as a decomposable model. If Google and the Linux Foundation are serious about transforming function hosting, I think they’ll need to look at doing this.
Another “don’t” is the virtual functions themselves. As I’ve pointed out in THIS blog, you really need a PaaS model for functions to be written to, and the same is true for edge computing overall. Otherwise, we risk ending up with implementation silos that require a lot of different executions of the same things, raising overall resource usage and making operations more complex.
All these contribute to a big question, which is just where Google will take Nephio. Did Google, flushed with love for their fellow networkers (and maybe filled with pity for those in telecom) just decide to do this project to contribute it? Doubtful. Google has always been a cloud partner of interest to the operators, and in fact were the only cloud provider operators actually asked me about engaging with. I think the fact that Google Cloud rather than just “Google” is the originator and sponsor of Nephio is telling. They’re going to do this, which means that there will be a functional implementation of at least the “do’s” part of NFV available. Everyone else in the market will either hunker down on “raw” NFV and likely fade away, or get on the Nephio bandwagon.
There are a lot on that bandwagon already, including major vendors like Intel and VMware, some network operators, and even some of the NFV VNF vendors. The community interest in Nephio is strong, which is a good sign since support from vendors is a prerequisite for rapid advance in the world of open source. One bad signal, though, is the fact that the majority of those ten operators who launched NFV in 2012 are not, so far, part of the project.
That’s bad because the NFV ISG and ETSI really need to get behind Nephio to redeem a lot of effort that’s been put into function hosting and service automation. The NFV ISG should restructure itself as a requirements contributor to the Nephio project, and a contributor to the issue of creating initial compatibility with ETSI NFV elements, and forget any technical activity outside that project. The ETSI ONAP project should consider how to build something designed as a higher layer, the new fourth layer, to the Nephio structure and focus on models for service orchestration (which it has stubbornly refused to do).
But, of course, neither of these happy outcomes are likely, and that could be good for Google. If they take Nephio where it needs to go while organized standards stand aside, there’s a chance other public cloud providers will stand aside rather than seem to validate Google’s thinking. That could leave Google as the only one thinking at all.
