The Huawei announcement of new “Agile Controller 3.0” for SDN raises some interesting issues in the transformation game. Huawei’s press release offers comments like “provides the capabilities of on-demand network resource pool reservation, automatic deployment, intelligent optimization, and bandwidth adjustment on-demand for enterprise customers across campuses, carriers and data center networks” and “The AC 3.0 is the “Super Brain” of networks which enables service innovation in cloud era”. A lot of that seems to overlap the concept of “orchestration”. Does it? It’s complicated.
Orchestration isn’t firmly defined, but the sense of the market at the moment is that it means the process of sequencing complex steps toward a common goal. In most NFV terminology, it has a slightly narrower meaning, which is the decomposition of a model element within a service model, or of the model overall, into deployment/connection steps. Orchestration operates across multiple classes of resources, and in most cases it would include provisions for lifecycle management, meaning the response to ongoing events/conditions.
If you can apply “orchestration” to a “model element” then it would be reasonable to say that the element you’re modeling could have two different makeups, one a functional or logical makeup (it decomposes into other models) and the other a physical or deployment makeup. This relates to the idea of decomposing a general “service” down to the committed “resources”. At the top, things are functional, and toward the bottom they’re physical.
What Huawei is announcing is an SDN controller, which would ordinarily put the controller toward the bottom of a classic orchestration/decomposition process. When you draw pictures of a traditional cloud or NFV implementation, you’d find the controller south of OpenStack Neutron, meaning way down the structure of deployment. However, Huawei is offering something that is very much needed and not much discussed, federation of SDN domains. Or at least that’s what I think; I can’t get a detailed picture quite yet.
SDN controllers are normally associated with OpenFlow and white-box switching. This model of SDN has tended to focus on cloud multi-tenancy, which means it’s been applied mostly within a data center. In that mission, it is logical to think of it as an adjunct to committing a VM or container—the connection part. However, networks are bigger than data centers, and no single SDN controller could be expected to handle the work associated with a large scope. That’s where federation comes in.
“Federation” is another term of surpassing fuzziness. I use it in the context I first heard it, which was to describe a relationship between network-owners that allowed for sharing of resources to create services. In the SDN context, federation is the thing that lets you combine SDN domains so that one mega-controller doesn’t have to run the whole world. Instead, you have a hierarchy not unlike the one we find in the DNS world today. If you add federation to SDN, you get the potential to define and build mega-networks. That necessarily elevates the controller from being down in the dust under OpenStack up to somewhere higher.
Where, obviously, there’s the question of the relationship between SDN federated service-building and orchestration. If we look at SDN in a pure connection-service mission, you could argue that a federated controller could do anything orchestration could do, as long as the entire infrastructure was in-scope to come controller or another and the controllers were federated. For cloud-building or NFV, that presumption of mission could be practical under some conditions.
There are a lot of ways that you could conceptualize deployment of a service consisting of components of software and connectivity. Even OpenStack has recognized this, with a kind of hazy option for Nova-hosting-centric or Neutron-network-centric deployment. An application or an NFV service could be set up by assigning components/VNFs to data center complexes and networking them, then deploying the components to a particular server in the complex and making the final stub connections. You could also deploy all the components and network them, or you could do things by data center or metro area. You get the drift. The point is that if you had a deployment strategy that did network-building in a burst, you could treat that process as setup of a massive federated SDN service. You could pull much, perhaps all, the network part out of an OpenStack NOVA or container deployment.
Obviously this would have to be reflected in the higher-level orchestration model, but so does any other approach. Orchestration and modeling drive a decomposition process that has to proceed in some logical way, meaning that you have to deploy software, connect elements, and report status so everything is coordinated. What the SDN-centric vision that Huawei’s federation approach could offer is a deployment model where the hosting and connection sides are separated. That could simplify some of the issues of decomposing models to little islands of functionality that are then connected into the glorious whole.
I’d be a lot more confident about all of this if I had all the details on AC 3.0, but I can’t find anything released on it other than the press release. I’ve gathered insight from the specs of the earlier SDN products. I’d also like to see how Huawei would propose to tie all of this into DevOps for the cloud and orchestration for NFV. Huawei has some good insight in NFV, but I can only speculate how AC 3.0 might be tied to it.
If that tie-in could be provided it could be very interesting. I blogged earlier this week about the notion that we needed to take a network-centric perspective on NFV, not a hosting-centric perspective. If operators agree, and if Huawei’s initiative can promote such a shift in mindset, then it might be a major step forward in NFV.
The change won’t be easy, though. I’ve worked on a number of standards and technologies that were based on modeling services and decomposing the models to build something that works. The easiest way to decompose a model, to orchestrate something complicated end-to-end, is to do it successively. You decompose the current level into the level below, and keep that up until you hit bottom. This creates that islands-of-functionality situation I described above, islands that have to be connected some way. The key point is that this approach tends to create a network as a series of fragments. If you want to separate connectivity and hosting to be parallel functions, you’d have to parse the model and build separate instructions for the two areas, then execute them. Even then, you’d still need to build WAN and data center connections separately if you want hosting and connectivity to be separated, because you can’t do data center connectivity without functions to connect.
It’s also not going to be easy for Huawei to reap the full benefit of AC 3.0, even if I’m totally correct in my view of its capabilities. In my first consulting job, I used to talk about the “feature-function-benefit” trajectory in marketing. We seem, as an industry, to be leaving out the “benefit” piece. A capability is meaningful only in the context that establishes buyer value. Huawei’s marketing/positioning of AC 3.0 is weak, but so are the positions of its competitors. That means that the notion of holistic SDN, or cloud SDN, or SDN-centric NFV, is still a fruit hanging and waiting to be picked.