Real-World Advice On SDN Migration

Networks are expensive, and organizations of all sizes are concerned about making the shift to software-defined networking (SDN), given the time and money they've invested in their current infrastructure. Organizations that embark on SDN want to ensure that the benefits of migration will exceed the risks involved.

One of the most common questions we hear about SDN migration at the Open Networking Foundation (ONF) is "How do I get there?" To help answer that question, ONF created the Migration Working Group almost a year ago.

The ONF Migration Working Group has spent the last year exploring a variety of SDN use cases in order to develop a collection of methods, metrics, tools, and best practices to help companies transition from their traditional networks to SDN using the OpenFlow protocol standard. 

There are currently three specific use cases that we've found very helpful for users who are considering migration:

Google's global user-based services are highly WAN-intensive due to the significant amount of data required to be moved from one region's datacenter to another, and the company concluded that delivery of its services couldn't be scalable with the technologies it had at the time. Google decided to use a 100% OpenFlow SDN for managing the WAN as a fabric, rather than a collection of boxes, to deploy centralized routing and traffic-engineering algorithms customized to the company's unique requirements. The target network has been in deployment for three years, and it carries more traffic than Google's public-facing WAN, with a higher growth rate.

Prior to its SDN migration, NTT used a traditional BGP deployment model. However, handling BGP state machines, processing BGP updates per configured policies, and calculating the best paths for each address family put a heavy load on NTT's routers. The company switched to a BGP-free edge, leveraging OpenFlow-based SDN to program the forwarding entries for data-plane traffic on its provider edge routers. NTT is now experiencing benefits including simplified and lower-cost routing edge architecture, accelerated deployment of new edge services, and better control of traffic patterns.

Stanford University migrated part of its campus network to support OpenFlow in 2010. Initially, the migration focused on wireless users. It then expanded to include select wired users in the 3A wing of its Gates Computer Science building and, later, multiple islands across two additional buildings. Each phase included one week of planning, one week of change, and six months of production use. Driving factors of this deployment included motivating the need for SDN through innovative experiments, understanding and verifying the new SDN technology, and contributing back to the OpenFlow specification and community.

Leveraging the experiences of these end users, ONF has identified and validated the top reasons for SDN migration, and has assembled best practices, guidelines, and processes for the transition. In addition, we've developed and recommend a planning framework for enterprises considering migration, which includes the following:

It is our hope that, through the experiences of other adopters, SDN users will realize that the process of network migration is feasible, realistic, and attainable. There are always risks associated with implementing and deploying new technology, but with risk comes reward -- in these cases a good one.

Emerging technologies are cutting costs and boosting setup speed and flexibility. IT's intrigued, our survey shows. Also in the How Cloud Will Transform The WAN issue of InformationWeek: Salesforce CEO Marc Benioff has a vision that needs a dose of reality. (Free registration required.)