Key Factors to Consider Before Adopting an SDN Offering

by Chris Preimesberger

Off the top, let’s get real about software-defined networking: Even after a couple of years as a buzzword, it’s still more of a concept than a specific product, and that makes sorting out the vendor claims difficult. Let’s just describe it as networks moving from a provisioned to a programmable environment. Network administrators will have to become proficient at coding instead of manually manipulating network capacity. With that in mind, now you can look at the specifics.

There are a lot of O’s in SDN—even though you don’t see one in the acronym itself. Network admins need to know them all and define how they might work within their system. There is open source, OpenStack, Open Networking Foundation, Open Daylight, Open Compute, Open Networking User Group and OpenFlow—and that’s only a partial list of all the “opens” that are within the vocabulary of SDN.

Chasing and cataloging the O’s has become a major activity for network administrators, analysts and tech journalists, but the very concept of interoperability (which is what Interop stands for) is now challenged by the big O competition. If you leave it up to the vendors, you will only find more O’s vying for a place on your network. The user community will have to step up to end the O madness.

Think about the business objective and use cases for SDN. Leverage SDN to transform business models and improve operations. When considering on-demand networking, service providers need to build new pricing models for dynamic services. Everyone deploying SDN should ask, “How will I ensure SDN services are able to deliver strong operational efficiency?”

The networking skills you have are not the skills you will need for SDN. At a recent networking conference, a keynote speaker decried the bizarre situation of application development and deployment in a world where Google and Apple control the selection and deployment (and the revenue) of mobile applications. This leads to a world where companies have to build specific mobile apps for specific platforms and then spend dollars and help desk hours trying to keep track of platforms, versions and compatibility. The speaker contended that a strong emphasis on mobile virtualization would enable vendors to interact directly with customers—a concept that makes sense.

Closed ecosystems can lock you into a network architecture that won’t allow you to innovate or differentiate your services the way you need. Keep your network open to best-of-breed technologies regardless of vendor, including open northbound interfaces on your controller, open southbound interfaces to the networking equipment and a controller architecture that is open, such as OpenDaylight.

Look at vendors with leading positions in the key precursor technologies to SDN. Those with agile, feature-rich control-plane capabilities will likely be able to deliver on SDN.

The quality of SDN technologies varies greatly. Seek out a high-availability controller system that provides sufficient protection in case of controller server failure as well as network failure protection. With critical intelligence being shifted into the controller, confidence in the controller is essential. Pay close attention to solutions that understand shared risk link groups to ensure one fiber cut is not taking out the primary and backup paths. Vendors that have experience deploying in major networks should be prioritized.

The role of SDN is expanding through the network and into the WAN. Ensure that you are considering SDN for your full architecture—not just supporting packet layers, but layers 0 to 3. Multilayer SDN will enable a more efficient and agile implementation of SDN because the controller understands all technologies and the benefit/tradeoff of using each one to deliver a service.