Cisco has never been shy about taking a different (and often frankly opportunistic) path with respect to “revolutions” like the cloud, SDN, and NFV. I’d be the last guy to say that Cisco was all for an open-happy-band-of-brothers approach to competition but I’d also be last to expect that they would be. We’re all in business to make money, and if Cisco takes a position in a key market like SDN that seems to favor…well…doing nothing much different, you have to assume they have good reason to believe that their approach will resonate with buyers. Even if their story is confusing. So it is with OpFlex.
Classical OpenFlow SDN uses a central controller to manage the routes in a network. This controller uses OpenFlow to communicate forwarding rules to the network devices, and this process can be supported either in “reactive” or “proactive” mode. In the reactive model, a switch tries to find a rule for something and if it fails, kicks the “something” back to the controller to get a rule. In the proactive mode the controller is expected to pre-load the devices with complete and consistent forwarding tables.
So how aout OpFlex? OpFlex isn’t “an alternative” to OpenFlow as some have suggested; it has nothing to do with the forwarding tables in a direct sense. It’s my view that you could still use OpenFlow inside a network that was controlled by OpFlex at a high level. You could also use traditional devices. Like other Cisco initiatives, OpFlex appears to be aiming higher, working to translate application needs into policies and then communicate those policies to the places in the network where traffic control is applied.
Policies, and policy exchanges, are what OpFlex is about. It’s convenient to visualize OpFlex as creating a kind of “policy network” that exists in parallel with the real network. This network has three tiers—a Policy Controller/Repository, Policy Elements, and Managed Objects, which are “objects” more in the abstract or software sense. The goal of OpFlex is to create a tree of policy distribution that ends with Policy Elements that can “resolve” a policy. It’s the resolution of policies that control the devices. Policy Elements are linked to one or more MOs, and these MOs are representations of (abstractions of) real/virtual network elements.
Where this connects with user reality is in the notion of “Endpoints”. Endpoints are devices, virtual or real, and when they “connect” they are registered and assigned a policy. It’s that policy and the handling it represents that is distributed using OpFlex. It appears that you can also define “roles” or application structures within an Endpoint, giving them separate policies. All that adds up to a way of doing application-based handling in an open and distributed way, presuming that everyone implements OpFlex consistently.
If I’m reading the draft RFC right (Cisco, feel free to send me a correction if I’m not) then this whole process has the effect of creating a kind of policy-domain set that overlays on a normal IP or Ethernet network. This means that the topology management and basic device forwarding stays as it is except to the extent that a Managed Object behavior is applied to the device and that MO responds to a policy. If there were no policies, the network would presumably function as it is today. If central policy control is lost it would appear that a default policy could be applied within the policy tree, even down to the device level.
The OpFlex concept is consistent with Cisco’s larger vision of SDN, which has been that it’s about application or software control, starting with APIs and going down to whatever you put in the data path. That doesn’t have to be anything much different, though it can be. Cisco seems to imply that there will be an OpFlex link to OpenDaylight; certainly they’re not trashing OpenDaylight or Insieme. I see OpFlex as being an intermediary layer in the Cisco approach, a means of allowing an API-driven SDN vision that’s always been kind of about policy into an “open” approach. Is it open? Yes; Cisco is going to do a reference open-source policy controller and the protocol is being submitted as an IETF standard.
You can now see why I say this isn’t really much related to OpenFlow, though Cisco positions it as being an example of a “declarative” versus OpenFlow’s “imperative” model. Actually Cisco is describing the “reactive” OpenFlow model I described earlier when it says “imperative”, and I’m not convinced that model is ever a good idea outside the lab. Most SDN users would want precomputed routes and failure modes. A better comparison would be to say that OpFlex as an architecture would allow policy-based application control with current devices. In that regard, it’s really not that different from an OpenDaylight controller with a legacy ACI plugin on the bottom.
Part of Cisco’s approach appears to be applicable to real current problems. MOs can have statistics and state indicators that can be observed, and it appears to me that an MO hierarchy might be able to support “derived state” accumulated up an MO chain from the individual devices (real or virtual). It also appears that you could view OpFlex as a kind of SDN federation approach since it seems that a Policy Element could “represent” a complete SDN/OpenFlow network and thus OpFlex and the policy tree could mediate traffic handling across multiple SDN domains. But the big problem here is my need to continually use qualifiers like “cloud” or “appears”. By presenting such an obvious OpenFlow counterpunch as the centerpiece of OpFlex PR material, Cisco has hidden any real mission statement and we’re left trying to dredge it out.
One thing I don’t like about this, at least as I’m interpreting it, is that what we’re doing here is establishing application networking policies that are distributed down to the lower network layers. It appears to me that you could establish policy hierarchies where lower-level networking recognized three or four classes of service and then map application policies to transport policies, but I’m not sure why you’d want to define higher-level policies that wouldn’t be implemented granularly. I favor the notion of an SDN network that’s layered, with the top level a pure overlay structure (like Nicira) and the bottom level a pure-policy transport-grade-of-service structure. This I think would be a simpler model because connectivity and grade of service consumption are mapped only at one place—the boundary between the layers.
There’s nothing in the announcement that makes it clear how things like orchestration and management would work in a policy-driven world, though as I indicated you could infer some hooks in OpFlex if you look closely. I think this is the biggest technical downside for Cisco and the biggest business downside too. You can’t create network value with protocols, and at the end of the day that’s what OpFlex is. Since I can easily map a concept like this into the broad “structured intelligence and derived operations” model I’ve been talking about, I have to believe Cisco could have done that too.
I see a bit of a rush-job positioning here, too. “OpFlex” is a term that’s widely used in other industries so if you search on it you get a bunch of extraneous hits. The OpenFlow jabs seem furiously defensive, and the state of the material is deficient even for a company like Cisco who values inspiration way more than buyer education. I think Cisco is seeing the handwriting on the wall (and it’s Chinese), and they’re leaping to the attack here. Maybe they should have waited a bit.