Greg Ferro writes exceptionally well, is technologically knowledgeable, provides incisive commentary, and invariably makes cogent arguments over at EtherealMind. Having met him, I can also report that he’s a great guy. So, it is with some surprise that I find myself responding critically to his latest blog post on OpenFlow and SDN.
Let’s start with that particular conjunction of terms. Despite occasional suggestions to the contrary, SDN and OpenFlow are not inseparable or interchangeable. OpenFlow is a protocol, a mechanism that allows a server, known in SDN parlance as a controller, to interact with and program flow tables (for packet forwarding) on switches. It facilitates the separation of the control plane from the data plane in some SDN networks.
But OpenFlow is not SDN, which can be achieved with or without OpenFlow. In fact, Nicira Networks recently announced two SDN customer deployments of its Network Virtualization Platform (NVP) — at DreamHost and at Rackspace, respectively — and you won’t find mention of OpenFlow in either press release, though OpenStack and its Quantum networking project receive prominent billing. (I’ll be writing more about the Nicira deployments soon.)
A Protocol in the Big Picture
My point is not to diminish or disparage OpenFlow, which I think can and will be used gainfully in a number of SDN deployments. My point is that we have to be clear that the bigger picture of SDN is not interchangeable with the lower-level functionality of OpenFlow.
In that respect, Ferro is absolutely correct when he says that software-defined networking, and specifically SDN controller and application software, are “where the money is.” He conflates it with OpenFlow — which may or may not be involved, as we already have established — but his larger point is valid. SDN, at the controller and above, is where all the big changes to the networking model, and to the industry itself, will occur.
Ferro also likely is correct in his assertion that OpenFlow, in and of itself, will not enable “a choice of using low cost network equipment instead of the expensive networking equipment that we use today. “ In the near term, at least, I don’t see major prospects for change on that front as long as backward compatibility, interoperability with a bulging bag of networking protocols, and the agendas of the networking old guard are at play.
Cisco as Software Company
However, I think Ferro is wrong when he says that the market-leading vendors in switching and routing, including Cisco and Juniper, are software companies. Before you jump down my throat, presuming that’s what you intend to do, allow me to explain.
As Ferro says, Cisco and Juniper, among others, have placed increasing emphasis on the software features and functionality of their products. I have no objection there. But Ferro pushes his argument too far and suggests that the “networking business today is mostly a software business.” It’s definitely heading in that direction, but Cisco, for one, isn’t there yet and probably won’t be for some time. The key word, by the way, is “business.”
Cisco is developing more software these days, and it is placing more emphasis on software features and functionality, but what it overwhelmingly markets and sells to its customers are switches, routers, and other hardware appliances. Yes, those devices contain software, but Cisco sells them as hardware boxes, with box-oriented pricing and box-oriented channel programs, just as it has always done. Nitpickers will note that Cisco also has collaboration and video software, which it actually sells like software, but that remains an exception to the rule.
Talks Like a Hardware Company, Walks Like a Hardware Company
For the most part, in its interactions with its customers and the marketplace in general, Cisco still thinks and acts like a hardware vendor, software proliferation notwithstanding. It might have more software than ever in its products, but Cisco is in the hardware business.
In that respect, Cisco faces the same fundamental challenge that server vendors such as HP, Dell, and — yes — Cisco confront as they address a market that will be radically transformed by the rise of cloud services and ODM-hardware-buying cloud service providers. Can it think, figuratively and literally, outside the box? Just because Cisco develops more software than it did before doesn’t mean the answer is yes, nor does it signify that Cisco has transformed itself into a software vendor.
Let’s look, for example, at Cisco’s approach to SDN. Does anybody really believe that Cisco, with its ongoing attachment to ASIC-based hardware differentiation, will move toward a software-based delivery model that places the primary value on server-based controller software rather than on switches and routers? It’s just not going to happen, because it’s not what Cisco does or how it operates.
Missing the Signs
And that bring us to my next objection. In arguing that Cisco and others have followed the market and provided the software their customers want, Ferro writes the following:
“Billion dollar companies don’t usually miss the obvious and have moved to enhance their software to provide customer value.”
Where to begin? Well, billion-dollar companies frequently have missed the obvious and gotten it horribly wrong, often when at least some individuals within the companies in question knew that their employer was getting it horribly wrong. That’s partly because past and present successes can sow the seeds of future failure. As in Clayton M. Christensen’s classic book The Innovator’s Dilemma, industry leaders can have their vision blinkered by past successes, which prevent them from detecting disruptive innovations. In other cases, former market leaders get complacent or fail to acknowledge the seriousness of a competitive threat until it is too late.
The list of billion-dollar technology companies that have missed the obvious and failed spectacularly, sometimes disappearing into oblivion, is too long to enumerate here, but some names spring readily to mind. Right at the top (or bottom) of our list of industry ignominy, we find Nortel Networks. Once a company valued at nearly $400 billion, Nortel exists today only in thoroughly digested pieces that were masticated by other companies.
Is Cisco Decline Inevitable?
Today, we see a similarly disconcerting situation unfolding at Research In Motion (RIM), where many within the company saw the threat posed by Apple and by the emerging BYOD phenomenon but failed to do anything about it. Going further back into the annals of computing history, we can adduce examples such as Novell, Digital Equipment Corporation, as well as the raft of other minicomputer vendors who perished from the planet after the rise of the PC and client-sever computing. Some employees within those companies might even have foreseen their firms’ dark fates, but the organizations in which they toiled were unable to rescue themselves.
They were all huge successes, billion-dollar companies, but, in the face of radical shifts in industry and market dynamics, they couldn’t change who and what they were. The industry graveyard is full of the carcasses of company’s that were once enormously successful.
Am I saying this is what will happen to Cisco in an era of software-defined networking? No, I’m not prepared to make that bet. Cisco should be able to adapt and adjust better than the aforementioned companies were able to do, but it’s not a given. Just because Cisco is dominant in the networking industry today doesn’t mean that it will be dominant forever. As the old investment disclaimer goes, past performance does not guarantee future results. What’s more, Cisco has shown a fallibility of late that was not nearly as apparent in its boom years more than a decade ago.
Early Days, Promising Future
Finally, I’m not sure that Ferro is correct when he says Open Network Foundation’s (ONF) board members and its biggest service providers, including Google, will achieve CapEx but not OpEx savings with SDN. We really don’t know whether these companies are deriving OpEx savings because they’re keeping what they do with their operations and infrastructure highly confidential. Suffice it to say, they see compelling reasons to move away from buying their networking gear from the industry’s leading vendors, and they see similarly compelling reasons to embrace SDN.
Ferro ends his piece with two statements, the first of which I agree with wholeheartedly:
“That is the future of Software Defined Networking – better, dynamic, flexible and business focussed networking. But probably not much cheaper in the long run.”
As for that last statement, I believe there is insufficient evidence on which to render a verdict. As we’ve noted before, these are early days for SDN.
I have a lot of respect for Greg Ferro too. He does enough writing that its inevitable you’re going to love some of his posts, and strongly disagree with others. A testament to his success as blogger and influencer. That said, I think you’re spot on here Brad when you say that SDN is where the money is at, which may or may not have anything to do with OpenFlow.
In fact, I’m finding myself taking a more extreme position than that, where OpenFlow as a means for controlling the forwarding of physical switches will be largely irrelevant by the time its commercially viable. (I have the same opinion of TRILL).
I think, though, that part of Greg’s argument has to do with the fact that between “off-the-shelf” NPUs and FPGAs with pre-made IP libraries we see less hardware innovation in general coming out of the various network vendors. The differentiation will increasingly be software. In some cases, that is all the differentiation there is. Just have a look at the myriad variety of 1U switches and low-end routers that all basically use the same hardware.
Now take into account that Intel is piling many network and matrix friendly features into its CPUs and we see increasing use of GPUs as compute resources. Cisco must now compete with them as software turns ordinary servers into competitive packet-processing devices.
So whether or not Cisco “acts” like a software company… they are one. If they don’t start behaving like one, they are going to feel the pain. There are only so many providers in the world that need massive high-end routers and switches. The remaining 90% of organizations still need network gear. If they aren’t moving their stuff into the cloud that is… which I think many will. On that point, I disagree with Greg…
But not on the idea that traditional network vendors are software companies now whether they want to be or not.
Thanks for the reply. You make great observations above, especially the comment about software turning “ordinary servers into competitive packet-processing devices.”
That development, and the rise of programmable SDN, is potentially very disruptive, as we’re already seeing in the service-provider community.
First off, as a fellow blogger, I enjoy reading your posts–your effort and thoughtfulness comes through.
So, considering how nascent the whole field is, it always surprises me how much dogma there is with SDN already. Hopefully, at some point, folks will decide that SDN is not defined by a specific architecture or technology or protocol, but rather by a specific set of functionality and capability. Cloud went through similar growing pains and the conversations got considerably more productive once we got over that hump. Although, apparently, we still need to have periodic squabbles on public and private cloud.
As to whether we are a “software company”, perhaps a little clarity is in order as to what you mean by that. Are we like Oracle or Microsoft in that our business model is built around software revenue, then no. However, if you questioning if we are a company with deep software expertise, then I would argue yes. All that networking iron does not run itself and I think that is where the analogy with server vendors breaks down–they are only delivering half of a functioning server platform and depend on Microsoft, Red Hat et al to bring something to the table. In my response to Greg’s post, I noted we view ourselves as a systems company–to be successful, we will need to draw on both hardware and software expertise. A couple of years ago, we delivered a pure software switch with a distribute architecture with the Nexus 1000V, which I don’t think is too shabby. But, for the most part, we see hardware and OS as two halves of the whole and customers reap the greatest benefit when they are designed to work together.
As to if we are going to “miss” the boat, only time will tell. 🙂 However, if folks are counting on us being complacent or are blind to current or emerging trends, they will be disappointed. We have been pretty quiet up to this point with good reason, but you will see that changing. If you want to get an idea of where our heads are at around SDN and related topics, check out David Ward’s post today: http://blogs.cisco.com/news/is-it-just-sdn/#more-66168 and if folks happen to be at the Open Networking Summit this week, you can hear more from him on Wednesday afternoon. Oh, you might see a blog or two from me on the topic too. 🙂
Omar Sultan (@omarsultan)
Thank you for drawing the distinction between OpenFlow and SDN, the former is not required to get the later. Extensibility of the operating system is key to achieve either by allowing unfettered direct interaction with the OS and underlying hardware.
i am no expert on SDN or OpenFlow. What i find interesting is what this “disruption/innovation” may mean for the economics of the business and vendor marker shares. Economics would dictate lower revenue higher margin business (negative when it happens before turning positive longer term). Vendor market shares will be disrupted – incumbents losing share and attackers gaining share
Just filling out the vendor parade here… seriously tho +1 on the distinction between Openflow and SDN.
Juniper is a huge believer in SDN, network programibility, and whatever we all decide to call it next week. In my view, there are three ways SDN will change the landscape:
1. How a network is built. When we put a bunch of devices together, how do they behave and operate? Will the SDN be implemented under the covers and simply enable new capabilities ala QFabric or will it require lots of knob turning? (Greg’s opex argument)
2. How a network is managed. Let’s be honest, no network vendor has ever nailed the management problem and this area is ripe for innovation. The invasion of Linux geeks and programmers are already creating new controls on network operating systems based on FreeBSD (Junos) and Linux. Meanwhile, Nicira and a few others have already made some nice inroads on this front at higher levels of abstraction.
3. How the rest of the infrastructure interacts with the network. As Mark points out above, there is tremendous value to be had when the network has an API. See the Junos developer network and apps that range from inventory to service automation and video management.
It’s early. Clearly things will change, although with so many variables confusion will clearly reign for some time.
Reblogged this on CCIE 31104, what's next? and commented:
Great SDN / OpenFlow follow up article.
INOVATION YOU SAY . I would say NO Centralized adaptive algorithms more old than Internet and ARPA-a 🙂 and they have more issues than a teenage emo girl whose step-dad beats herr , im not wanna do the math for you 😉 it was do long time ago i can give many arguments but i tell only one What will happen when this central Controler going down or links over this CC going down 🙂 the whole network will go down :)) there is only Buzz becouse of 2 billion dolar companies wants to get more money for something that nobody needs I would say the this new king of yours is naked 🙂 its just new marketing name of old know thing