SDN buzz continues, but it’s my view that most of the stories coming out qualify for the “kiss the SDN baby” award; political theater. What’s happening is simply that SDN is hot, that vendors are afraid of being put at a competitive disadvantage for lack of SDN support, and so are moving to take the minimum steps necessary to claim support. That in most cases is implementing OpenFlow.
OpenFlow does not an SDN make. By itself, OpenFlow doesn’t even make a path for traffic to follow. All it does it let you update forwarding-table entries in a conformant device. The purpose of a forwarding table entry is to move traffic through a node, not a network. You still need path computation to do the latter. To do path computation you need topology, you need device and link state…you get the picture. We’ve talked about this particular issue before, but this month in Netwatcher we’re looking at the details of the SDN-to-network link in our treatment of the “Topologizer” element of the SDN of the future. That element (along with the “Cloudifier” and “SDN Central”) are essential in turning OpenFlow into an SDN. We haven’t heard about these above-OpenFlow features from anybody, including the new OpenFlow supporters.
Huawei, one of the recent OpenFlow fans, has also demonstrated a lack of SDN vision by initially pooh-poohing OpenFlow and SDN, only to be converted by the hot lights and glamour the market affords the concept. If there was ever a vendor who should have been leading the charge on SDN, Huawei was it. They are weakest in the areas where OpenFlow is the most destabilizing of competitors, and their prime competitor (Alcatel-Lucent) seems to be dragging its feet on OpenFlow. Cisco and Juniper, two other competitors, have narrower product lines and an SDN vision could have shined a spotlight on that fact by creating an integrated, multi-layer-evolution, vision of traffic handling. So far, though, Huawei is just SDN counterpunching.