OpFlex: Just what the doctor ordered: yet another distributed point protocol!
Yesterday Cisco announced OpFlex, a new protocol designed to let policy managers send policy commands to network hardware. This sounds like an admirable move in the direction of SDN, except that Cisco touts this as a replacement for OpenFlow, and a development that negates the value of the centralized controller, both central tenets of the SDN revolution that targets the Cisco incumbency.
People who have read the releases (such as yours truly) were introduced to the virtues of “declarative control” over “imperative control” and the pernicious lack of scalability or fault tolerance of centralized controllers. Above all, OpFlex made it possible for intelligence and the policy decision making process to be sensibly distributed all over the network, just like it has been for decades. My, how familiar and comforting!
You have probably concluded from the tone of the preceding paragraphs that I might not share Cisco’s opinions on the virtues of OpFlex. To be perfectly “open” (a concept to which I cleave), I do work for a company 100% committed to SDN, so I won’t claim to be unbiased. But neither am I so easily misled. Let’s take a closer look at the questions Cisco’s claims generate:
Can OpFlex replace Openflow? OpFlex isn’t an OpenFlow replacement. It’s not even close! All it does it provide a common language for policy dissemination. This isn’t flow management with dozens of actions, instructions and matching fields. This isn’t a way for applications to communicate with the network to create a truly intelligent and interactive (software defined network) fabric, like what the OpenFlow controller provides.
What OpFlex does is attempt to chip away at the perceived value of the centralized controller by removing one very important function: policy. However, it does so by placing offering a solution tailored for use with another centralized node!
Who really benefits from a declarative control model? Cisco makes a big deal of OpenFlow providing imperative control vs. OpFlex using a declarative control model. In plain English: in the “declarative model” the equipment vendor decides on how the model is implemented. In the “imperative model” these definitions are made by the controller who implements them consistently for all the devices it controls.
As to how the OpFlex policies are implemented, that is entirely up to the node in question. I am sure that having policies centrally issued but locally interpreted by every different piece of equipment will lead to more consistent network behavior. A certain equipment vendor (I’m sure one comes to mind) will certainly be able to make a good case for customers to ensure harmony by deploying ONLY their devices. Can everyone see the progress being made here?
Is the centralized controller concept bad for scalable networking or just bad for high-margin hardware vendors? Cisco has consistently challenged SDN’s centralized controller concept saying that it doesn’t scale and is low-availability. Not only have those claims been consistently dis-proven in lab tests (see IEEE test here) but they also demonstrate that scalability and high availability can be achieved via other means (and on cheap COTS hardware!)
The incumbents don’t want to see the concept of the centralized controller broadly accepted because it transfers too much value out of high margin network devices and puts it on cheap virtualized hardware. It’s in the incumbents’ interests to preserve the existing model of high-margin network devices. They present the idea that a single network entity, acting as the interface between network devices and the entities that wish to use their resources, is less scalable and/or less reliable than a whole bunch of scattered devices. Okay, the distributed approach has been working. But let’s be clear here: it has not been particularly deterministic in its behavior, and the problem is only getting worse as mobility, the cloud and virtualization push existing protocols to do things for which they weren’t designed!
Leaving aside the desirability of deterministic network behavior, let’s look at what we lose when we throw the controller baby out with the SDN bathwater: without a central controller in the picture there is no single entity with which applications can negotiate for network resources. Applications, policy management, and network services ALL have to somehow become aware of and manage all their relationships individually with a whole mess of nodes. This is painfully complex in a traditional network, but becomes a gargantuan nightmare in a cloud or NFV context.
Is adding another protocol layer the answer? Let’s summarize: OpFlex purports to replace OpenFlow, a broad based, open standard, coherent framework for implementing software defined networks, with a set of commands that continue to require multiple, expensive hardware devices to process.
These commands are meant to transfer only highly abstracted policy commands that must be interpreted individually by each network device. This has the added ‘benefit’ of avoiding having a network node (the controller) that actually understands the state of the entire network and can consistently coordinate behavior across the entire fabric. Even more perniciously, that controller can provide applications a single party with which to negotiate for said resources and interact in a “software defined” fashion. Why would anyone want that level of dynamic flexibility in their network?
Clearly large hardware vendors must provide the medicine to try to stop the spread of that level of centralization and reduced hardware costs! Adding yet another protocol layer on top of the current onion of protocols is just what the hardware sales doctor ordered. OpenFlow’s attempt to displace cherished friends of the network manager such as STP and BGP needs to be eradicated, and OpFlex is just the medicine to do it.
Maybe I’m being a bit of a Donny-downer here, but I have a feeling this is one medicine that Cisco competitors and most of the SDN industry are not going to be swallowing. I don’t know about you, but we are drinking a warm glass of OpenFlow right now and our network is already feeling better.
