“Marketers will call whatever succeeds SDN” – Dr. Douglas Comer at Fall ONUG 2014
SDN may have started as a vision from academia around data and control plane separation, but over the years the term has flexed itself to address pretty much any innovation from an incumbent vendor or a startup as long as there is a software element involved. Conversations on SDN often extend into how it will enable more open networking. With Open Network Summit (ONS), Open Compute Platform- Network (OCP), OpenStack, OpenDaylight Summit and Open Networking Users Group (ONUG), 2014 has been the year of “open networking” conferences. Similar to SDN, the term “open” has been left to a number of interpretations and is at risk of becoming yet another cliché unless we take a concrete step to clarify it early on.
What is open in networking?
A product or solution can be open in multiple ways. At a software level, openness can be achieved by:
- Open-sourcing the software
- Supporting open protocols
- Supporting open APIs
Until a few years ago, implementing open standards was sufficient for a vendor to claim “openness,” as it ensured interoperability with other network elements. However, with virtualization and cloud computing increasing agility requirements on the network, openness now has new dimensions. The network device needs to be programmable by external software and automation tools, creating the need for Open APIs. Open-sourcing the software, on the other hand, creates the opportunity for greater transparency and collaboration either with the user community or other vendors in the industry.
At a hardware level, openness can mean either designing the system on a merchant silicon (often, more specifically, Broadcom silicon) or supporting an external third-party OS to run on a vendor’s hardware platform. As we see, these are two widely different mechanisms of openness serving different purposes. A common merchant silicon implementation could eliminate proprietary forwarding plane implementations out of the environment and ensure data plane consistency in a multi-vendor deployment. The disaggregated approach, on the other hand, provides flexibility of software and features the customer chooses to implement without changing the underlying hardware.
Given the wide breadth of above, it is apparent that “openness” is not a binary state but one that is achieved progressively and needs to be addressed in reference to a context and user need; openness is relative. In the absence of a comparable context every solution in the market can be classified as open, creating confusion and hype.
The bazaar of open solutions today
Given the lack of clarity around the term “open” and with every vendor messaging their brand of openness, I looked at industry analysts for their perspective and definition around the term open. Per Brad Casemore, research director for datacenter networking at IDC: “In its purest sense, openness should denote choice and interoperability in both hardware and software, with no vendor lock-in.” Evaluating openness thus requires an understanding of the granularity at which the customer wants vendor flexibility and interoperability.
System-level approach to openness
For almost all incumbent system vendors (with the exception of Dell, which has opened up its hardware to support third-party OS), the open boundary starts at a system level. Open solutions from these vendors hence are in the form of APIs or controllers, often proprietary on the systems they are selling today.
If the customer is satisfied with the incumbent vendor’s system (product, features, pricing, and support), and is mainly looking for operational excellence of that vendor solution, this state of programmability may be acceptable. Most customers however require opening up of the solution to support multi-vendor environments. The system-level solutions, at a minimum, require either a vendor-neutral controller implementation or some level of controller federation across proprietary vendor controllers.
System-disaggregation approach to openness
Vendors targeting the disaggregated network system take the openness granularity a level down into hardware and software level. Very much a lesson from the server side, the view is that by opening up the system and disaggregating hardware and software, one will achieve lower capex, rapid innovation, and lower opex through modular inclusion of opex-saving software elements.
Network System Disaggregation
There is some skepticism in the market regarding whether broader enterprise customers are seeking the level of openness desired by Mega Scale Data Center customers who have been leading this trend. Irrespective of features/opex benefits that may be provided down the road, this approach to openness certainly seems to hold promise for rapidly lowering the system pricing for the customers. Many large financial enterprises are participating actively in the OCP-Network forum, as well as evaluating solutions in the space.
Overlay approach to openness
The overlay approach brings agility and automation to the environment without making any changes to existing hardware. Hence this has been the most prominent approach to openness in the SDN community. But if one takes a closer look at solutions in either the SDDC or the emerging SDWAN space, one finds that the solutions are often closed, single-vendor overlay solutions with little standardization or interoperability across vendors
The proprietary overlay approaches give business agility without a large-scale rip-and-replace of underlying infrastructure. But over time these create another level of lockdown.
Take-away for a customer looking to deploy open networking
For a customer looking to embrace open networking, choices of truly open solutions can be limiting. As we have seen, open networking is not a binary state but a gradual opening-up of environment relative to a state that was less open earlier. A customer looking to implement open networking should consider what problem they are trying to solve and the level at which interoperability is needed.
Having a commonly understood taxonomy for open networking can be a starting point to evaluate the options and have an “open” conversation with the vendor.
The taxonomy presented here is a first attempt to create a systematic representation of choices available in the market. Feedback/comments on above are welcome.