Everyone seems to believe that Software Defined Networks (SDN) is the future. They know it’s coming… whatever it is and whenever it gets here, but don’t really know what to do about it.
We talked to hundreds of attendees at the Open Network Summit (ONS) in Santa Clara and the Aruba Airheads Developers Conference in Las Vegas over the past two weeks about our SDN strategy. Most were familiar with the general concepts of SDN and knew what it is, at least in concept. Some had ideas about what they might do with it… some day. Few had specific plans to implement SDN or had even done any work with SDN yet.
At ONS, Brocade won the “2014 SDN Idol” award for best use case. We demonstrated DDoS (Distributed Denial of Service) mitigation with real-time SDN analytics that utilized OpenFlow, sFlow and Brocade’s hybrid HyperEdge™/OpenFlow implementation to identify and shutdown attacks quickly and efficiently. The use of SDN allows network administrators to configure and manage this all from the SDN controller rather than at a switch or port level.
During our [well-attended] breakout sessions we presented a description of SDN and how it simplifies network management – de-coupling the control plane from OpenFlow-enabled network devices. This, in turn, allow applications to manage services, such as setting QoS (quality-of-service) or resource allocations for critical applications, for the entire network rather than have to configure these per-port. Attendees saw the unlimited potential from SDN for simplification, automation and flexibility in network management.
Surprisingly we didn’t get a lot of question about “why SDN?” or even what we were developing for SDN. They seemed to accept SDN as inevitable. Instead, the most common questions from end-users, network engineers and integrators alike, were about how they should prepare for SDN. They were pleased to hear that Brocade was standardizing on support for OpenFlow 1.3 across our entire portfolio and about our unique approach to SDN hybrid mode on a per-port and/or per-flow basis. This meant that they would allow them to easily transition to SDN for specific capabilities or applications as they become available without having to make any changes to their existing network configurations or procedures. They were reassured that rip-and-replace wouldn’t be required for their networks to be SDN-ready with Brocade.
The other leading area of questions was about the skills that they would need for this new SDN-enabled network world. Indeed, it’s the “software” aspect of SDN that network engineers will need to learn. The standards organizations, such as Open Networking Foundation (www.opennetworking.org) and OpenDaylight (www.opendaylight.org) provide insights and resources available to get started.