Cisco Describes SDN Strategy, Sets Industry Back 10 Years

At Cisco Live on Tuesday, David Yen, SVP and GM of Cisco's data center technology group, and a supporting cast finally described Cisco's response to the SDN craze. Cisco's message was crafted to detail a highly useful direction for the Cisco faithful, and at the same time shows the company taking a deeply defensive position against the possibility that the technology could disrupt the networking leader's number one position in switching and routing.

Cisco's core proposition is that while the industry is abuzz with OpenFlow and SDN, what customers really want is programmability of the network. So, while OpenFlow and SDN are important developments, the real thing that will get customers excited, according to Cisco, is exposing all that intelligence that's already in the network and letting users program it. Rather than dealing with BGP and VLAN setups, just tell the network you want a connection between point A and point B, and describe your SLA. The underlying network will do the rest.

To that end, Cisco is offering onePK (or One Platform Kit), which is a software developer's kit that gets at a consistent set of APIs exposed on all of Cisco's current operating systems, IOS, IOS-XR and NX-OS. While onePK is only marginally related to SDN, it is, nonetheless welcome, particularly for all Cisco shops and those who've tried to develop networking management systems without such access. The lack of good API access has left network management vendors to use SNMP interfaces, which were not always well documented and varied across products. As a result, network management products have been hamstrung, leaving them to be little more than network monitoring applications. Now, with onePK, at least in an all Cisco environment, network management applications will have a shot at doing some serious management.

Cisco And Open Protocols

Cisco also announced support for OpenStack and OpenFlow. For OpenStack, which describes how to get servers, networking, and storage systems working together in a private cloud environment, Cisco will create the necessary APIs for the Nexus switches to participate in an OpenStack environment. Cisco also says it has some unnamed extensions in mind for OpenStack. For OpenFlow, which exposes a networking device's forwarding tables to programming by an outside controller, Cisco said it would support the standard, but primarily for the use of universities engaged in protocol research.

Of these two announcements, Cisco's OpenStack support appears to be quite sincere. Cisco seems to see OpenStack as a viable approach for use with its UCS servers. Cisco's joint venture with EMC and VMware, called VCE, is also a proponent of OpenStack. Cisco's rivals here, IBM and HP, are also both OpenStack adherents, which bodes well for the standard, and probably left Cisco no choice but to jump onboard.

What SDN Promises

So that's Cisco's view of customers want. But it's certainly far from the full story. One of the tenents of SDN is that it doesn't make a lot of sense for every single networking device to have all the smarts necessary for it to do its job. In fact, because of autonomous nature of switches, they can end up making forwarding decisions that might make sense to it, but are simply bad choices further down the road. A reasonable analogy is driving to work. You go the same way every day, but if three lanes of a four-lane road are closed one day, it would have made more sense for you to go a different route. If there was a central controller helping you--think of your navigation system, or Google Maps on steroids--you'd end up taking a better route that avoided the problem. The central controller has turned out to be a better way to manage wireless networks, where congestion or spectral noise can frequently cause localized problems.Cisco wants to rely on the smarts in the router and switch, in part because it's proven to work, and in very large part because most of the value add Cisco provides is in the smarts built into each of those boxes. In a pure SDN network, with the smarts kept somewhere else, the switches themselves quickly devolve into commodity products with commodity pricing. That is something no Cisco shareholder wants to hear about. So Cisco gives you "choice." You'll be able to take a Cisco switch, with all its built-in smarts, and use it in an SDN environment. Of course, if you do, you'll have paid for all that autonomous smart stuff, but you won't use it. In fact, you'll pay someone else for it.

Moving from the environment we have today to a fully SDN/Controller model is a huge transition--the sort that happens over a decade or more, with leaders like Google doing it right now, and the rest of figuring it out over time. What Cisco calls "choice"--meaning you can use the same gear in a controller-based network or an autonomous one--is really taking away one of the primary advantages the controller approach, that being cost savings. In an open standards controller environment, not only should the switches be dumb, and therefore cheap, they also must be highly compatible. There's no extensions, no added bells and whistles. Compatibility, performance, and reliability are what will distinguish vendors.

Now if you sell controllers, it's a different story. There will be lots and lots of ways to judge those systems, and a company like Cisco would obviously have quite an advantage there, but it's proprietary antics would largely have to work up the stack, and not back to down to the switches.

OnePK, while welcome, will also slow down the move to SDNs. First, competitors will have to respond, and it appears as though there's a lot to OnePK. Second, customers will have to determine if OnePK truly does meet their needs for network programmability, and if it does, they'll have to assess whether they really want to jump into a fully blown SDN where they'll have little expertise.

Cisco is good at staving off competition of any sort, so this response shouldn't be too surprising. Sure, it's protectionist, and sure, the industry could get to pervasive use of controllers much faster if Cisco was all in on the technology. But that was never likely to happen. Juniper and others aren't yet convinced they should modify their architecture either. Innovation is often a long hard path, and it just got a little bit longer for SDNs.

At this year's InformationWeek 500 Conference C-level execs will gather to discuss how they're rewriting the old IT rulebook and accelerating business execution. At the St. Regis Monarch Beach, Dana Point, Calif., Sept. 9-11.