Dan Pitt debunks the myths of SDN.
SDN is making great strides toward mainstream adoption; however, a few misconceptions about SDN persist. This is understandable – with change often come misunderstandings as the industry brings itself up to speed on new advances. To resolve some of the confusion surrounding SDN, I’d like to address a few of the most common misconceptions I’ve heard.
Myth One: SDN and NFV are similar methods with the same end goals.
Reality: SDN and NFV are two different technologies with overlapping outcomes, but they ultimately produce different results. By ONF’s definition, SDN is an emerging network architecture where network control is decoupled from forwarding and is directly programmable. According to SDx Central, NFV “decouples the network functions … from proprietary hardware appliances so they can run in software.” While these two definitions sound similar, they are not the same. Essentially, NFV allows network operators to convert appliances into virtual machines, letting ordinary servers run a variety of virtualized functions. This saves costs, computing power, and electricity, but it’s only a step toward a longer-term solution. SDN complements and supports NFV by providing the required cooperation within the data plane (even within a hypervisor) to steer and direct network traffic. Because of this, we see more long-term benefits when NFV and SDN are both deployed, further reducing OpEx and CapEx and improving network manageability. Nonetheless, while SDN and NFV are complementary, it is important to remember that one is not a proper subset of the other.
Myth Two: SDN’s centralized control plane is a single point of failure.
Reality: SDN’s centralized control plane manages and monitors network performance and functions, sending messages to switching elements in the forwarding plane while providing a consistent programming interface for system-wide policy and security. But because of its centralized nature, as explained in a recent ONF blog post by Ash Bhalgat of Luxoft, the control plane of an OpenFlow-based SDN architecture is inaccurately dubbed a single point of failure. In reality it’s logically centralized but not any more physically centralized than, say, the server that maintains your bank account. The advances made in the computing industry over the last fifteen years have proven that a logically centralized approach does not guarantee a single point of failure, and the risk can be mitigated with high availability systems. Distributed-systems software makes SDN possible.
Myth Three: Open SDN is just another industry buzzword.
Reality: Open SDN is the answer to the costly and inconvenient problem of vendor lock-in for network operators. The core principle underlying open SDN is that it is not controlled by a single party – as opposed to proprietary – giving end users more control through an open ecosystem with unprecedented choice. Open SDN supports and encourages interoperability among different vendors’ solutions, eliminating vendor lock-in and enabling network operators to build best-of-breed networks. And open SDN is not just a pipe dream. Apart from the many companies that are developing SDN solutions based on the OpenFlow® standard (many can be found here), our organization is working with additional industry associations, vendors, and end users to encourage a truly open, interoperable SDN marketplace from top to bottom, including well above the OpenFlow® substrate up to the northbound interfaces. Open SDN represents massive investment by both vendors and operators and is clearly the paradigm of the future; its realization is putting the power back into the hands of network operators.
Myth Four: Migrating to SDN is complicated, unattainable, and all or nothing.
Reality: Migration to SDN is completely attainable, and many are currently going through the process. My gosh, Stanford University demonstrated this five years ago by adding OpenFlow® switches one at a time to its network, moving traffic onto them gradually with no disruption to the production network. To more formally explain and ease the transition, our Migration Working Group has developed and continues to develop resources and best-practice guidelines that help ensure a smooth migration to accelerate the adoption of open SDN based on the experiences of those who have already made the transition. SDN implementation is not all or nothing, nor now or never, and it should be done in steps to ensure that small bumps don’t turn into big problems. I recommend checking out our “SDN Migration Considerations and Use Cases” and “Migration Tools and Metrics” documents for inspiration and suggestions to get started on the process.
The networking industry is making excellent progress in its transition to being based on software in general and SDN in particular. We will all reach our ultimate goal of making SDN the new norm for networks by embracing change and debunking misconceptions. There is no need to let the myths stand in the way between your company and SDN adoption. If you have any questions about SDN that you’re seeking answers to, feel free to ask in the comments below or via Twitter.
- Dan Pitt, Executive Director
