Proprietary implementations of open†source in SDN?

Earlier this year I had the opportunity to speak with Jeff Reed, VP of the Enterprise Infrastructure and Solutions Group at Cisco on the company’s software-defined networking (SDN) strategy and trends in SDN in general[1]. I went in armed with some questions about OpenFlow, expected to hear about the company’s involvement in the OpenDaylight initiative, and was primarily interested in the company’s take on how SDN architectures are impacting vendors of hardware platforms such as AdvancedTCA (ATCA). But when I asked about Cisco’s SDN strategy, Reed was quick to point me to their Application Centric Infrastructure (ACI); when I said OpenFlow he responded with OpFlex. Do you see where I’m going with this?

Proprietary implementations of open source

In early 2013, Cisco teamed with IBM on the beginnings of OpenDaylight, an open-source project aimed at accelerating the development of SDN and network functions virtualization (NFV). Of course, the term “open source” is used loosely at best these days, and although OpenDaylight is now managed by the Linux Foundation and had more than 250 contributors in 2014, the vast majority of the now more than 1 million lines of code are courtesy networking giants such as Juniper, Brocade, Microsoft, Intel, and, of course, Cisco[2]. So while OpenDaylight flies under the flag of open source, is it really?

Let me direct your attention back to OpFlex. OpFlex is a Cisco-envisioned protocol that orchestrates policy between the controller and network switch in ACI implementations (as mentioned, ACI is Cisco’s answer to SDN). Ironically, OpFlex is basically the equivalent of what the OpenFlow controller does for SDNs in OpenDaylight configurations, only faster and with more fine-grained control. Currently OpFlex is an open protocol, and Cisco has committed to licensing it under Apache 2.0 in addition to proposing it as a standard to the IETF[3].

While an open-source variant of OpFlex would make the protocol widely accessible to the vendor community at large, it’s also undoubtedly an endorsement of Cisco’s ACI. In addition to an application policy infrastructure controller (APIC), the ACI model relies on hardware such as Cisco’s Nexus 9000 and Nexus 9300 switches. Meanwhile, Reed also pointed out during our conversation that Cisco has been working on a line of network ASICs over the past couple years that include a flexible parser and flexible data pipeline so that the ICs “can support protocols that didn’t even exist when we shipped it.”

“That’s such a terrific toolset to have with SDN and ACI because if a customer deploys one of those boxes and a great new protocol comes along a year from now, they can support it without having to go buy a new piece of hardware,” Reed said. “So there’s a lot of opportunity for ACI to continue to drive the relevance of capabilities on the network infrastructure itself. Almost every new product or development activity we’re working on ties into ACI and how we enable it via the controllers. That’s part and parcel to how you’ll see Cisco build its products over the next few years.”

In all, these ASICs will provide a migration path from SDN/OpenFlow to Cisco’s ACI/OpFlex architecture, or other future SDN infrastructure combinations. If you’re interested in keeping abreast of the evolution of SDN, I’d suggest you pay attention to contributions in open-source projects such as OpenDaylight; if for no other reason than to make sure there are no surprises.

References:

1. “Software-defined networking – A view from the top.” http:// opsy.st/CiscoSDN

2. “A survey of open networking standards, part 1: OpenDaylight.” http://opsy.st/QualiSystemsOpenDaylight

3. “OpFlex: Another example of Cisco being Cisco.” http://opsy.st/CiscoBeingCisco.