Declarative or Imperative SDN?
There has been some recent “Brew Ha-Ha” in the media over the Imperative vs Declarative SDN models. I think most of this is coming to the surface now because of the recent presentations and announcements at InterOp.
Even I became caught up in the arguing. Specifically after a recent “Networkworld.com” article referring to Cisco’s OpFlex (and the declarative model that it operates in) as the “OpenFlow SDN killer.”
Frankly that article just really ticked me off. It appeared to me that Cisco was in essence giving the “middle-finger” to the Open Networking Foundation (ONF) and the work Cisco has been doing with OpenDaylight.
The problem here seems to be the mixed-messaging coming from Cisco. Jim Duffy with NetworkWorld.com brilliantly highlights this here.
On the one hand Cisco does not endorse the imperative SDN model used by VMware NSX, Google (both internally and with Andromeda), and of course any OpenFlow based SDN. However they still claim to be in full support of the work they are doing with OpenDaylight.
But on the other hand, the OpFlex policy agent can leverage OpenFlow and OVSDB. That’s great! In fact, its kind of interesting that parts of the OpFlex draft regarding JSON usage (specifically section 4.1), are copied/pasted word for word from the OVSDB draft section 3.1.
But again, Cisco is completely against the imperative model and OVSDB. They claim that the declarative model used in ACI is superior. You can see how this mixed-messaging is confusing.
With imperative SDN you have a centralized controller (usually a clustered set of controllers) that act as the “brains” for your SDN. The controller receives requests from your applications via a northbound API, and in turn sends commands downstream to your end devices (using some protocol – like OpenFlow) to configure the devices – physical or virtual – to meet the needs of the application. The controllers are NOT in the data path. They are simply providing the instruction set to the end devices and telling them how to push packets. When you see packet “X” perform function “Y.”
Cisco’s ACI leverages a declarative model. With declarative SDN, you are essentially distributing the intelligence out to the network fabric. The ‘controller’ in this case (if you can really call it that) is “declaring” what the application needs, then relays that need to the network fabric using the OpFlex protocol. The end devices then determine the proper method to meet the application requirements.
Which option is better? Really I don’t think anyone can answer that right now. Cisco’s argument against the imperative model is that it doesn’t scale. (Apparently they haven’t talked to Google).
I don’t really have an argument against the declarative control model, but I certainly have significant concerns.
The goal of SDN is that I am taking the software OUT of the hardware and in doing so I eliminate vendor lock-in. I think declarative SDN makes it very easy for a vendor to say, “Hey, use this framework, and we will accelerate it (or somehow manipulate it) on the device in ASIC.” Once you do that you can say hello to vertical lock-in. You’ve just taken a function that should be handled up at the control plane and moved it to the data plane.
It’s a slippery slope. The fact that you have a leading networking vendor (Cisco) championing such a model is cause for concern in my opinion.
You can say the same thing about NSX. That is a proprietary controller. Yes, absolutely. I don’t believe that in the end we will all be using a VMware, or Cisco, or HP, proprietary system to control the policy framework holistically for your entire environment. That would defeat the purpose of SDN. It cannot be owned by any single vendor or we might as well all go home. There is no point if I am locking myself to a vendor.
I think in the end what HAS to happen is something along the lines of what Martin Casado is doing with Congress and OpenStack. This is a concept that has much larger scope than just SDN.
We need to take a step back and look at the broader picture here. It is about policy and business logic, not just as it applies to networking but to the entire stack supporting the application. The environment as a whole. There needs to be a central open control plane where you can define your business logic. The policy controller will then configure the stack (network, storage, compute, etc) to conform to that business logic.
The key here is that the control plane needs to remain open. That is critical. It cannot be proprietary to any specific vendor, but an industry standard platform. This keeps everyone on the same playing field, and prevents the customer from getting locked into any one vendor’s solution.
So in the end, when we argue about which approach is better (imperative or declarative), it frankly doesn’t matter. As long as the end goal is to provide a truly open platform that simplifies the application of business logic to the environment that avoids vendor lock in.
In my opinion we will probably see a mix of both. I am sure that there will be some instances where it will be beneficial to have a series of end devices that have some sort of intelligence with which to determine the best way for them to meet the application requirements. However I certainly do not believe that will be the only (or even the most widely adopted) model.