Category Archives: Open Networking Foundation

Questioning SDN Cynicism

A few months ago, I noticed that the networking cognoscenti were becoming jaded about software-defined networking (SDN). To be fair, the networking cognoscenti can skew toward disgruntlement, so it was no surprise to see this restive bunch cast a jaundiced eye toward networking’s greatest, latest hope.

I consider myself among the skeptical and wary, always cognizant that vendors can be inclined to advance a self-serving agenda that sometimes is designed to satisfy their own near-term interests over the long-term objectives of their customers. That works particularly well when the vendors can trick the customers into believing that they’re actually looking out for them. As our ancient forebears knew, caveat emptor was more than a catchphrase.

Asking Why

All of which brings me to a puzzling aspect of the current disaffection with SDN, expressed most recently in a highly readable and strongly recommended post by Ethan Banks of PacketPushers fame. My question, which I put to Banks to and to everyone else for whom SDN has become an annoyance, is simple: Are you really upset with SDN, or are you actually frustrated with the way the term has been used and abused by the vendor community?

It’s not an academic or an idle question.

One should remember that SDN, properly defined and understood, is a creation of a customer-centric consortium, the Open Networking Foundation (ONF), not a marketing or technical construct espoused by a given networking vendor or even by a group of vendors. If the term “SDN” is being bastardized and demeaned, it is not the ONF that is doing it. More directly, if the term is being cheapened, the devaluation is occurring at the hands of vendors.

But why? There are at least two possibilities. One is that certain networking vendors want to exploit the positive connotations, the afterglow, that surrounded software-defined networking (SDN). According to this theory, the damage they’re inflicting to the SDN brand is unintentional and ironic: They wanted to ride SDN’s relatively pristine coattails, not pull it into a seedy gutter of disrepute. I would be inclined to accept this theory if vendors adopted SDN definitions that accorded with that of the ONF, but. for the most part, that’s not what’s happened.

Agents Provocateurs: Back in Action 

Instead, vendors typically recast SDN in forms that correspond with product roadmaps and company-specific strategic objectives.  The result has been market confusion and cynicism, understandably so. When a term is spun to mean practically anything to anyone, it risks losing its specificity and its relevance.

Allow me suggest that at least a few vendors would be neither inconvenienced nor unduly troubled to see SDN’s identity fractured and splintered like a broken mirror.  It would not be the first time that fear, uncertainty, and doubt were deployed as agents provocateurs in a commercial context.

Nonetheless, coming back to my question above, I would counsel that we think carefully about whether our annoyance is really with SDN or with the way the term “SDN” is being manipulated and distorted by the vendor community.

As always, it is helpful to diagnose not only what is happening, but to try to understand why it is happening, too.

Northbound API: The Standardization Debate

During the last several months, several extremely informative articles and posts have been written about the significance of the northbound API (or NB API) within the context of software-defined networking (SDN).

We’ve seen two posts on the topic at SDN Central, one written in April by David Lenrow and another written by Roy Chua in early July.  Brent Salisbury, on his blog NetworkStatic, offered an excellent exegesis on the northbound API in June, and he touched on the topic again in a subsequent post in July that dealt with how he believes SDN APIs will evolve. At GigaOm, Stacey Higginbotham also has written on the subject, as have I both here and at TechTarget’s SearchNetworking.

Recently, Greg Ferro, of EtherealMind renown, provided an instructive overview on SDN APIs, opining that it is “unlikely that Northbound APIs will never standardise but I’m not aware of any initiatives in this area.”

I don’t know whether northbound APIs, as Greg suggests, will never standardize, but I do know that most knowledgeable observers (including the aforementioned parties) believe that there should no headlong rush toward standardization. The consensus is that SDN’s northbound APIs should be given an opportunity to flourish first, and that the market ultimately should vote with its feet and with its wallets.

Too Early?

That said, there are those who believe standards bodies should play a role, even at this nascent stage, in defining SDN’s northbound API.  In fact, the matter was raised yesterday on a discussion thread for the IETF’s software-driven network protocol (SDNP) BOF mailing list, where some argued that the Open Networking Foundation’s (ONF) reluctance to begin standardization work on the northbound API — the ONF reportedly will incorporate northbound-API discussions into deliberations of its recently formed architecture workgroup — opened the door for IETF involvement.

Often, but not always, proponents of near-term northbound-API standardization are representatives of legacy vendors familiar with the standards-definition process. (At this point, I feel strangely compelled to invoke the quote often misattributed to Otto von Bismarck regarding the similarity of laws to sausages: “Laws are like sausages. You should never watch them being made.” I believe this maxim also applies to IETF standards.)

The point here, though, isn’t to render a value judgment on who’s right and who’s wrong. What’s salient is that there is stark disagreement on whether the question of the northbound API can and should be settled by market forces or by vendor comity (and committee). Watching to see which players line up on either side of the divide, and how they defend their positions, will be instructive.

Between What Is and What Will Be

I have refrained from writing about recent developments in software-defined networking (SDN) and in the larger realm of what VMware, now hosting VMworld in San Francisco, calls the  “software-defined data center” (SDDC).

My reticence hasn’t resulted from indifference or from hype fatigue — in fact, these technologies do not possess the jaundiced connotations of “hype” — but from a realization that we’ve entered a period of confusion, deception, misdirection, and murk.  Amidst the tumult, my single, independent voice — though resplendent in its dulcet tones — would be overwhelmed or forgotten.

Choppy Transition

We’re in the midst of a choppy transitional period. Where we’ve been is behind us, where we’re going is ahead of us, and where we find ourselves today is between the two. So-called legacy vendors, in both networking and compute hardware, are trying to slow progress toward the future, which will involve the primacy of software and services and related business models. There will be virtualized infrastructure, but not necessarily converged infrastructure, which is predicated on the development and sale of proprietary hardware by a single vendor or by an exclusive club of vendors.

Obviously, there still will be hardware. You can’t run software without server hardware, and you can’t run a network without physical infrastructure. But the purpose and role of that hardware will change. The closed box will be replaced by an open one, not because of any idealism or panglossian optimism, but because of economic, operational, and technological imperatives that first are remaking the largest of public-cloud data centers and soon will stretch into private clouds at large enterprises.

No Wishful Thinking

After all, the driving purpose of the Open Networking Foundation (ONF) involved shifting the balance of power into the hands of customers, who had their own business and operational priorities to address. Where legacy networking failed them, SDN provided a way forward, saving money on capital expenditures and operational costs while also providing flexibility and responsiveness to changing business and technology requirements.

The same is true for the software-defined data center, where SDN will play a role in creating a fluid pool of virtualized infrastructure that can be utilized to optimal business benefit. What’s important to note is that this development will not be restricted to the public cloud-service providers, including all the big names at the top of the ONF power structure. VMware, which coined software-defined data center, is aiming directly for the private cloud, as Greg Ferro mentioned in his analysis of VMware’s acquisition of Nicira Networks.

Fighting Inevitability

Still, it hasn’t happened yet, even though it will happen. Senior staff and executives at the incumbent vendors know what’s happening, they know that they’re fighting against an inevitability, but fight it they must. Their organizations aren’t built to go with this flow, so they will resist it.

That’s where we find ourselves. The signal-to-noise ratio isn’t great. It’s a time marked by disruption and turmoil. The dust and smoke will clear, though. We can see which way the wind is blowing.

Chinese Merchant-Silicon Vendor Joins ONF, Enters SDN Picture

Switching-silicon ODM/OEM Centec Networks last week became the latest company to join the Open Networking Foundation (ONF).

According to a press release, Centec is “committed to contributing to SDN development as a merchant silicon vendor and to pioneering in the promotion of SDN adoption in China.” From the ONF’s standpoint, the more merchant silicon on the market for OpenFlow switches, the better.  Expansion in China doubtless is a welcome prospect, too.

Established in 2005, Centec has been financed by China-Singapore Suzhou Industrial Park Venture Capital, Delta Venture Enterprise, Infinity I-China Investments (Israel), and Suzhou Rongda. A little more than a year ago, Centec announced a $10.7-million “C” round of financing, in which Delta Venture Enterprise, Infinity I-China Investments (Israel), and SuZhou Rongda participated.

Acquisition Rumor

Before that round was announced, Centec’s CEO James Sun, formerly of Cisco and of Fore Systems, told Light Reading’s Craig Matsumoto that the company aspired to become an alternative supplier to Broadcom in the Ethernet merchant-silicon market. As a Chinese company, Centec not surprisingly has cultivated relationships with Chinese carriers and network-gear vendors. In his Light Reading article, in fact, Matsumoto cited a rumor that Centec had declined an acquisition offer from HiSilicon Technologies Co. Ltd., the semiconductor subsidiary of Huawei Technologies, China’s largest network-equipment vendor.

Huawei has been working not only to bolster its enterprise-networking presence, but also to figure out how best to utilize SDN and OpenFlow (and OpenStack, too).  Like Centec, Huawei is a member of the ONF, and it also has been active in IETF and IRTF discourse relating to SDN. What’s more, Huawei has been hiring SDN-savvy engineers in China and in the U.S.

As for Centec, the company made its debut on the SDN stage early this year at the Ethernet Technology Summit, where CEO James Sun gave a silicon vendor’s perspective on OpenFlow and spoke about the company’s plans to release a reference design based on Centec’s TransWarp switching silicon and an SDK with support for Open vSwitch 1.2. That reference design subsequently was showcased at the Open Networking Summit in April.

It will be interesting to see how Centec develops, both in competitive relation to Broadcom and within the context of the SDN ecosystem.

Network-Virtualization Startup PLUMgrid Announces Funding, Reveals Little

Admit it, you thought I’d lost interest in software-defined networking (SDN), didn’t you?

But you know that couldn’t be true. I’m still interested in SDN and how it facilitates network virtualization, network programmability, and what the empire-building folks at EMC/VMware are billing as the software-defined data center, which obviously encompasses more than just networking.

Game On

Apparently I’m not the only one who retains an abiding interest in SDN. In the immediate wake of VMware’s headline-grabbing acquisition of network-virtualization startup Nicira Networks, entrepreneurs and venture capitalists want us to know that the game has just begun.

Last week, for example, we learned that PLUMgrid, a network-virtualization startup in the irritatingly opaque state of development known as stealth mode, has raised $10.7 million in first-round funding led by moneybags VCs U.S. Venture Partners (USVP) and Hummer Winblad Venture Partners. USVP’s Chris Rust and Hummer Winblad’s Lars Leckie have joined PLUMgrid’s board of directors. You can learn more about the individual board members and the company’s executive team, which includes former Cisco employees who were involved in the networking giant’s early dalliance with OpenFlow a few years ago, by perusing the biographies on the PLUMgrid website.

Looking for Clues 

But don’t expect the website to provide a helpful description of the products and technologies that PLUMgrid is developing, apparently in consultation with prospective early customers. We’ll have to wait until the end of this year, or early next year, for PLUMgrid to disclose and discuss its products.

For now, what we get is a game of technology charades, in which PLUMgrid executives, including CEO Awais Nemat, drop hints about what the company might be doing and their media interlocutors then guess at what it all means. It’s amusing at times, but it’s not illuminating.

At SDNCentral, Matt Palmer surmises that PLUMgrid might be playing in “the service orchestration arena for both physical and virtual networks.” In an article written by Jim Duffy at Network World, we learn that PLUMgrid sees its technology as having applicability beyond the parameters of network virtualization. In the same article, PLUMgrid’s Nemat expresses reservations about OpenFlow. To wit:

 “It is a great concept (of decoupling the control plane for the data plane) but it is a demonstration of a concept. Is OpenFlow the right architecture for that separation? That remains to be seen.”

More to Come

That observation is somewhat reminiscent of what Scott Schenker, Nicira co-founder and chief scientist and a professor in the Electrical Engineering and Computer Science Department at the University of California at Berkeley, had to say about OpenFlow last year. (Shenker also is a co-founder and officer of the Open Networking Foundation, a champion and leading proponent of OpenFlow.)

What we know for certain about PLUMgrid is that it is based in Sunnyvale, Calif., and plans to sell its network-virtualization software to businesses that manage physical, virtual, and cloud data centers. In a few months, perhaps before the end of the year, we’ll know more.

Xsigo: Hardware Play for Oracle, Not SDN

When I wrote about Xsigo earlier this year, I noted that many saw Oracle as a potential acquirer of the I/O virtualization vendor. Yesterday morning, Oracle made those observers look prescient, pulling the trigger on a transaction of undisclosed value.

Chris Mellor at The Register calculates that Oracle might have paid about $800 million for Xsigo, but we don’t know. What we do know is that Xsigo’s financial backers were looking for an exit. We also know that Oracle was willing to accommodate it.

For the Love of InfiniBand, It’s Not SDN

Some think Oracle bought a software-defined networking (SDN) company. I was shocked at how many journalists and pundits repeated the mantra that Oracle had moved into SDN with its Xsigo acquisition. That is not right, folks, and knowledgeable observers have tried to rectify that misconception.

I’ve gotten over a killer flu, and I have a residual sinus headache that sours my usually sunny disposition, so I’m no mood to deliver a remedial primer on the fundamentals of SDN. Suffice it to say, readers of this forum and those familiar with the pronouncements of the ONF will understand that what Xsigo does, namely I/O virtualization, is not SDN.  That is not to say that what Xsigo does is not valuable, perhaps especially to Oracle. Nonetheless, it is not SDN.

Incidentally, I have seen a few commentators throwing stones at the Oracle marketing department for depicting Xsigo as an SDN player, comparing it to Nicira Networks, which VMware is in the process of acquiring for a princely sum of $1.26 billion. It’s probably true that Oracle’s marketing mavens are trying to gild their new lily by covering it with splashes of SDN gold, but, truth be told, the marketing team at Xsigo began dressing their company in SDN garb earlier this year, when it became increasingly clear that SDN was a lot more than an ephemeral science project involving OpenFlow and boffins in lab coats.

Why Confuse? It’ll be Obvious Soon Enough

At Network Computing, Howard Marks tries to get everybody onside. I encourage you to read his piece in its entirety, because it provides some helpful background and context, but his superbly understated money quote is this one: “I’ve long been intrigued by the concept of I/O virtualization, but I think calling it software-defined networking is a stretch.”

In this industry, words are stretched and twisted like origami until we can no longer recognize their meaning. The result, more often than not, is befuddlement and confusion, as we witnessed yesterday, an outcome that really doesn’t help anybody. In fact, I would argue that Oracle and Xsigo have done themselves a disservice by playing the SDN card.

As Marks points out, “Xsigo’s use of InfiniBand is a good fit with Oracle’s Exadata and other clustered solutions.” What’s more, Matt Palmer, who notes that Xsigo is “not really an SDN acquisition,” also writes that “Oracle is the perfect home for Xsigo.” Palmer makes the salient point that Xsigo is essentially a hardware play for Oracle, one that aligns with Oracle’s hardware-centric approaches to compute and storage.

Oracle: More Like Cisco Than Like VMWare

Oracle could have explained its strategy and detailed the synergies between Xsigo and its family of hardware-engineered “Exasystems” (Exadata and Exalogic) —  and, to be fair, it provided some elucidation (see slide 11 for a concise summary) — but it muddied the waters with SDN misdirection, confusing some and antagonizing others.

Perhaps my analysis is too crude, but I see a sharp divergence between the strategic direction VMware is heading with its acquisition of Nicira and the path Oracle is taking with its Exasystems and Xsigo. Remember, Oracle, after the Sun acquisition, became a proprietary hardware vendor. Its focus is on embedding proprietary hooks and competitive differentiation into its hardware, much like Cisco Systems and the other converged-infrastructure players.

VMware’s conception of a software-defined data center is a completely different proposition. Both offer virtualization, both offer programmability, but VMware treats the underlying abstracted hardware as an undifferentiated resource pool. Conversely, Oracle and Cisco want their engineered hardware to play integral roles in data-center virtualization. Engineered hardware is what they do and who they are.

Taking the Malocchio in New Directions

In that vein, I expect Oracle to look increasingly like Cisco, at least on the infrastructure side of the house. Does that mean Oracle soon will acquire a storage player, such as NetApp, or perhaps another networking company to fill out its data-center portfolio? Maybe the latter first, because Xsigo, whatever its merits, is an I/O virtualization vendor, not a switching or routing vendor. Oracle still has a networking gap.

For reasons already belabored, Oracle is an improbable SDN player. I don’t see it as the likeliest buyer of, say, Big Switch Networks. IBM is more likely to take that path, and I might even get around to explaining why in a subsequent post. Instead, I could foresee Oracle taking out somebody like Brocade, presuming the price is right, or perhaps Extreme Networks. Both vendors have been on and off the auction block, and though Oracle’s Larry Ellison once disavowed acquisitive interest in Brocade, circumstances and Oracle’s disposition have changed markedly since then.

Oracle, which has entertained so many bitter adversaries over the years — IBM, SAP, Microsoft, SalesForce, and HP among them — now appears ready to cast its “evil eye” toward Cisco.

Inevitability of Virtualized Infrastructure

As a previous post, Infrastructure Virtualization Versus Converged Infrastructure, attests, I strongly believe that virtualization is leading us to a future in which underlying hardware becomes largely undifferentiated and interchangeable. Applications and orchestration will reside in software riding atop the virtualization layer, which effectively will function as an abstraction buffer above hardware infrastructure.  The latter will eventually include hardware for computer, networking, and storage.

Vendors that ride hardware-based business models will have trouble adapting to this new reality. Many of these companies have hordes of software developers and software engineers, but they inextricably intertwine their software and hardware as a matter of business practice, selling the latter as proprietary boxes that often cannot interoperate with, or be swapped out for, competing hardware. It’s classic hardware-based vendor lock-in, and it’s been with us for many years. This applies to vendors that sell all three main types of hardware infrastructure, and to those that sell them tied together as converged infrastructure.

Loosening a Tenacious Grip

Proprietary data-center hardware would appear to be running on borrowed time, though it will not disappear overnight. Its grip will be especially tenacious in the enterprise, though the pull of the cloud eventually will weaken its hold. Proprietary compute infrastructure will be the first to succumb, but networking and storage will fall, too. The economic and operational logic powering the transition is inexorable, so it’s a question of when, not whether, it will happen.

While CapEx cost savings are an obvious benefit, operational flexibility (shifting workloads with agility and less effort) and OpEx savings also are factors. Infrastructure hardware will be cheaper, as well as easier and less costly to run. Pools of industry-standard hardware will be reallocated on demand to serve the needs of application workloads. Data-center customers no longer will be constrained by the hardware-release schedules of their previous vendors of choice. Customers also will be able to take advantage of the latest industry-standard chipsets, which will power hardware with improved energy efficiency and better cooling characteristics.

In servers, and now in storage, Facebook’s Open Compute Project (OCP) has sought to expedite the move to off-the-shelf hardware. Last week at Oscon, Frank Frankovsky, a vice president at  Facebook and the chairman and president of the OCP, rallied the open-source troops by arguing that proprietary x86 systems are “gratuitously differentiated.” He called for all hardware-design specifications to be open.

OCP as Competitive Cudgel

That would benefit Facebook, which launched OCP as a vehicle to help it lower data-center CapEx and OpEx, boost operational flexibility, and — last but not least — mitigate a competitive advantage held by Google, which had a massive head start in rationalizing and fine-tuning its data centers and IT infrastructure. In fact, Google cloaks its IT operations in extreme secrecy, believing that its practices and technologies deliver substantial competitive advantage over its main rivals, including Facebook. The latter must agree, because the animating idea behind Open Compute is to create a market, demand and supply, for commodity server hardware will reduce or eliminate Google’s edge.

Some have wondered why Google hasn’t joined OCP, but the answer should be obvious. Google believes it has cracked the infrastructure code, and it is therefore disinclined to share its insights and best practices with its competitors. Google isn’t a fan of proprietary vanity hardware — it’s been designing its own gear, then going to server and network ODMs, for some time now — but Google feels it has nothing to gain, and much to lose, from opening its kimono to the OCP crowd.

With networking, though, Google felt it needed a little help from its friends — as well as from its enemies. That explains why it allied with Facebook and other cloud-service providers in the Open Networking Foundation (ONF), which I have written about here on many occasions. The goal of the ONF, as with OCP, is to slip the proprietary shackles of hardware vendors, whose gear functions as an impediment to operational agility as well as a costs that could be reduced through SDN-style network virtualization. Google’s communitarian approach to addressing the network-virtualization riddle suggests that it believes it cannot achieve the desired outcome on its own.

Cracking the Nut

Whereas compute hardware was well on its way to standardization, networking hardware, until the ONF, was akin to a vertically integrated mainframe system, replete with a proliferating number of both proprietary and industry-standard protocols. Networking is a bigger, and tougher, nut to crack.

But crack it will, first at the big cloud-service providers, then, as the cloud gains momentum, at enterprises.

PS: I will post something tomorrow about VMware’s just-announced acquisition of Nicira, which is big news no matter how you slice it.  I wrote the above post before I learned of the acquisition.