OpFlex - is the abstraction in the right place?

Posted by Dave Tucker on Mon 28 April 2014

It's been a few weeks since Cisco announced OpFlex and I've just finished gathering my thoughts...

What is OpFlex

It's a protocol for delivering policy to endpoints. Policy is declarative, based on promise theory and can therefore scale well vs. imperative models (like OpenFlow)

What does this all mean

Kyle Mestery assures us that OpFlex is not an OpenFlow killer and while I agree, I'm starting to have my doubts. Vendors have been dragging their heels when it comes to implementing OpenFlow due to its pipeline and table structures not being a good fit to current hardware. OpFlex offers them a way out as they no longer need to care "how" something is implemented, just that the "promise" is kept (read: policy is enforced).

I can see Cisco deploying OpFlex across their entire portfolio and declaring victory - we've got SDN. Who cares about OpenFlow? This begs the question of whether OpFlex is just a move from Cisco to protect it's core business?

Why I care about OpenFlow and you should too

The future of networking is "Open"

The key benefit to using OpenFlow is disaggregation. It's beneficial to everybody for the proprietary stack to be broken down to allow openness at all layers.

OpenFlow gives us the standard API from the chipset to the network OS allowing any chipset to be used. It's the x86 of Networking.

Linux gives us a standard OS on which we can build applications.

Open source is where we, the community, collaborate on applications. The community includes everybody, after all, why should vendors be the ones calling the shots? In open source, you can have your say! Open Source can replace open standards in a disaggregated stack. The focus is on the implementation not the documentation and interoperability is guaranteed should we all use the same implementation.

A solely OpFlex based solution will be open at the Policy/API layer but closed from the Network OS down.

Not everything about OpFlex is bad

OpFlex does have some merit in that there are benefits to the declarative model. There is less overhead than in an imperative model as you don't need to maintain state for all of the endpoints... it's safe to assume that if they "promise" to do something then that promise will be kept.

Also my understanding is that OpFlex will be open source which means that all aspects of the development will be in the open. As with all open source projects, single vendor open source doesn't mean much. Cisco will need to rally it's partners and customers to contribute in order for it to "matter" in the industry.

Is the abstraction in the right place? Device-level vs Controller-level policy

Having thought a little further about what OpFlex is trying to accomplish I'm wondering more and more whether the abstraction is in the right place... Consider the following points.

How do we troubleshoot a system wherein each node is responsible for rendering policy? Note that in the declarative model that each node may chose a different mechanism/implementation to guarantee a promise. This goes against one of the most important traits of our networks - predictability - which is a characteristic of robustness.

How do we create policy for elements that require context without blurring the lines between imperative vs declarative? Take something like traffic engineering for example which requires some context. For example, I might need to know which interface is the next hop in the shortest or lowest cost path to a destination. This context is usually gathered from a protocol (assuming we aren't using SDN here). At this point, your policy would have to include a "promise me you are running BGP" which is tying a promise to a specific implementation in turn making the policy less abstract. When your policy has a dependency on a given implementation, you reduce the number of endpoints that could successfully use it.

The edge of the network is a great place for enforcing policy, but IMHO it's not the right place to render it.

Using OpFlex at the Network Controller level makes more sense to me. There hasn't been much talk about where we place network controllers but taking performance and reliability in to consideration this would be as close to the endpoints as possible. You then end up with N controllers that need to share a common policy. Having this policy managed with OpFlex seems like a great idea as we can be sure that the implementation within a given control (or administrative domain) is the same, making troubleshooting simpler and giving us predictability, and that each controller has sufficient state information to implement abstract policy.

OpFlex would also be the elusive East/West API that people have been calling for to allow interoperability between controllers.

What do you think? Drop me a line on Twitter or leave a comment!


Comments !