If you attended the Open Networking Summit or the Applied OpenFlow Symposium last month, you could see that Software-Defined Networking (SDN) is gaining a lot of momentum. There may still be some nuances on its definition but it is pretty clear that everyone sees a need for it.

For almost two decades, industry experts and hands-on networkers have worked hard creating protocols to solve L2/L3 issues. These issues were mainly around QoS, scalability, access control, security and mobility. However everyone is now agreeing that these protocols are reaching their limits. Causes are multiple.

The traffic between user and server, described as North-South traffic, is experiencing exponential growth. To allow better server utilization, applications that used to be delivered locally are now in the data center creating more network traffic overall to bring information to the place of consumption. And as we get hyper-connected, each of us increasingly accounts for more than ‘one place of consumption’ as we connect to applications from our laptops, home computers, tablets, smartphones, TVs, etc. Because most of the networking protocols defined over the past years were not designed with such change in mind, configuring and managing networks has significantly increased in complexity.

In parallel, we are seeing a surge in the traffic within the data center between servers, also referred to as East-West traffic. This is mainly due to more advanced, distributed and interwoven applications running on different servers. Think about all the servers involved in bringing you a LinkedIn page where you can see at once all your contacts, their presence information, people they recently added to their network, their last blogs and even job openings around your location. This all happens in a single click demanding faster, more dynamic network connectivity between applications. Again today’s network configuration tools are poorly suited to handle such requirements. Virtual switches were built to better handle East-West traffic. Unfortunately they only add to the overall complexity by increasing the risk of inconsistent configurations between virtual and physical networks.

While network managers should be able to focus on strategic projects, they end up spending most of their time configuring networks manually, with non-automated tools (still CLI based), and planning around exceptions in their network. They have to accomplish this with limited visibility on network utilization and with little ability to seamlessly and instantly roll back to previous configurations if a problem arises. This drastically contrasts with the application space and its advanced software tools allowing for complex problem solving via programming and automation.

This is where the concept of Software-Defined Networking comes in. SDN will simplify network configuration, management and troubleshooting and make networks programmable. At the Applied OpenFlow Symposium, Igor Gashinksy (Yahoo!) and Ed Crabble (Google) talked about how SDN could unlock the potential of their networks. Among others, they mentioned:

* Optimizing network resources (CPU and bandwidth) by removing the heavy workload like topology discovery processing from the local network elements
* Decoupling HW and SW release cycles at the switch level to allow for faster experimentation, innovation and deployment free of inter-dependencies
* Replacing manual configuration tools prone to error by software tools – making the network programmable
* Reducing the complexity of partitioning resources and delegating their associated management
* Taking a novel look at networking to increase its business relevance by making it more user-friendly

I will spend more time talking about specific networking problems that SDN can solve in future blogs. To ensure that I address what is on top of your mind, please don’t hesitate to share your networking challenges with me…