Well, it seems like the SDN action never ends. We have two stories today; the SDN strategy that sort-of-was, and the SDN strategy that probably isn’t.
Let’s start with the “isn’t’. Cisco announced some optical enhancements to its CRS line, and what’s interesting about them is that they are aimed at an area where SDN technology is already active, and yet Cisco isn’t talking SDN when they chat up their latest optical-integration vision. They’ve jumped off the GMPLS starting point and done pretty much what they suggested they’d do, which is to achieve SDN goals using legacy technology were possible.
The question this raises is whether Cisco really has any desire to support the totality of SDN principles, which would include the elimination of distributed, adaptive, discovery-based forwarding in favor of central control. You can’t fairly say that you HAVE to do this to support SDN because it’s not at all clear what supporting SDN means (any more than it’s clear what the cloud is). It may be that Cisco sees what I’ve described above, which is a major evolution of the cloud, and also sees what I noted yesterday in my Juniper blog—that SDNs are the union of the cloud and the network. If progress toward achieving the cloud’s goals is difficult, then uniting it with the network is at least as hard. It may be that a proprietary strategy that bypasses all the disorder of the consensus process that hampers standards of any sort is the fastest path to market. It may be that Cisco is telling us it intends to take that path.
Now we come to our “sort-of” with HP. The company is an enterprise play in networking but a public cloud provider, supporter of OpenStack, and supplier of servers. It’s logical it would take some SDN position. HP had OpenFlow switches before, and what it now appears to be adding is an OpenFlow controller and some related software tools that can gather information from HP devices via a RESTful interface, then send OpenFlow commands that presumably will automate route-threading. The key element, the HP Virtual Application Networks SDN Controller (VANSDNC from now on!) is available either as an appliance or as software, and it fits into my SDN model in the same general way that the combination of the Topologizer, SDN Central, and the Cloudifier fit in combination.
The good news here is that HP appears to have taken the need for extra functionality above OpenFlow seriously, and they also say their approach extends beyond the data center to the network at large (to “the desktop” in their material). In their material they show an example of the VANSDNC linking to a cloud provisioning or DevOps framework as well as supporting “SDN applications” which are designed to specifically exploit SDN capabilities. Two initial ones include a cloud data center virtual network setup app and a security app.
The bad news is in all the qualifications like “apparently” and “say”. There is simply not enough material provided to get a full understanding of the potential of the products being announced. So while it seems that they can get topology and status information from the network using a pre-standard RESTful interface, it’s not clear whether “the network” means Ethernet, IP or a hybrid of both and whether it’s for HP only or for other vendors.
What’s missing, detail-wise? We have no specific picture of the functionality of the element of the VANSDNC that’s responsible for collecting topology data and creating a map of the network, or that responsible for converting that map to route information. Can it do path selection? If so based on what? What products, protocols, vendors, can contribute information to the map? If it’s HP only, then how can other network elements be introduced to create a complete topology? And when HP says it can extend SDNs to the desktop, what limits are there over the WAN services that might be involved?
There’s a lot of good here. I do like the notion of SDN applications. The HP binding material for their application virtual networking does suggest that HP is taking virtual networking from a pure multi-tenant play to an application segregation play, which I think is smart. But it’s hard to escape the notion that HP has built an SDN to suit its own cloud offerings, public and private, and not worried too much about SDNs in general. And, of course, the strategy can’t really address the WAN unless there’s some secret tool set involved. Thus, this is a good move, and one that will put pressure on competitors.
Like Cisco. HP takes some swipes at Cisco’s “looks like an SDN and quacks like an SDN but isn’t ever going to be one” positioning, and this may make things harder for Cisco as they try to fend off “real” SDN competitors in both the enterprise and carrier spaces.