Perfect is the enemy of good.
That’s an old saying. Confucius (551-479 BC) said, “Better a diamond with a flaw than a pebble without.” Aristotle (384-322 BC) said something similar. Voltaire popularized the phrase in the 1770s.
Software-defined networking, or SDN, has been defined as a mostly data-center-only technology.
There are various technologies for controlling data flows within a data center. But, they don’t translate well to the links between sites. Part of this is because it would usually require the rather expensive purchase of new WAN routers to replace existing hardware.
The Gartner group makes a distinction between fully programmable SDN as used within a data center with OpenFlow, versus Software-Defined WAN, or SD-WAN. By SD-WAN they mean a technology that supports:
Well, that last one is certainly different from OpenFlow, VMware NSX, Microsoft Hyper-V, and Cisco ACI!
Gartner estimates that SD-WAN has less than 1% market share today, but up to 30% of users will use SD-WAN within three years. As a Gartner analyst said, “SDN is an architecture, whereas SD-WAN is a technology you can buy.” The vendors bundle the most important features, wrap it in a simple interface, and sell it at relatively low cost.
The Metro Ethernet Forum selected VeloCloud’s “Cloud-Delivered SD-WAN” as the 2016 SDN Technology of the Year at their MEF16 conference. VeloCloud’s product has been cited in several articles about SD-WAN.
So, a globe-spanning SDN internetwork might be the perfect solution. But simplified SD-WAN links connecting SDN data centers are quite likely good enough for now.
Cisco is a relatively late adopter of SDN in a form that we generally think of as “real SDN”. They feel that their Application Centric Infrastructure, or ACI, is the best way to manage networks with control of forwarding at OSI Layers 2, 3, and 4.
ACI uses a declarative policy model. An application sends a request to an ACI controller. The request asks for a data flow between endpoints. It may ask for certain characteristics of throughput, latency, and priority. The controllers inform the switch fabric of what needs to happen, but not precisely how to make it happen.
The intelligence to set up these policy-forwarding tables resides within the switch fabric. The ACI switch fabric itself maintains its Layer 2 (MAC) and Layer 3 (IP) forwarding tables.
This is very different from OpenFlow, where all intelligence resides in the controller. An OpenFlow switch holds flow tables telling it how to forward based on Layers 2, 3, and 4. But if the controller crashes, the entire switch fabric quickly “goes dumb” and stops forwarding.
Yes, with OpenFlow you want multiple controllers, each of which is a cluster. Since the controllers are typically Linux systems, you might suddenly be more interested in the chapter of Learning Tree’s Linux server administration course where you learn about building high-availability clusters.
Maybe you already use Cisco Nexus 9000 and 1000 series switches. If so, ACI probably makes much more sense than trying to replace all that expensive hardware and move to OpenFlow.
Cisco has solutions for integrating WAN links with ACI fabric in data centers. See their white paper “Cisco ACI Fabric and WAN Integration with Cisco Nexus 7000 Series Switches and Cisco ASR Routers”. They explain how you can extend ACI control to the WAN edge devices, or not.
You might also be interested in ACG Research’s “Business Case for Cisco SDN for the WAN”. It takes a broader view of available choices and, as it title suggests, looks at the potential costs and returns on investment.