It seems that software defined networking is on every network engineer's mind these days, and rightfully so. Ever since the introduction of OpenFlow in 2010, we have seen steady news on traditional networks transition to a software-defined network. The news typically focuses on the infrastructure agility as competitive advantage that the change brings. Many high profile SDN startups were formed offering new network services, such as SD-WAN. In the slower paced standards bodies, SDN standards were gradually being ratified. In the marketplace, vendors such as Quanta and Pica8 started to join forces in making carrier-grade hardware that was de-coupled from software. The combination of results is a seemingly new SDN world, just waiting around the corner for all networks to transition to. However, the reality is a bit different. Despite all the progress SDN have made, the technology deployment seems to be biased toward the very large, some might call Hyperscale, networks. Higher education research networks such as Internet2 and companies such as Google, Facebook, and Microsoft, all publicly release their SDN-driven projects, with many of them in detail and open source. But in the mid-tier service provider and enterprise space, there still remains to be a holding pattern.

What are the reasons causing this disparity? Every network is different, but let's take a look at some of the generalized reasons for not adapting SDN, and perhaps some counter arguments. First let's look at the argument of My network is too small to utilize the benefits of SDN.

It does not take a mathematician to figure out that larger networks have more network gears, and therefore can reap more benefits if they can save money or increase flexibility by moving to SDN. Each network is different and the degree of competitive advantage SDN can bring varies. However, if we believe that SDN is the correct path for the future, it is never too early to start planning.

In this chapter, I will offer some steps for the migration. These steps do not need to be executed at once; in fact, many of them need to be executed sequentially. But the steps, such as standardizing your network, will help you gain some benefits today. The second argument against SDN migration might be: The technology is not mature enough for production use.

It is true that the SDN technology is moving at a faster pace than its more mature counterparts, and being on the cutting edge can sometimes put you on the bleeding edge. It is no fun to commit to a technology only to replace it later. In this chapter, I wish to offer you some thoughts about segmenting parts of your network, so you can safely evaluate the technology without putting your production network at risk. We see that both small and large networks can benefit from SDN, and segmenting large networks into smaller networks would be beneficial. A possible third argument against SDN migration might be: I do not have enough engineering resources to invest in SDN.

The SDN projects, such as OpenFlow, have come a long way since their humble beginning as Stanford University research projects. The fact that you are reading this chapter might indicate that even though there are only limited resources, you do believe that there is some value in investing the time to learn the technology. Each technology is more or less an evolution rather than revolution process; the knowledge you invest time in learning today, will serve as a foundation for newer technology tomorrow, even if you do not use it today. Finally, one might argue that I do not have a transition plan to move to SDN.

In this chapter, I wish to address the transition path by calling the network a hybrid SDN network. We might have an aspiration to move from a traditional, vendor driven network to an automated software defined network, but the truth of the matter is that the migration will take time, effort, and monetary investment. During that transition time, the network still needs to be functional and the light still needs to be on. In this chapter, I will use OpenFlow and Ryu controller as an example of an SDN network that we eventually want to migrate to. We will look at some of the planning steps, technology, and points of discussion for a successful migration. I wish to offer some generalized suggestions and examples that might come in handy for your own network. If you are wondering about a successful migration, you need to look no further than Google. At the Open Networking Summit of 2017, the typically secretive Google detailed their migration from traditional network to OpenFlow-based WAN at G-Scale (http://opennetsummit.org/archives/apr12/hoelzle-tue-openflow.pdf). By some estimate in 2010, if Google was an ISP, it would be the second largest in the world. Very few of us operate at that scale, but it is comforting to know that migration is possible without disruption even for a network as large as Google's.

In particular, this chapter will focus on the following:

• Preparing the network for SDN and OpenFlow
• Greenfield deployment considerations
• Controller redundancy
• BGP interoperation
• Monitoring integration
• Controller to switch secure TLS connection
• Physical switch selection considerations

By the end of the chapter, you should be ready to take the next steps in bringing your traditional network into a software defined network.