Category Archives: Open Networking Foundation

VCs Weigh SDN’s Risks and Rewards

I’ve been thinking about a month-old post that Matthew Palmer wrote on the SDNCentral website.

In his post, Palmer considers that Arista, Insieme, and Vyatta were not financed by traditional venture capitalists. He further questions to what extent venture capitalists will plow money into the SDN space. He comes to the conclusion that it is “hard to believe there will be a large number of SDN startups being funded” by VCs.

My objective here is not to challenge Palmer’s conclusion, which seem about right. Instead, I want to examine his assumptions to see whether I can add anything to the discussion.

Slow-Growth Dead Zone

For a long time, VCs have eschewed the networking market. In recent years, Arista Networks emerged as the only new Ethernet-switching vendor to crash the established vendors’ party. Arista, as Palmer points out, was funded by its founders, not by VCs, who generally perceived networking, especially the enterprise variant, as a slow-growth dead zone controlled and dominated by Cisco Systems.

Meanwhile, the VCs had unfortunate experiences in the network-access control (NAC) market, where they sought to make bets in an area that was seen as peripheral to the big vendors’ wheelhouses.

As for SDN today, Palmer thinks most of the major VCs have done their bidding, and he believes Sequoia and Kleiner Perkins will fill out the field shortly. Beyond that, he doesn’t see much action.

Freeze Frame

He comes to that conclusion partly because of Cisco’s longstanding domination of the networking market. Writing that “Cisco learned a long time ago how to freeze markets and make markets look unattractive to competitors and investors,” Palmer believes the networking giant has put “everyone on notice” with its Insieme spin-in venture.  He believes Insieme, and whatever else Cisco does in SDN, will shut the door on SDN startups that aren’t already on the market with credible products and technologies that solve customer problems.

Perhaps VCs, as they have done in the recent past, will refrain from betting against the industry giant. That said, there already has been more VC activity in SDN than we’ve seen in network infrastructure for quite some time. In that respect, SDN demonstrably is different from the networking developments that have preceded it.

It’s different in others ways, too. I know I’ve hammered the same nail repeatedly in the past, but, at the risk of obsessive redundancy, I will do so again: The Open Networking Foundation (ONF) represents a powerful customer-driven dynamic that effectively challenges the vendor-led hegemony that has typified most networking markets and associated standards bodies. The ONF is run by and for service providers. Vendors are excluded from its board of directors, and their contributions are carefully circumscribed to conform with the dictates of the board.

Formidable Power

The catch is that the ONF is all about the needs and requirements of cloud service providers. The enterprise isn’t a primary consideration, though the development of enterprise-market demand for SDN products and technologies could further the strategic interests (economies of scale, innovation, vendor support, etc.) of the service-provider community.

Cisco is a formidable power, but it can’t impose its will on the ONF. In that respect, at least in the service-provider space, SDN is different from preceding network markets, such as Ethernet switching, which were basically incremental advancements in an established market model.

Call me crazy, but I believe that market and financial analysts should begin modeling scenarios in which the growth of SDN cuts into the service-provider revenues and margins of Cisco and Juniper. This will be particularly true in the cloud-service provider (IaaS) space initially, but it is likely to grow into other areas over time.

Enterprise Bulwark

The enterprise? That’s a tougher nut for SDN, for the reason I’ve cited earlier (ONF’s lack of an enterprise mandate), and for others as well. For starters, most enterprises don’t have the resources or the motivation (business case) to move away from networking models and relationships that have served them well.  As SDN evolves over time, that situation could change. For now, though, SDN is more a curiosity for enterprises than something they are considering for wholesale adoption.

Cisco and the other established networking vendors know the enterprise is safer ground for whatever SDN strategy or counterstrategy they present. In this respect, what Palmer terms “Insieme FUD” and other similar tactics are likely to be effective in the near term (the next two years.)

I really can’t quibble with Palmer’s conclusion — as I wrote above, it feels about right — but I think the VC investments we’ve seen heretofore in SDN already suggest that it is perceived differently from the linear networking markets that have preceded it.   I also believe there’s reason to think that SDN will lead to significant disruptions to the provision of networking solutions in the service-provider space.

How far can it go in the enterprise? For now, prospects are murky, but the game is in the early stages, and much will depend on how the SDN ecosystem evolves as well as on how effective Cisco and others are at leveraging the advantages of incumbency.

Why Established Networking Vendors Aren’t Leading SDN Charge

Expressing equal parts exasperation and incredulity, Greg Ferro wonders why industry-leading networking vendors aren’t taking the innovative initiative in offering compelling strategies for software-defined networking (SDN).

The answer seems clear enough.

Although applications will be critical to the long-term commercial success of SDN, Google and the other movers and shakers that direct the affairs of the Open Networking Foundation (ONF) originally were drawn to SDN because they were frustrated with the lack of responsiveness and innovation from established vendors. As a result, they devised a networking model that not only separated the control and data planes of network elements, but that also, in the word’s of Google’s Amin Vahdat, separated the “ evolution path for (network) hardware and software.”

Two Paths

Until now, those evolutionary paths have been converged and constrained inside the largely propriety boxes of networking vendors. Google and its confreres with the ONF perceived that state of affairs as the yoke of vendor oppression. The network, slow to evolve and innovate, was getting in the way of progress.  All the combustible ingredients of a cloud-service provider insurrection had cohered. Google, taking the lead in organizing the other major service providers under the rubric of the ONF, lit the fuse.

The effects of the explosion are just being felt, and the reverberations will echo for some time. The big service providers, and perhaps many smaller ones, are gravitating away from the orbit of networking’s ancien regime. The question now is whether enterprises will follow. At some point, that probably will happen, but how and when it will unfold are less clear. Enterprises, unlike the board members of the ONF, are too diverse and prolific to organize in pursuit of common interests. Accordingly, vendors are still able to set the enterprise agenda.

But enterprises will notice the benefits that SDN is capable of conferring, and the ONF’s overlords will seek to cultivate and sustain an ecosystem that can deliver parallel hardware and software innovation. Google, for example, has indicated that while it develops its own networking hardware today, it would be amenable to buying OpenFlow switches from the vendor community. Those switches, like to carry lower margins and prices than the gear sold by the major networking vendors, will probably come from ODMs using merchant silicon from Broadcom, Marvell, Fulcrum (Intel), and others.

Money’s in the Software

The major networking vendors are saying that the cleavage of the control and data planes is not a big deal, that it’s not necessary or isn’t a critical requirement for innovation and network programmability. Perhaps there is some merit to their arguments, but there’s no question that the separation of the control and data planes is not in their business interests. If some their assertions have merit, they also are self-serving.

Cisco, as we’ve discussed before, might be able to develop software, but its business model is predicated on the sale of routers and switches. Effectively, it would have to remake itself comprehensively to recast itself as a vendor of server-based controllers (software) and the applications the run on them. A proprietary hardware box, whether a server or switch, isn’t what the ONF wants.

If the ONF’s SDN vision prevails, the money is in software: server-based controllers, applications, management/orchestration frameworks, and so on. Successful vendors not only will have to be proficient at developing software; they’ll also have to be skilled at marketing and selling it. They’ll have to build their businesses around it.

This is the challenge the major networking vendors confront. It’s why they aren’t leading the SDN charge, and it also is why they are attempting to co-opt and subvert it.

Putting an ONF Conspiracy Theory to Rest

We know that the Open Networking Foundation (ONF) is controlled by the six major service providers that constitute its board of directors.

It is no secret that the ONF is built this way by design. The board members wanted to make sure that they got what they wanted from the ONF’s deliberations, and they felt that existing standards bodies, such as the IETF and IEEE, were gerrymandered and dominated by vendors with self-serving agendas.

The ONF was devised with a different purpose in mind — not to serve the interests of the vendors, but to further the interests of the service-provider community, especially the service providers who sit on the ONF’s board of directors. In their view, conventional networking was a drag on their innovation and business agility, obstructing progress elsewhere in their data centers and IT operations. Whereas compute and storage resources had been virtualized and orchestrated, networking remained a relatively costly and unwieldy fiefdom ruled by “masters of complexity” rummaging manually through an ever-expanding bag of ad-hoc protocols.

Organizing for Clout

Not getting what they desired from their networking vendors, the service providers decided to seize the initiative. Acting on its own,  Google already had done just that, designing and deploying DIY networking gear.

The study of political elites tells us that an organized minority comprising powerful interests can impose its will on a disorganized majority.  In the past, as individual companies, the ONF board members had been unable to counter the agendas of the networking vendors. Together, they hoped to effect the change they desired.

So, we have the ONF, and it’s unlike the IETF and the IEEE in more ways than one. While not a standards body — the ONF describes itself as a “non-profit consortium dedicated to the transformation of networking through the development and standardization of a unique architecture called Software-Defined Networking (SDN)” — there’s no question that the ONF wants to ensure that it defines and delivers SDN according to its own rules  And at its own pace, too, not tied to the product-release schedules of networking vendors.

In certain respects, the ONF is all about consortium of customers taking control and dictating what it wants from the vendor community, which, in this case, should be understood to comprise not only OEM networking vendors, but also ODMs, SDN startups, and purveyors of merchant silicon.

Vehicle of Insurrection?

Just to ensure that its leadership could not be subverted, though, the ONF stipulated that vendors would not be permitted to serve on its board of directors. That means that representatives of Cisco, Juniper, and HP Networking, for example, will never be able to serve on the ONF board.

At least within their self-determined jurisdiction, the ONF’s board members call all the shots. Or do they?

Commenting on my earlier post regarding Cisco’s SDN counterstrategy, a reader, who wished to remain anonymous (Anon4This1), wrote the following:

Regarding this point: “Ultimately, [Cisco] does not control the ONF.”

That was one of the key reasons for the creation of the ONF. That is, there was a sense that existing standards bodies were under the collective thumb of large vendors. ONF was created such that only the ONF board can vote on binding decisions, and no vendors are allowed on the board. Done, right? Ah, well, not so fast. The ONF also has a Technical Advisory Group (TAG). For most decisions, the board actually acts on the recommendations of the TAG. The TAG does not have the same membership restrictions that apply to the ONF board. Indeed, the current chairman of the TAG is none other than influential Cisco honcho, Dave Ward. So if the ONF board listens to the TAG, and the TAG listens to its chairman… Who has more control over the ONF than anyone? https://www.opennetworking.org/about/tag

Board’s Iron Grip

If you follow the link provided by my anonymous commenter, you will find an extensive overview of the ONF’s Technical Advisory Group (TAG). Could the TAG, as constituted, be the tail that wags the ONF dog?

My analysis leads me to a different conclusion.  As I see it, the TAG serves at the pleasure of the ONF board of directors, individually and collectively. Nobody on the TAG does so without the express consent of the board of directors. Moreover, “TAG term appointments are annual and the chair position rotates quarterly.” Whereas Cisco’s Dave Ward serves as the current chair, his term will expire and somebody else will succeed him.

What about the suggestion that the “board actually acts on recommendations of the TAG,” as my commenter asserts. In many instances, that might be true, but the form and substance of the language on the TAG webpage articulates clearly that the TAG is, as its acronym denotes, an advisory body that reports to (and “responds to requests from”) the ONF board of directors.  The TAG offers technical guidance and recommendations, but the board makes the ultimate decisions. If the board doesn’t like what it’s getting from TAG members, annual appointments presumably can be allowed to expire and new members can succeed those who leave.

Currently, two networking-gear OEMs are represented on the ONF’s TAG. Cisco is represented by the aforementioned David Ward, and HP is represented by Jean Tourrilhes, an HP-Labs researcher in Networking and Communication who has worked with OpenFlow since 2008. These gentlemen seem to be on the TAG because those who run the ONF believe they can make meaningful contributions to the development of SDN.

No Coup

It’s instructive to note the company affiliations of the other six members serving on TAG. We find, for instance, Nicira CTO Martin Casado, as well as Verizon’s Dave McDysan, Google’s Amin Vahdat, Microsoft’s Albert Greenberg, Broadcom’s Puneet Agarwal, and Stanford’s Nick McKeown, who also is known as a Nicira co-founder and serves on that company’s board of directors.

If any company has pull, then, on the ONF’s TAG, it would seem to be Nicira Networks, not Cisco Systems. After all, Nicira has two of its corporate directors serving on the ONF’s TAG. Again, though, both gentlemen from Nicira are highly regarded and esteemed SDN proponents, who played critical roles in the advent and development of OpenFlow.

And that’s my point. If you look at who serves on the ONF’s TAG, you can clearly see why they’re in those roles and you can understand why the ONF board members would desire their contributions.

The TAG as a vehicle for an internal coup d’etat at the ONF? That’s one conspiracy theory that I’m definitely not buying.

SDN Controller Ecosystems Critical to Market Success

Software-defined networking (SDN) is a relatively new phenomenon. Consequently, analogies to preceding markets and technologies often are invoked by its proponents to communicate key concepts. One oft-cited analogy involves the server-based solution stack and the nascent SDN stack.

In this comparison, server hardware equates to networking hardware, with the CPU instruction set positioned as analogous to the OpenFlow instruction set. Above those layers, the server operating system is said to be analogous to the SDN controller, which effectively runs a “network operating system.” Above that layer, the analogy extends to similarities between server OS and network OS APIs and to the applications that run atop both stacks.

Analogies and Implications

Let’s consider the comparison of the server operating system to the SDN controller.  While the analogy is apt, it carries implications that prospective early adopters of SDN need to fully understand. As we’ve discussed before, SDN controllers based on OpenFlow today carry no guarantees of interoperability. An application that runs on one controller might not be available (or run) on another controller, just as an application developed for a Windows server might not be available on Linux (and vice versa).

Moreover, we don’t know how difficult it will be to port applications from one OpenFlow-based controller to another. It could be a trivial exercise or an agonizing one. There are many nagging questions, far fewer answers.

Keep in mind that this is an entirely different matter from the question of interoperability between OpenFlow-based controllers and switches. Presuming the OpenFlow standard is adhered to and implemented correctly in all cases, OpenFlow-based controllers on the market today should be able to communicate with OpenFlow-based switches.

But interoperability (or lack thereof) is an unwritten book at the layers where the SDN controller (an NOS akin to a server-based operating system) and the NOS APIs reside.  The poses a potential problem for the market development of a viable SDN ecosystem, at least for the enterprise market. (It’s not as much of an issue for the gargantuan service providers that drive the agenda of the Open Network Foundation; those companies have ample resources and will make their own internal standardization decisions relating to controllers and practically everything else that falls under the SDN rubric.)

Controller Derby

At SDNCentral, no fewer than seven open-source OpenFlow controllers are listed. Three of those controllers are Java based: Beacon, Floodlight, and Jaxon. The other open-source OpenFlow controllers listed at SDNCentral are FlowER, NodeFlow, POX, and Trema.  Additionally, OpenFlow controllers have been developed by several companies, including NEC, BigSwitch Networks (which offers a commercial version of the Floodlight controller), and Nicira Networks, which has built on the foundation of the Onix controller.

Interestingly, Google and Ericsson also have based their controllers on Onix. In a blog post last summer, Nicira CTO Martin Casado described Onix as a “general SDN controller” rather than an OpenFlow controller. Casado admitted that he was devising terminology on the fly, but he defined a “general SDN controller as “one in which the control application is fully decoupled from both the underlying protocol(s) communicating with the switches, and the protocol(s) exchanging state between controller instances (assuming the controllers can run in a cluster).” So, OpenFlow could be part of the picture, but it doesn’t have to be there; another mechanism could substitute for it.

Casado conceded that Onix is the right controller for many environments, but not for others. Wrote Casado:

There have been multiple control applications built on Onix, and it is used in large production deployments in the data centers, as well as in the access and core networks. However, it is probably too heavyweight for smaller networks (the home or small enterprise), and it is certainly too complex to use as a basic research tool.

Horses for Courses

So, there are horses for courses, and there are controllers for applications. Early indications suggest that it will not be a one-size-fits-all world. Nonetheless, at the end of his blog post, Casado expressed that opinion that “standards should be kept away” from controller design, and that the market’s natural-selection process should be allowed to run its course.

Perhaps that is the right prescription. It seems too early for leaden-footed standards bodies, such as the IETF and IEEE, to intervene. Nevertheless, customers will have to be wary. They’ll have to do their research, perform due diligence, and thoroughly understand the strengths, weaknesses, and characteristics of candidate controllers. Without assured controller interoperability, customers that adopt and deploy applications on one controller might have considerable difficulty shifting their investment and their software elsewhere.

Of course, if Google and the other major service providers who rule the roost at ONF want to expedite matters, they could publicly and aggressively endorse one or two controller platforms as de facto standards. But that’s probably unlikely, for a variety of reasons. Even if it were to happen, as Casado points out, any controller that proves favorable at large cloud service providers might not be the best choice for enterprises, especially smaller ones.

Opening for Networking’s Old Guard

At this point, it’s not clear how the SDN controller market will shake out. SDN controllers will struggle for sustenance not only against each other, but also against networking’s conventional distributed control planes already on the market, as well as so-called hybrid approaches — whereby the data path is jointly controlled by the conventional box-based control planes as well as by server-based controllers — that will be articulated and promoted by the major networking vendors, all of whom are keen to retard “pure SDN’s” advance from the environs of the largest cloud service providers to those of enterprise buyers. (As mentioned previously, the hybrid-control approach also is perceived by the ONF as a transitional necessity for customers seeking to move from their networks as they are constituted today to future SDN architectures.)

In that regard, the big networking powers are fortunate that the ONF’s early mandate is focused primarily, if not exclusively, on the requirements of the large cloud-service providers that populate its board of directors. The ambiguity surrounding controllers and their interoperability (or lack thereof) represents another factor that will dissuade enterprise buyers from taking an early leap of faith into the arms of SDN purveyors.

The faster the SDN market sorts out a controller hierarchy — determining the suitability and market prevalence of certain controllers in specific application environments — the sooner valuable ecosystems will form and enterprises will take serious notice.

For now, though, a shakeout doesn’t appear imminent.

Distributed, Hybrid, Northbound: Key Words in Cisco’s SDN Counterstrategy

When it has broached the topic of software-defined networking (SDN) recently, Cisco has attempted to reframe the discussion within the larger context of programmable networks. In Cisco’s conception of the evolving networking universe, the programmable network encompasses SDN, which in turn envelops OpenFlow.

We know by now that OpenFlow is a relatively small part of SDN. OpenFlow is a protocol that provides for the physical separation of the control and data planes, which heretofore have been combined within a switch or router. As such, OpenFlow enables server-based software (a controller) to determine how packets should be forwarded by network elements. As has been mentioned before, here and elsewhere, mechanisms other than OpenFlow could be used for the same purpose.

Logical Outcome

SDN is bigger than OpenFlow. It deals not only with the abstraction of the data plane, but also with higher-layer abstractions, at the control plane and above. The whole idea behind SDN is to put the applications, and the services they deliver, in the driver’s seat, so that the network does not become a costly encumbrance that impedes business agility and operational efficiency. In that sense, Cisco is right to suggest that programmable networks are a logical outcome that can and should result from the rise of SDN.

That said, the devil can always be found in the details, and we should note that Cisco’s definition of SDN, to the extent that it might invoke that acronym rather one of its own, is at variance with the definition that has been proffered by the Open Networking Foundation (ONF), which is controlled by the world’s largest cloud-service providers rather than by the world’s largest networking vendors. Cisco’s understanding of SDN looks a lot more like conventional networking, with a distributed or hybrid control plane instead of the logically centralized control plane favored by the ONF.

This post isn’t about value judgments, though. I am not here to bash Cisco, or anybody else for that matter, but to understand and interpret Cisco’s motivations as it formulates a counterstrategy to the ONF’s plans.

Bog-Standard Switches

Given the context, then, it’s easy to understand why Cisco favors the retention of the distributed — or, failing that, even a hybrid — control plane. Cisco is the market leader in switches and routers, and it owns a lot of valuable real estate on its customers’ networks.  If OpenFlow succeeds, not only in service-provider networks but also in the enterprise, Cisco is at risk of losing the market dominance it has worked so long and hard to build.

Frankly, there isn’t much differentiation to be achieved in bog-standard OpenFlow switches. If the Googles of the world get their way, the merchant silicon vendors all will support OpenFlow on their chipsets, and industry-standard boxes will be available from a number of ODMs and OEMs. It will be a prototypical buyer’s market, perhaps advancing quickly toward commoditization, and that’s not a prospect that Cisco shareholders and executives wish to entertain.

As Cisco comes to grips with SDN, then, it needs to rediscover the sort of leverage that it had before the advent of the ONF.  After all, if SDN is all about putting applications and other software literally in control of networks composed of industry-standard boxes, then network hardware will suffer a significant margin-squeezing demotion in the value hierarchy of customers.  And Cisco, as we’ve discussed before, develops more than its fair share of software, but remains a company wedded to a hardware-based business model.

Compromise and Accommodation 

Cisco would like to resist and undermine any potential market shift to the ONF’s server-based controllers. Fortunately for Cisco, many within the ONF are willing to acquiesce, at least initially and up to a point. A general consensus seems to have developed about the need for a hybrid control plane, which would accommodate both logically centralized controllers and distributed boxes. The ONF’s braintrust sees this move as a necessary compromise that will facilitate a long-term transition to a server-based model. It seems a logical and rational deduction — there’s a lot of networking gear installed out there that does not support the ONF’s conception of SDN — but it’s an opening for Cisco, nonetheless.

Beyond the issue of physical separation of the data plane and the control plane, Cisco has at least one other card to play.  You might have noticed that Cisco representatives have talked a lot during the past couple months about a “northbound interface” for SDN. As currently constituted, OpenFlow is a “southbound” interface, in that serves as a mechanism for a controller to program a switch. On a network diagram, that communication flows downward (hence southbound).

In SDN, a northbound interface would go upward, extending from the switch to the control plane and potentially beyond to applications and management/orchestration software. This is a discussion Cisco wants to have with the industry, at the ONF and elsewhere. Whereas southbound interfaces are all about what is done to a switch by external software, the northbound interface is a conduit by which the switch confers value — in the form of information intrinsic to the network — to the higher layers of abstraction.

Northbound Traffic

For now, the ONF has chosen not to define standard protocols or APIs for northbound interfaces, which could run from the networking devices up to the control plane and to higher layers of abstraction. Cisco, as the vendor with the largest installed base of gear in customer networks, finds itself in a logical position to play a role in helping to define those northbound interfaces.

Ideally, if programmable networks and SDN fulfill their potential, we’ll see the development of a virtuous feedback loop at the highest layers of abstraction, with software programming an underlying virtualized network and the network sending back state and other data that dynamically allows applications to perform even better.

Therefore, the northbound interface will be an important element in the future of SDN. Cisco hopes to leverage it, but more for the sustenance of its own business model than for the furtherance of the ONF’s objectives. Cisco holds some interesting cards, but it should be careful not to overplay them. Ultimately, it does not control the ONF.

As the SDN discourse elevates beyond OpenFlow, watch the traffic in the northbound lanes.

Why Google Isn’t A Networking Vendor

Invariably trenchant and always worth reading, Ivan Pepelnjak today explores what he believes Google is doing with OpenFlow. As it turns out, Pepelnjak posits that Google is doing more with other technologies than it is with OpenFlow, seemingly building a modern routing platform and a traffic-engineering application deserving universal envy and admiration.

In assessing what Google is doing, Pepelnjak would seem to get it right, as he usually does, but I would like to offer modest commentary on a couple minor points. Let’s start with his assessment of how Google is using OpenFlow:

“Google is using OpenFlow between controller and adjacent chassis switches because (like every other vendor) they need a protocol between the control plane and forwarding planes, and they decided to use an already-documented one instead of inventing their own (the extra OpenFlow hype could also persuade hardware vendors to implement more OpenFlow capabilities in their next-generation chipsets).”

OpenFlow: Just A Piece of the Puzzle

First off, Pepelnjak is essentially right. I’m not going to quarrel with his central point, which is that Google adopted OpenFlow as a communication protocol between (and that separates) the control plane and the forwarding plane. That’s OpenFlow’s purpose, its raison d’être, so it’s no surprising that Google would use it that way. As Chris Rock might say, that’s what OpenFlow is supposed to do.

Larger claims made on behalf of OpenFlow are not its fault. Subsequently, Pepelnjak states that OpenFlow is but a small piece of the networking puzzle at Google, and he’s right there, too. I don’t think it’s possible for OpenFlow to be a bigger piece. As a protocol between the control and forwarding planes, OpenFlow is what it is.

Beyond that, though, Pepelnjak refers to Google as a “vendor,” which I find odd.

Not a Networking Vendor

In many ways, Google is a vendor. It’s a cloud vendor, it’s an advertising vendor, it’s a SaaS vendor, and so on. But, in this particular context, Pepelnjak seems to be classifying Google as a networking vendor. That would be an incorrect designation, and here’s why: Vendors sell things, they vend. Google doesn’t sell the homegrown networking hardware and software that it implements internally. It’s doing it only for itself, not as a business proposition that would involve it proffering the technology to customers. As such, it should not be tossed into the same networking-vendor bucket as a Cisco, a Juniper, or an HP.

In fact, Google is going the roll-your-own route with its network infrastructure precisely because it couldn’t get what it wanted from networking vendors. In that respect, it is the anti-vendor. Google and the other gargantuan cloud-service providers who steer the Open Networking Foundation (ONF) promulgated software-defined networking (SDN) and espoused OpenFlow because they wanted network infrastructure to be different from the conventional approaches advanced by networking vendors and the traditional networking industry.

Whatever else one might think of the ONF, it’s difficult not to conclude that it represents an instance of customers (in this case, cloud-service providers) attempting to wrest strategic control from vendors to set a technological agenda. Google, a networking vendor? Only if one misunderstands the origins and purpose of ONF.

Creating a Market

Nonetheless, Google might have a hidden agenda here, and Pepelnjak touches on it when he writes parenthetically that “the extra OpenFlow hype could also persuade hardware vendors to implement more OpenFlow capabilities in their next-generation chipsets.”

Well, yes. Just because Google has chosen to roll its own and doesn’t like what the networking industry is selling today, it doesn’t necessarily mean that it has closed the door to buying from vendors in the future, presuming said vendors jump on the ONF bandwagon and start developing the sorts of products Google wants. Google doesn’t want to disclose the particulars of its network infrastructure, which it views as a source of competitive advantage and differentiation, but it is not averse to hyping OpenFlow in a bid to spur the supply side of the market to get with the SDN program.

Later in his post, Pepelnjak notes that Google used “standard protocols (BGP and IS-IS) like everyone else and their traffic engineering implementation (and probably the northbound API) is proprietary. How is that different (from the openness perspective) from networks built from Juniper’s or Cisco’s gear?”

Critical Distinction

Again, my point is that Google is not a vendor. It is customer building network technologies for its own use. By the very nature of that implicit (non)-transaction, the technologies in question will be proprietary. They’re not going anywhere other than Google’s data-center network. Google owns them, and it is in full control of defining them and releasing them on a schedule that suits Google’s internal objectives.

It’s rather different for vendors, who profit — if they’re doing it right — from the commercial sale of products and technologies to customers. There might be value in proprietary products and technologies in that context, but customers need to ensure that the proprietary value outweighs the proprietary risks, typically represented by vendor lock-in and upgrade cycles dictated by the vendor’s product-release schedule.

Google is not a vendor, and neither are the other companies driving the agenda of the ONF. I think it’s critical to make that distinction in the context of SDN and, to a lesser extent, OpenFlow.

IRTF Considers SDN

For a while now, the Internet Engineering Task Force (IETF) has been looking for a role to play in relation to software defined networking (SDN).

Even as the IETF struggles to identify a clear mandate for itself as a potential standards arbiter for SDN, the Internet Research Task Force (IRTF) appears ready to jump into fray. The IRTF doesn’t conflict with the IETF, so its involvement with SDN would be parallel and ideally complementary to anything the IETF might pursue.

Both the IETF and IRTF  are overseen by the Internet Architecture Board (IAB). Whereas the IETF is mandated to focus on shorter-term issues involving engineering and standards, the IRTF focuses on longer-term Internet research.

Hybrid SDN Models

Cisco Systems’ David Mayer has drafted a proposed IRTF charter for the Software Defined Networking Research Group (SDNRG). It features an emphasis on hybrid SDN models, “in which control and data plane programability works in concert with existing and future distributed control planes.”

The proposed charter also states that the SDNRG will provide “objective definitions, metrics and background research, with the goal of providing this information as input to protocol, network, and service design to SDOs and other standards producing organizations such as the IETF, ITU-T, IEEE, ONF, MEF, and DMTF.”

How the research of the IRTF and the eventual standards activity of the IETF conform or diverge from the work of the Open Networking Foundation (ONF) will be interesting to monitor. The ONF is controlled exclusively at the board level by cloud service providers, whereas vendors will be actively steering the work of the IETF and IRTF.

What the Battle for “SDN” Reveals

As Mike Fratto notes in an excellent piece over at Network Computing, “software-defined networking” has become a semantical battleground, with the term getting pushed and pulled in various directions.

For good reason, Fratto was concerned that the proliferating definitions of software-defined networking (SDN) were in danger of shearing the term of all meaning. He compared what was happening to SDN to what happened previously to terms such as cloud computing, and he opined that once a term means anything, it means nothing.

Setting Record Straight

Not wanting to be passive observer to such linguistic nihilism, Fratto decided to set the record straight. He rightly observes that software-defined networking (SDN), as we understand it today, derives its provenance from the Open Networking Foundation (ONF). As such, the ONF’s definition of SDN should be the one that holds sway.

Citing an ONF white paper, “Software-Defined Networking:  The New Norm for Networks,” Fratto notes that, properly understood, SDN emphasizes three key features:

  • Separation of the control plane from the data plane
  • A centralized controller and view of the network
  • Programmability of the network by external applications

Why the Fuss?

I agree that the ONF’s definition is the one that should be authoritative and, well, definitive. What other vendors are doing in areas such as network virtualization and network programmability might be interesting — and perhaps even commendable and valuable to their customers — but unless what they are doing meets the ONF criteria, it should not qualify as SDN.  Furthermore, if what they’re doing doesn’t qualify as SDN, they should call it something else and explain its architectural principles and value clearly. An ambiguous, perhaps even disingenuous, linkage with SDN ought to be avoided.

What Fratto does not explore is why certain parties are attempting to muddy the SDN waters. In my experience, when vendors contest terminology, it suggests the linguistic real estate in question is uncommonly valuable, either strategically or monetarily. I posit that SDN is both.

Like “cloud” before it, everybody seemingly recognizes that SDN has struck a resounding chord. There’s hype attached to SDN, sure, but it also has genuine appeal and has generated considerable interest. As the composition of the ONF’s board of directors has suggested, and as the growing number of cloud service-provider deployments attest, SDN is not a passing fad. At least in the large cloud shops, it already has practical utility and business value.

The Value of Words

That value is likely to grow over time, and, while the enterprise will be a tough nut to crack for more than one reason, it’s certainly conceivable that the SDN eventually will find favor among at least certain enterprise demographics. The timeline for that outcome is not imminent, and, as I’ve written previously, Cisco isn’t about to “do a Nortel” and hold a going-out-of-business sale. Nonetheless, the auguries suggest that the ONF’s SDN will be with us for a long time and represents a significant business threat to networking’s status quo.

In this context, language really is power. If entrenched interests — such as the status quo of networking — don’t like an emerging trend, one way they can attempt to derail it is by co-opting it or subverting it. After all, it’s only an emerging trend, not yet entrenched, so therefore its terminology is nascent, too. If, as a major vendor with industry clout, you can change the meaning of the terminology, or make it so ambiguous that practically anything qualifies for inclusion, you can reassert control and dilute the threat.

In the past, this gambit — change the meaning, change the game — has accrued a decent track record. It works to impede change and to give entrenched interests more time to plot effective countermeasures.

Different This Time

What’s different this time — and Fratto’s piece provides corroborating evidence — is the existence of the ONF, a strong, customer-driven consortium that is (in its own words) “dedicated to the transformation of networking through the development and standardization of a unique architecture called Software-Defined Networking (SDN), which brings direct software programmability to networks worldwide. The mission of the Foundation is to commercialize and promote SDN and the underlying technologies as a disruptive approach to networking that will change how virtually every company with a network operates.”

If the ONF hadn’t existed, if it hadn’t already established an incontrovertible definition of SDN, the old “change the meaning, change the game” play might have worked.

But, as Fratto’s piece illustrates, it probably won’t work now.

Cisco’s SDN Strategy: Meet the New Boss, Same as the Old Boss

Like Om Malik, I received and read the memo that Cisco distributed internally regarding the company’s plans for spin-in Insieme and software-defined networking (SDN). Om has published the memo in its entirety, so there’s no need for me to do the same here.

As for Insieme, the memo informs us that Cisco has made an investment of $100 million  in the “early-stage company focused on research and development in the datacenter market. It also notes that Insieme was founded by Mario Mazzola, Luca Cafiero, and Prem Jain in February 2012, and that “Cisco has the right to purchase the remaining interests of Insieme, with a potential payout range of up to $750 million that will be based primarily on the sales and profitability of Insieme products through Cisco.”

Cisco emphasizes that Insieme’s product-development efforts are “complementary” to its current and planned internal efforts, and it notes that further details regarding Insieme will be disclosed in “Cisco’s upcoming 1oQ filing in May.”

Mystery No More

But we don’t have to wait until then to discern how Cisco will position itself in relation to SDN and programmable networks. If we were in need of additional clues as to how Cisco will play its hand, the memo contains more than enough information from which to deduce the company’s strategy.

As far as Cisco is concerned, there isn’t actually anything new to see in SDN. This is where the marketing battle over words and meanings will ensue, because Cisco’s definition of SDN will bear an uncanny resemblance to what it already does today.

In the memo, Padmasree Warrior, Cisco CTO and co-leader of engineering, makes the following statement: “Cisco believes SDN is part of our vision of the intelligent network that is more open, programmable, and application aware—a vision in which the network is transformed into a more effective business enabler.”

Cisco’s SDN

It’s an ambiguous and innocuous opening salvo, and it could mean almost anything. As the memo proceeds, however, Cisco increasingly qualifies what it means by the term SDN.  It also tells us how Insieme fits into the picture.

Here’s what I see as the memo’s money shot:

“Because SDN is still in its embryonic stage, a consensus has yet to be reached on its exact definition. Some equate SDN with OpenFlow or decoupling of control and data planes. Cisco’s view transcends this definition.”

If you want the gist of the memo in a nutshell, it’s all there. Cisco will (and does) contend that the “decoupling of control and data planes” — in other words, server-based software deciding how packets should be routed across networks — does not define SDN.

Don’t Change

This should not come as a surprise. It’s in Cisco’s interest — and, the company will argue, its customers’ interests as well — for it to resist the decoupling of the control and data planes. You won’t get ridiculous hyperbole from me, so I won’t say that such a decoupling represents an existential threat to Cisco. That would be exaggeration for effect, and I don’t play that game. So let me put it another way: It is a business problem that Cisco would rather not have to address.

Could Cisco deal with that problem? Probably, given the resources at its disposal. But it would be a hassle and a headache, and it would require Cisco to change into something different from what it is today. If you’re Cisco, not having to deal with the problem seems a better option.

Later in the Cisco memo, the company tips its hand further. Quoting directly:

While SDN concepts like network virtualization may sound new, Cisco has played a leadership role in this market for many years leveraging its build, buy, partner strategy.  For example, Cisco’s Nexus 1000V series switches—which provide sophisticated NX-OS networking capabilities in virtualized environment down to the virtual machine level—are built upon a controller/agent architecture, a fundamental building block of SDN solutions. With more than 5,000 customers today, Cisco has been shipping this technology for a long time.

“SDN plays into at least two of Cisco’s top five priorities—core routing/switching and data center/virtualization/cloud,” says Warrior.

Cisco has the opportunity to shape and define the SDN market because it is still perceived as an emerging technology, Warrior says. In fact, Cisco innovation will be much deeper than just SDN.

Cisco is operating from established positions of strength, which include the scale of its operating systems, superior ASICS, unique embedded intelligence, experienced engineering expertise, and an expansive installed base—most of which has no interest in completely replacing what it has already invested in so heavily. “

Pouring the Grappa

So, Cisco’s future SDN, including whatever Insieme eventually delivers to market, will look a lot like the “SDN” that Cisco delivers today in the Nexus 1000V series switches and the NX-OS. When one considers that some engineers now on the Insieme team worked on the Nexus 1000V, and that Insieme is licensed to use the NX-OS, it does not take a particularly athletic leap of logic to conclude that Insieme will be building a Nexus-like switch, though perhaps one on steroids.

Insieme, as I’ve written before, will represent an evolution for Cisco, not a revolution. It will be fortified switching wine in an SDN bottle. (Mario Mazzola is fond of giving Italian names to his spin-in companies. He should have called this one “Grappa.”)

Commenting on Cisco’s SDN memo and the company’s decision to tap spin-in venture Insieme as a vehicle in the space, Om Malik interpreted it as “a tactical admission that it (Cisco) has become so big, so bureaucratic and so broken that it cannot count on internal teams to build any ground breaking products.”

Bigger This Time

That might be an accurate assessment, but it’s also possible to see Insieme as business as usual at Cisco. Clearly Cisco never retired its spin-in move, as I once thought it did, but merely put it into prolonged sabbatical, holding it in reserve for when it would be needed again. Malik himself notes that Cisco has gone to the spin-well before, with this particular trio of all-star engineers now involved in their third such venture.

For good or ill, maybe this is how Cisco gets difficult things done in its dotage. It calls together a bunch of proven quantities and old engineering hands and has them build a bigger datacenter switch than they built the last time.

Is that SDN? It’s Cisco’s SDN. The company’s customers ultimately will decide whether it’s theirs, too.

Debating SDN, OpenFlow, and Cisco as a Software Company

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.

Direct from ODMs: The Hardware Complement to SDN

Subsequent to my return from Network Field Day 3, I read an interesting article published by Wired that dealt with the Internet giants’ shift toward buying networking gear from original design manufacturers (ODMs) rather than from brand-name OEMs such as Cisco, HP Networking, Juniper, and Dell’s Force10 Networks.

The development isn’t new — Andrew Schmitt, now an analyst at Infonetics, wrote about Google designing its own 10-GbE switches a few years ago — but the story confirmed that the trend is gaining momentum and drawing a crowd, which includes brokers and custom suppliers as well as increasing numbers of buyers.

In the Wired article, Google, Microsoft, Amazon, and Facebook were explicitly cited as web giants buying their switches directly from ODMs based in Taiwan and China. These same buyers previously procured their servers directly from ODMs, circumventing brand-name server vendors such as HP and Dell.  What they’re now doing with networking hardware, then, is a variation on an established theme.

The ONF Connection

Just as with servers, the web titans have their reasons for going directly to ODMs for their networking hardware. Sometimes they want a simpler switch than the brand-name networking vendors offer, and sometimes they want certain functionality that networking vendors do not provide in their commercial products. Most often, though, they’re looking for cheap commodity switches based on merchant silicon, which has become more than capable of handling the requirements the big service providers have in mind.

Software is part of the picture, too, but the Wired story didn’t touch on it. Look at the names of the Internet companies that have gone shopping for ODM switches: Google, Microsoft, Facebook, and Amazon.

What do those companies have in common besides their status as Internet giants and their purchases of copious amounts of networking gear? Yes, it’s true that they’re also cloud service providers. But there’s something else, too.

With the exception of Amazon, the other three are board members in good standing of the Open Networking Foundation (ONF). What’s more,  even though Amazon is not an ONF board member (or even a member), it shares the ONF’s philosophical outlook in relation to making networking infrastructure more flexible and responsive, less complex and costly, and generally getting it out of the way of critical data-center processes.

Pica8 and Cumulus

So, yes, software-defined networking (SDN) is the software complement to cloud-service providers’ direct procurement of networking hardware from ODMs.  In the ONF’s conception of SDN, the server-based controller maps application-driven traffic flows to switches running OpenFlow or some other mechanism that provides interaction between the controller and the switch. Therefore, switches for SDN environments don’t need to be as smart as conventional “vertically integrated” switches that combine packet forwarding and the control plane in the same box.

This isn’t just guesswork on my part. Two companies are cited in the Wired article as “brokers” and “arms dealers” between switch buyers and ODM suppliers. Pica8 is one, and Cumulus Networks is the other.

If you visit the Pica8 website,  you’ll see that the company’s goal is “to commoditize the network industry and to make the network platforms easy to program, robust to operate, and low-cost to procure.” The company says it is “committed to providing high-quality open software with commoditized switches to break the current performance/price barrier of the network industry.” The company’s latest switch, the Pronto 3920, uses Broadcom’s Trident+ chipset, which Pica8 says can be found in other ToR switches, including the Cisco Nexus 3064, Force10 S4810, IBM G8264, Arista 7050S, and Juniper QFC-3500.

That “high-quality open software” to which Pica8 refers? It features XORP open-source routing code, support for Open vSwitch and OpenFlow, and Linux. Pica8 also is a relatively longstanding member of ONF.

Hardware and Software Pedigrees

Cumulus Networks is the other switch arms dealer mentioned in the Wired article. There hasn’t been much public disclosure about Cumulus, and there isn’t much to see on the company’s website. From background information on the professional pasts of the company’s six principals, though, a picture emerges of a company that would be capable of putting together bespoke switch offerings, sourced directly from ODMs, much like those Pica8 delivers.

The co-founders of Cumulus are J.R. Rivers, quoted extensively in the Wired article, and Nolan Leake. A perusal of their LinkedIn profiles reveals that both describe Cumulus as “satisfying the networking needs of large Internet service clusters with high-performance, cost-effective networking equipment.”

Both men also worked at Cisco spin-in venture Nuova Systems, where Rivers served as vice president of systems architecture and Leake served in the “Office of the CTO.” Rivers has a hardware heritage, whereas Leake has a software background, beginning his career building a Java IDE and working at senior positions at VMware and 3Leaf Networks before joining Nuova.

Some of you might recall that 3Leaf’s assets were nearly acquired by Huawei, before the Chinese networking company withdrew its offer after meeting with strenuous objections from the Committee on Foreign Investment in the United States (CFIUS). It was just the latest setback for Huawei in its recurring and unsuccessful attempts to acquire American assets. 3Com, anyone?

For the record, Leake’s LinkedIn profile shows that his work at 3Leaf entailed leading “the development of a distributed virtual machine monitor that leveraged a ccNUMA ASIC to run multiple large (many-core) single system image OSes on a Infiniband-connected cluster of commodity x86 nodes.”

For Companies Not Named Google

Also at Cumulus is Shrijeet Mukherjee, who serves as the startup company’s vice president of software engineering. He was at Nuova, too, and worked at Cisco right up until early this year. At Cisco, Mukherjee focused on” virtualization-acceleration technologies, low-latency Ethernet solutions, Fibre Channel over Ethernet (FCoE), virtual switching, and data center networking technologies.” He boasts of having led the team that delivered the Cisco Virtualized Interface Card (vNIC) for the UCS server platform.

Another Nuova alumnus at Cumulus is Scott Feldman, who was employed at Cisco until May of last year. Among other projects, he served in a leading role on development of “Linux/ESX drivers for Cisco’s UCS vNIC.” (Do all these former Nuova guys at Cumulus realize that Cisco reportedly is offering big-bucks inducements to those who join its latest spin-in venture, Insieme?)

Before moving to Nuova and then to Cisco, J.R. Rivers was involved with Google’s in-house switch design. In the Wired article, Rivers explains the rationale behind Google’s switch design and the company’s evolving relationship with ODMs. Google originally bought switches designed by the ODMs, but now it designs its own switches and has the ODMs manufacture them to the specifications, similar to how Apple designs its iPads and iPhones, then  contracts with Foxconn for assembly.

Rivers notes, not without reason, that Google is an unusual company. It can easily design its own switches, but other service providers possess neither the engineering expertise nor the desire to pursue that option. Nonetheless, they still might want the cost savings that accrue from buying bare-bones switches directly from an ODM. This is the market Cumulus wishes to serve.

Enterprise/Cloud-Service Provider Split

Quoting Rivers from the Wired story:

“We’ve been working for the last year on opening up a supply chain for traditional ODMs who want to sell the hardware on the open market for whoever wants to buy. For the buyers, there can be some very meaningful cost savings. Companies like Cisco and Force10 are just buying from these same ODMs and marking things up. Now, you can go directly to the people who manufacture it.”

It has appeal, but only for large service providers, and perhaps also for very large companies that run prodigious server farms, such as some financial-services concerns. There’s no imminent danger of irrelevance for Cisco, Juniper, HP, or Dell, who still have the vast enterprise market and even many service providers to serve.

But this is a trend worth watching, illustrating the growing chasm between the DIY hardware and software mentality of the biggest cloud shops and the more conventional approach to networking taken by enterprises.

Cisco: SDN if Necessary, but Not Necessarily SDN

Cisco CEO John Chambers recently gave interviews to a number of technology journalists. The main point Chambers sought to hammer home was that Cisco had successfully “reinvented” itself after suffering a significant setback during the economic downturn.

Although Chambers spoke about several product lines and technologies — with video, a perennial favorite of the Cisco CEO, again receiving lavish attention — I will devote this post to what Chambers had to say about Cisco’s response to software-defined networking (SDN).

Going Old School

Reading what was both on the lines and between them, I think it’s safe to infer that Cisco’s data-center switching strategy will turn on ASICs, hardware, software, and services. While Cisco says it is open to working with SDN — OpenFlow is a relatively minor consideration, so let’s put it aside here — Cisco’s conception of software-defined networking is unlikely to bear any similarity to what we’re seeing from startups such as Nicira Networks or Big Switch Networks.

In stating at the outset that ASICs will continue to play a prominent role in Cisco’s switching strategy, Chambers tips his hand on SDN. He’s basically telling us that Cisco, if it espouses SDN at all, will favor an old-school interpretation of the technology, with a distributed control plane running across a switch-centric architecture. Contrast that with the logically centralized, server-based control planes being promoted by the aforementioned startups.

It shouldn’t come as any surprise that CIsco would adopt a grudging, incremental approach to SDN. Even today, Cisco makes most of its money selling switches and routers at robust margins. Anything it can do to maintain perceived switch value — and ASICs historically have played a big part in fashioning that value-enhancing narrative — will be aggressively pursued by the company. Notwithstanding that it has become a server vendor with its Unified Computing System (UCS), Cisco doesn’t want to accelerate a shift toward a compute-centric model of programmable networking in which applications and controller software on servers play omniscient puppet master to dumb switches. Where’s the Cisco margin in that vision?

Passenger on the Bus

Yes, that was a rhetorical question, and it probably didn’t require the imposition of a question mark. Indeed, Cisco isn’t constituted to play a leading role in the sort of brave new SDN world that has arisen from the campuses of Stanford, UC Berkeley, and other halls of academia.

Cisco will argue that the customer, and the aggregation of customers that form the demand side of the market, will be the ultimate arbiter. In making that assertion, Cisco would be right, but let’s consider that a certain constituency of customers, represented by large cloud service providers, already is voting with its data-center wallets and its considerable industry influence to champion the new model of SDN, which helps it “get the network out of the way,” innovate with new services, and reduce operating and capital expenditures.

Yes, Chambers touts Cisco’s membership in the Open Networking Foundation (ONF), but he must know that Cisco rides that bus and doesn’t drive it. As we all know by now, representatives from the largest of service providers populate the ONF’s board of directors, set its strategic course, and guide its technological agenda. Like other networking vendors, Cisco is a bit player in the ONF. For a company so cocksure and accustomed to dominating markets and standards bodies, Cisco cannot be pleased at its relatively plebeian status within the ONF.

Enterprise Fortress  

What’s more, the ONF has no desire to cede power to Cisco in the future. Dan Pitt, the ONF’s executive director, stated recently that “no vendors are allowed on the ONF board,”  and that “vendors can be on (working) groups but not steer them.” So, barring a dramatic change, Cisco’s influence on the ONF’s direction, and hence on SDN as defined by the ONF, will be marginal.

Fortunately for Cisco, the ONF is focused primarily on the needs of its board members. While a growing proportion of applications and computing cycles are moving to the public cloud, the enterprise networking market remains prodigious. Indeed, a great many enterprise data centers have invested in Cisco network infrastructure and architecture.  As before, it will be difficult to persuade them to take their business elsewhere.

So, Cisco will fight a rearguard action against SDN and against software-driven networks predicated on merchant silicon. Looking to its past for future guidance, Cisco will continue to wager heavily on its ASICs, perhaps with a new twist here and there. For the most part, though, it will be business as usual. And business, in the enterprise and among smaller service providers, still is pretty good for Cisco.

The company isn’t in danger of dropping off the technology map, not even close. But there is a threat on he horizon, and past performance doesn’t guarantee future results.

Contingency Plan

For that reason, Cisco probably should have two sets of strategic plans — one for the near to intermediate term (which seems to be the plan it already has), and another that looks further ahead. In that plan, Cisco should envision a worst-case scenario — at least from Cisco’s perspective — one in which the SDN tide sweeps along smaller cloud providers and then begins to make incursions into large enterprises.

Even though it might not play out that way, Cisco needs to prepare for it anyway. The company needs to tap into some of Andy Grove’s “healthy paranoia,” because the compute-centric model of SDN poses an existential threat to the core of Cisco’s business.

As such, Cisco needs a proactive contingency plan, featuring acquisitions as opposed to incremental in-house development. Perhaps Cisco already has such a plan. If it does, Chambers and his executive team will keep it under their hats. There’s no point turning a worst-case scenario into a self-fulfilling prophecy.

Timing, as the saying goes, is everything.