Dec 13, 2013
Is it possible that all of the discussion of open networking is misguided? Put another way, a number of vendors are working hard to drive home the importance of open networking, particularly in the context of SDN. On the surface, open networking sounds like a good idea, but what do IT professionals really think about it?
Part of the challenge with discussing open networking is the confusion that results from the fact that in the IT industry we use the phrase open in different ways. As a point of reference, I will give an example of a closed system. My example system is comprised of both hardware and software — and the same company provides both. The company doesn’t publish the interface between the hardware and the software. One result of that approach is that, if you want to use that software, you have no choice in terms of the hardware you have to buy. While that approach may result in a highly functional, highly available system, it limits a buyer’s choices and it doesn’t enable anybody other than the company providing the system to add value.
Many vendors use the negative aspects of this hypothetical closed system to make the case for open networking in general, and for open protocols in particular. Part of the confusion that surrounds the phrase open protocols is that “open” is often equated with “interoperable”. To me, an open protocol is one that is designed by a recognized standards committee such as the IEEE or the IETF. Using that definition, OpenFlow is an example of an open protocol. So is OpenFlow interoperable? The answer is: it depends. Like most protocols, OpenFlow has required and optional features, but it also was designed in such a way as to enable vendors to extend the protocol. The result is that multiple vendors can support OpenFlow, but that doesn’t mean that their solutions will interoperate.
I recently published the first few chapters of an e-book on the topic of Network Virtualization and SDN. Chapter 2 of the e-book contains the results of a survey question in which the survey respondents were given a set of characteristics that are often associated with SDN and were asked to indicate which two characteristics would provide the most value to their company’s network. Forty-five percent of the survey respondents mentioned the centralization of configuration and policy management, while only ten percent of them mentioned open protocols. Just ten percent of respondents — hardly a ringing endorsement for the value of open protocols. The not-yet-published chapter 4 of the e-book contains another set of results: survey respondents were asked to indicate the type of SDN solution that their organization was likely to implement within the next two years. The possible responses focused on the use of open protocols and open source solutions. Less that half of the survey respondents who work for a company that will likely implement SDN within the next two years are currently committed to SDN solutions based on open source and open protocols — again, not exactly a ringing endorsement for open protocols and/or open source solutions.
At one of the recent SDN seminars produced by Network World I asked the attendees the value that they saw in open protocols. The general feeling was that if open protocols indeed did mean interoperable protocols, they liked the idea — but they didn’t love the idea. Their reservation was that sometimes a proprietary solution provides more value than does an open solution designed by committee.
The bottom line is that everything else being at least somewhat equal, IT professionals do indeed want to implement open networking solutions. However, those open networking solutions need to be robust enough to solve real problems, or else IT professionals will do what they have to do to solve those problems, even if that means implementing proprietary protocols.
Image credit: Shawn Rossi (flickr)
Jim has a broad background in the IT industry. This includes serving as a software engineer, an engineering manager for high-speed data services for a major network service provider, a product manager for network hardware, a network manager at two Fortune 500 companies, and the principal of a consulting organization. In addition, Jim has created software tools for designing customer networks for a major network service provider and directed and performed market research at a major industry analyst firm. Jim’s current interests include both cloud networking and application and service delivery. Jim has a Ph.D. in Mathematics from Boston University.