Summary Bullets:
- Do not expect anything claiming to be SDN to interoperate with other products. Make your vendor or VAR prove it.
- Each technology or product decision you make limits all the rest of the decisions you can subsequently make. Keep the dependencies in mind at all times.
Software-defined networking (SDN) will not make multi-vendor networking any easier. In fact, SDN will make multi-vendor networking more difficult, if not impossible to achieve. SDN is fragmenting along many dimensions such as overall architectures, protocol usage and orchestration integration. The result for vendors making network products such as firewalls, application delivery controllers, intrusion prevention systems, application performance monitoring and basic troubleshooting is that they have to expend development resources integrating with all of these protocols and products instead of adding new features or bringing new products to market.
So, SDN fragmentation has begun in earnest. Vendors are lining up behind architectures, such as controller and controller-less architectures; overlay technologies such as VXLAN, NVGRE or some other overlay protocol; programmable network protocols such as OpenFlow or Shortest Path Bridging with 802.1Qca Path Control and Reservation; platforms such as Alcatel-Lucent’s Nuage, Juniper’s Contrail, Midokura, Microsoft’s Hyper-V Network Virtualization, the OpenDaylight project, Open vSwitch, Plexxi or VMware’s NSX; and finally cloud platforms such as CloudStack, OpenStack and vCloud. Got all that? There will be a test later. (Lest someone waggles their finger at me, I didn’t forget SPB, TRILL, Cisco’s FabricPath or Brocade’s VCS Fabric. Those are an altogether different part of networking that is not specific SDN.)
The upshot is that if you select any particular networking vendor, your subsequent choices for an interoperable SDN quickly narrow to a few select vendors that have proven integration with each other. Do not expect that any two vendors claiming to support the same protocol, architecture or technology will actually interoperate until you get proof that the products actually do work together.
Protocols and open source projects are supposed to make ‘table stakes’ technology uniform and allow vendors to innovate in other layers, which in theory lifts everyone up. The reality is that the ramifications of technology choices any networking vendor makes in one aspect of SDN impacts every other decision you, the customer, can make. Sometimes those choices coincide because two products will interoperate together; other times the choices don’t coincide because another product doesn’t interoperate with the products already selected.
For example, your development team has been relying on features in a particular application delivery controller (ADC) but that particular ADC does not have proven interoperability with your SDN products. A difficult choice has to be made. Do you ditch your network or your ADC? Alternatively, you could acquire a new ADC that satisfies everyone, but now you have two different products to manage. You could hack around any limitations and hope everything eventually coalesces.
Before putting out a bid, be sure you have a clearly defined list of your dependencies and requirements. It will help your team or your VAR make better choices.
IT Connection 