Though the question has been frequently discussed and debated by press and analysts, my take is that “What Is Software-Defined Networking?” isn’t the right question to ask until you answer the question of what problems IT organizations are trying to solve for which an SDN solution is viable.
The whole brouhaha about the definition of SDN reminds me of a similar uproar about the definition of cloud computing that happened four or five years ago. Back then, some industry pundits were adamant that there was no such thing as private cloud computing. These pundits insisted that cloud computing meant one thing and one thing only — acquiring services from a third party such as SalesForce.com. Some pundits went so far as to state that not only was private cloud computing an oxymoron, but that all cloud services had to be accessed using the Internet.
At the time, these discussions about the definition of cloud computing struck me as being similar to a discussion of how many angels can dance on the head of a pin — absolutely fascinating, but totally divorced from reality. I say that because while this high level discussion was occurring, IT organizations that needed quick access to new applications started to acquire these applications from Software-as-a-Service providers and they usually, but not always, used the Internet for access. At the same time, IT organizations that wanted to experience the same efficiencies as the public cloud providers started their journey to private cloud by implementing server virtualization.
So, while some in the industry argue about whether or not an overlay network is an SDN and others argue whether or not OpenFlow is necessary or even relevant, IT organizations are moving forward, doing what they always do — solving problems and finding ways to add new value. As part of moving forward, many of the IT organizations that I talk to are trying to determine which, if any, of the varying approaches to SDN can help them solve the problems they are faced with on a daily basis. However, their approach is pragmatic — they focus first on the problem they are trying to solve because that influences what flavor of SDN solution they choose and which technologies they should use.
At Network World’s May 7th SDN seminar, the IT organizations that I talked to believed that the relevant problem that is of the most interest to them is centralizing configuration management and provisioning. That certainly is an often-talked-about use case for SDN. However, while SDN is an appropriate way to solve that problem, the OpenFlow protocol isn’t needed. XMPP and a variety of other protocols are just fine for this task.
While there isn’t yet a killer app driving SDN adoption, the closest we have is the need to implement virtual networks, in part to support the dynamic movement of VMs. IT organizations who want to implement virtual networks can do so either by implementing an SDN or by implementing network overlays. My suggestion is that these organizations focus on solving that problem and not get distracted by the noise in the industry about whether or not network virtualization using overlays is or is not an SDN. Who really cares??