Category Archives: Big Switch Networks

Big Switch Emphasizes Ecosystem, Channel

Big Switch Networks made the news very early today — one article was posted precisely at midnight ET — with an announcement of general availability of its SDN controller, two applications that run on it, and an ecosystem of partners.

Customers also are in the picture, though it wasn’t made explicit in the Big Switch press release whether Fidelity Investments and Goldman Sachs are running Big Switch’s products in production networks.  In a Network World article, however, Jim Duffy writes that Fidelity and Goldman Sachs are “production customers for the Big Switch Open SDN product suite.” 

Controller, Applications, Ecosystem

The company’s announced products, encompassed within its Open Software Defined Networking architecture, feature the Big Network Controller, a proprietary version of the open-source Floodlight controller, and the two aforementioned applications. An SDN controller without applications is like, well, an operating system without applications. Accordingly, Big Switch has introduced Big Virtual Switch, an application for network virtualization, and Big Tap, a unified network monitoring application. 

Big Virtual Switch is the company’s answer to Nicira’s Network Virtualization Platform (NVP).  Big Switch says the product supports up to 32,000 virtual-network segments and can be integrated with cloud-management platforms such as OpenStack (Quantum), CloudStack, Microsoft System Center, and VMware vCenter.  As Big Switch illustrates on its website, Big Virtual Switch can be deployed on Big Network Controller in pure overlay networks, in pure OpenFlow networks, and in hybrid network-virtualization environments.  

According to the company, Big Virtual Switch can deliver significant CAPEX and OPEX benefits. A graphical figure — tagged Economics of Big Virtual Switchincluded in a product data sheet claims the company’s L2/L3 network virtualization facilitates “up to 50% more VMs per rack” and delivers CAPEX savings of $500,000 per rack annually and OPEX savings of $30,000 per rack annually. For those estimates, Big Switch assumes a rack size of 40 servers and suggests savings can be accrued across severs, operating-system instances, storage, networking, and operations. 

Strategies in Flux

Big Virtual Switch and Big Tap are essential SDN applications, but the company’s ultimate success in the marketplace will turn on the support its Big Network Controller receives from third-party vendors. Big Switch is aware of its external dependencies, which is why it has placed so much emphasis on its ecosystem, which it says includes A10 Networks, Arista Networks, Broadcom, Brocade, Canonical, Cariden Technologies, Citrix, Cloudscaling, Coraid, Dell, Endace, Extreme Networks, F5 Networks, Fortinet, Gigamon, Infoblox, Juniper Networks, Mellanox Technologies, Microsoft, Mirantis, Nebula, Palo Alto Networks, Piston Cloud Computing, Radware, StackOps, ThreatSTOP, and vArmour. The Big Switch press release includes an appendix of “supporting quotes” from those companies, but the company will require more than lip service from its ecosystem. 

Some companies will find that their interests are well aligned with those of Big Switch, but others are likely to be less motivated to put energy and resources into Big Switch’s SDN platform.  If you consider the vendor names listed above, you might deduce that the SDN strategies of more than a few are in flux. Some are considering whether to offer SDN controllers of their own. Even those who have no controller aspirations might be disinclined to bet too heavily or too early on a controller platform. They’ll follow the customers and the money. 

A growing number of commercial controllers are on the market (VMware/Nicira, NEC, and Big Switch) or have been announced as coming to market (IBM, HP, Cisco). Others will follow. Loyalties will shift as controller fortunes wax and wane. 

Courting the Channel 

With that in mind, Big Switch is seeking to enlist channel partners as well as technology partners. In a CRN article, we learn that Big Switch “has begun to recruit systems integrator and data center infrastructure-focused solution providers that can consult and design network architecture using Big Switch software and products from a galaxy of ecosystem partners.” In fact, Big Switch wants all its commercial sales to go through channel partners. 

In the CRN piece, Dave Butler, VP of sales at Big Switch, is candid about the symbiotic relationship the company desires from partners:

“None of our products work well alone in a data center — this is a very rigorous and rich ecosystem of partners. We’ll pay a finder’s fee to anyone who brings the right opportunity to us, but we’re not really a product sale. We need the integrators that can create a bundled solution, because that’s what makes the difference.”

. . . . “We bring them (partners) in as the specialist, and they have probably a greater touch than we might. We are not taking deals direct. Then, you have to do all the work by yourself. This is a perfect solution for their services and expertise. And, they can make money with us.”

Needs a Little Help from Its Friends

The plan is clear. Big Switch’s vendor ecosystem is meant to attract channel partners that already are selling those vendors’ products and are interested in expanding into SDN solutions. The channel partners, including SIs and datacenter-solution providers, will then bring Big Switch’s SDN platform to customers, with whom they have existing relationships. 

In theory, it all coheres. Big Switch knows it can’t go it alone against industry giants. It knows it needs more than a little help from its friends in the vendor community and the channel. 

For Big Switch, the vendor ecosystem expedites channel recruitment, and an effective channel accelerates exposure to customers. Big Switch has to move fast and demonstrate staying power. The controller race is far from over. 

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.

Some Thoughts on VMware’s Strategic Acquisition of Nicira

If you were a regular or occasional reader of Nicira Networks CTO Martin Casado’s blog, Network Heresy, you’ll know that his penultimate post dealt with network virtualization, a topic of obvious interest to him and his company. He had written about network virtualization many times, and though Casado would not describe the posts as such, they must have looked like compelling sales pitches to the strategic thinkers at VMware.

Yesterday, as probably everyone reading this post knows, VMware announced its acquisition of Nicira for $1.26 billion. VMware will pay $1.05 billion in cash and $210 million in unvested equity awards.  The ubiquitous Frank Quattrone and his Quatalyst Partners, which reportedly had been hired previously to shop Brocade Communications, served as Nicira’s adviser.

Strategic Buy

VMware should have surprised no one when it emphasized that its acquisition of Nicira was a strategic move, likely to pay off in years to come, rather than one that will produce appreciable near-term revenue. As Reuters and the New York Times noted, VMware’s buy price for Nicira was 25 times the amount ($50 million) invested in the company by its financial backers, which include venture-capital firms Andreessen Horowitz, Lightspeed,and NEA. Diane Greene, co-founder and former CEO of VMware — replaced four years ago by Paul Maritz — had an “angel” stake in Nicira, as did as Andy Rachleff, a former general partner at Benchmark Capital.

Despite its acquisition of Nicira, VMware says it’s not “at war” with Cisco. Technically, that’s correct. VMware and its parent company, EMC, will continue to do business with Cisco as they add meat to the bones of their data-center virtualization strategy. But the die was cast, and  Cisco should have known it. There were intimations previously that the relationship between Cisco and EMC had been infected by mutual suspicion, and VMware’s acquisition of Nicira adds to the fear and loathing. Will Cisco, as rumored, move into storage? How will Insieme, helmed by Cisco’s aging switching gods, deliver a rebuttal to VMware’s networking aspirations? It won’t be too long before the answers trickle out.

Still, for now, Cisco, EMC, and VMware will protest that it’s business as usual. In some ways, that will be true, but it will also be a type of strategic misdirection. The relationship between EMC and Cisco will not be the same as it was before yesterday’s news hit the wires. When these partners get together for meetings, candor could be conspicuous by its absence.

Acquisitive Roads Not Traveled

Some have posited that Cisco might have acquired Nicira if VMware had not beaten it to the punch. I don’t know about that. Perhaps Cisco might have bought Nicira if the asking price were low, enabling Cisco to effectively kill the startup and be done with it. But Cisco would not have paid $1.26 billion for a company whose approach to networking directly contradicts Cisco’s hardware-based business model and market dominance. One typically doesn’t pay that much to spike a company, though I suppose if the prospective buyer were concerned enough about a strategic technology shift and a major market inflection, it might do so. In this case, though, I suspect Cisco was blindsided by VMware. It just didn’t see this coming — at least not now, not at such an early state of Nicira’s development.

Similarly, I didn’t see Microsoft or Citrix as buyers of Nicira. Microsoft is distracted by its cloud-service provider aspirations, and the $1.26 billion would have been too rich for Citrix.

IBM’s Moves and Cisco’s Overseas Cash Horde

One company I had envisioned as a potential (though less likely) acquirer of Nicira was IBM, which already has a vSwitch. IBM might now settle for the SDN-controller technology available from Big Switch Networks. The two have been working together on IBM’s Open Data Center Interoperable Network (ODIN), and Big Switch’s technology fits well with IBM’s PureSystems and its top-down model of having application workloads command and control  virtualized infrastructure. As the second network-virtualization domino to fall, Big Switch likely will go for a lower price than did Nicira.

On Twitter, Dell’s Brad Hedlund asked whether Cisco would use its vast cash horde to strike back with a bold acquisition of its own. Cisco has two problems here. First, I don’t see an acquisition that would effectively blunt VMware’s move. Second, about 90 percent of Cisco’s cash (more than $42 billion) is offshore, and CEO John Chambers doesn’t want to take a tax hit on its repatriation. He had been hoping for a “tax holiday” from the U.S. government, but that’s not going to happen in the middle of an election campaign, during a macroeconomic slump in which plenty of working Americans are struggling to make ends meet. That means a significant U.S.-based acquisition likely is off the table, unless the target company is very small or is willing to take Cisco stock instead of cash.

Cisco’s Innovator’s Dilemma

Oh, and there’s a third problem for Cisco, mentioned earlier in this prolix post. Cisco doesn’t want to embrace this SDN stuff. Cisco would rather resist it. The Cisco ONE announcement really was about Cisco’s take on network programmability, not about SDN-type virtualization in which overlay networks run atop an underyling physical network.

Cisco is caught in a classic innovator’s dilemma, held captive by the success it has enjoyed selling prodigious amounts of networking gear to its customers, and I don’t think it can extricate itself. It’s built a huge and massively successful business selling a hardware-based value proposition predicated on switches and routers. It has software, but it’s not really a software company.

For Cisco, the customer value, the proprietary hooks, are in its boxes. Its whole business model — which, again, has been tremendously successful — is based around that premise. The entire company is based around that business model.  Cisco eventually will have to reinvent itself, like IBM did after it failed to adapt to client-server computing, but the day of reckoning hasn’t arrived.

On the Defensive

Expect Cisco to continue to talk about the northbound interface (which can provide intelligence from the switch) and about network programmability, but don’t expect networking’s big leopard to change its spots. Cisco will try to portray the situation differently, but it’s defending rather than attacking, trying to hold off the software-based marauders of infrastructure virtualization as long as possible. The doomsday clock on when they’ll arrive in Cisco data centers just moved up a few ticks with VMware’s acquisition of Nicira.

What about the other networking players? Sadly, HP hasn’t figured out what to about SDN, even though OpenFlow is available on its former ProCurve switches. HP has a toe dipped in the SDN pool, but it doesn’t seeming willing to take the initiative. Juniper, which previously displayed ingenuity in bringing forward QFabric, is scrambling for an answer. Brocade is pragmatically embracing hybrid control planes to maintain account presence and margins in the near- to intermediate-term.

Arista Networks, for its part, might be better positioned to compete on networking’s new playing field. Arista Networks’ CEO Jayshree Ullal had the following to say about yesterday’s news:

“It’s exciting to see the return of innovative networking companies and the appreciation for great talent/technology. Software Defined Networking (SDN) is indeed disrupting legacy vendors. As a key partner of VMware and co-innovator in VXLANs, we welcome the interoperability of Nicira and VMWare controllers with Arista EOS.”

Arista’s Options

What’s interesting here is that Arista, which invariably presents its Extensible OS (EOS) as “controller friendly,” earlier this year demonstrated interoperability with controllers from VMware, Big Switch Networks, and Nebula, which has built a cloud controller for OpenStack.

One of Nebula’s investors is Andy Bechtolsheim, whom knowledgeable observers will recognize as the chief development officer (CDO) of, and major investor in, Arista Networks.  It is possible that Bechtolsheim sees a potential fit between the two companies — one building a cloud controller and one delivering cloud networking. To add fuel to this particular fire, which may or may not emit smoke, note that the Nebula cloud controller already features Arista technology, and that Nebula is hiring a senior network engineer, who ideally would have “experience with cloud infrastructure (OpenStack, AWS, etc. . . .  and familiarity with OpenFlow and Open vSwitch.”

 Open or Closed?

Speaking of Open vSwitch, Matt Palmer at SDN Centralwill feel some vindication now that VMware has purchased a company whose engineering team has made significant contributions to the OVS code. Palmer doubtless will cast a wary eye on VMware’s intentions toward OVS, but both Steve Herrod, VMware’s CTO, and Martin Casado, Nicira’s CTO, have provided written assurances that their companies, now combining, will not retreat from commitments to OVS and to Open Flow and Quantum, the OpenStack networking  project.

Meanwhile, GigaOm’s Derrick Harris thinks it would be bad business for VMware to jilt the open-source community, particularly in relation to hypervisors, which “have to be treated as the workers that merely carry out the management layer’s commands. If all they’re there to do is create virtual machines that are part of a resource pool, the hypervisor shouldn’t really matter.”

This seems about right. In this brave new world of virtualized infrastructure, the ultimate value will reside in an intelligent management layer.

PS: I wrote this post under a slight fever and a throbbing headache, so I would not be surprised to discover belatedly that it contains at least a couple typographical errors. Please accept my apologies in advance.

Debate Over Openness of Open vSwitch

Late last week, the illustrious Ivan Pepelnjak pointed me to a post by Matthew Palmer at SDN Central. Pepelnjak thought the post would interest me, and he was right.

While I encourage you to read Palmer’s post firsthand, I will summarize it briefly. Basically, Palmer makes a two-part argument and then leaves us with unsettled questions. The first part of his argument is that the virtual switch (vSwitch) has become the “prime real-estate for network virtualization within the datacenter.” As such, the vSwitch has become a strategic battleground for vendors and service providers alike.

This brings us to the second part of Palmer’s argument, which is more controversial. Palmer implies that the first part of his argument, about the valuable real-estate inhabited by the vSwitch, wouldn’t be a major point of contention if a genuine and viable open vSwitch — and not just an open-source vSwitch — were available. Alas, he says, that is not the case.

Open . . . or Just Open Source? 

Palmer suggests that Open vSwitch (OVS), which wears the mantle of open-source vSwitch, is a proprietary wolf in sheep’s clothing.  He says Open vSwitch might be open source, but that it is far from open. Instead, he says, it is under the direction of one company, Nicira Networks, which “controls the features, capabilities, and protocols supported within OVS and when they are released.”

Writes Palmer:

“Since OVS is ‘Open’ Nicira will gladly take your free labor to develop on OVS and give you an Apache license to ‘fork’ your own distribution; but they essentially decide which features and protocols, from what contributors will be included in the mainline distribution at what time.  This basically masquerades OVS as the ‘free’ switch in a freemium business model where the vendor locks you in with their better, proprietary, paid for version.  This is why many others in the networking community are looking for alternatives to invest their time and development resources. “

From Naive Newcomer to Proprietary Villain

My first reaction was that Nicira must be making some headway commercially. I don’t think I’ve ever seen a vendor go from virtual-networking upstart to proprietary villain in a shorter period of time. Palmer is an accomplished business-development executive, and he corresponds regularly with a large circle of industry notables. Clearly, Nicira has gotten their attention.

Not long ago, many denizens of that same community dismissed Nicira as a bunch of technically brilliant but commercially ingenuous SDN neophytes who weren’t a serious threat to the networking industry’s status quo. If Palmer’s post is an accurate barometer of industry sentiment, that view has undergone significant revision.

In some ways, Palmer’s post was foreshadowed by a commentary from Dell’s Brad Hedlund earlier this year. Whereas Palmer bemoaned the proprietary stranglehold that Nicira might gain over the Open Networking Foundation (ONF) and large swathes of the SDN community, though, Hedlund took a different tack. While he, like Palmer, noted that Nicira’s engineers played a defining role in developing Open vSwitch, Hedlund was more interested in how Nicira’s approach to SDN prefigured a “significant shift .  . .  when it comes to the relevance and role of “protocols” in building next generation virtual data center networks.”

Diverse Project

In light of Palmer’s charges, I thought I’d reach out to Nicira to solicit a reply. Fortunately, Martin Casado, Nicira’s CTO, was kind enough to get back to me with what he termed “off-the-cuff comments” on Palmer’s post.

His first point was that “Nicira doesn’t have a proprietary vSwitch (never has).” In his post, Palmer wrote that Nicira “has their own proprietary version of Open vSwitch . . . . “

Casado also noted that “Nicira’s kernel module is in mainline Linux, which is clearly not controlled by Nicira,” and that “OVS is one of the largest and most diverse open source projects in the world,” with a “profile better and broader than most projects.”

The Nicira CTO also wrote that Open vSwitch is used by “potentially competitive companies,” including Cisco, Big Switch Networks, NEC, and Midokura. Casado wrote that these vendors are “welcome to fork it, or do whatever they want with it.” On that point, he and Palmer appear to be in agreement, though Palmer contends that Nicira essentially controls the direction of OVS.

SDN’s Long, Hot Summer

Finally, though Palmer’s post suggested that Nicira’s could undermine OpenFlow by swapping it out for a “proprietary (i.e. non-OpenFlow) protocol that only works with Nicira’s vSwitch and controller,” Casado responded as follows: “Development of OpenFlow 1.1 – 1.3 is moving ahead at an extremely aggressive pace.  Multiple organizations are working on it (NTT, Google, T-Systems, and Nicira), and much of the implementation is done and has been committed.”

That response, in and of itself, does not close the door on Nicira leveraging another protocol — and we know that Nicira has proposed two variants of OpenFlow, one at the edge and one in the core, to support an MPLS-like SDN fabric — but it also suggests that OpenFlow isn’t in any imminent danger of being sidelined or relegated to oblivion.

Still, Palmer’s post raises compelling questions and demonstrates that, in the summer of 2012, SDN is generating heat as well as light.

Addressing SDN Burnout

In the universe of staccato text bursts that is Twitter, I have diagnosed a recent exhaustion of interest in software defined networking (SDN).

To a certain degree, the burnout is understandable. It is a relatively nascent space, generating more in the way of passionate sound and fury than in commercial substance. Some Twitter denizens with a networking bent have even questioned whether an SDN market — involving buyers as well as sellers — actually exists.

On that score, the pointed skepticism has been refuted. SDN vendors, including Nicira Networks and Big Switch Networks, increasingly are reporting sales and customer traction. What’s more, market-research firms have detected signs of commercial life. International Data Corporation (IDC), for example, has said the SDN market will be worth a modest $50 million this  year,  but that it will grow to $200 million in 2013 and to $2 billion by 2016. MarketsandMarkets estimates that the global SDN market will expand from $198 million in 2012 to $2.10 billion in 2017, representing a compound annual growth rate (CAGR) of 60.43% during that span.  I’m sure other market measurers will make their projections soon enough.

But just what are they counting? SDN isn’t a specific product category, like a switch; it’s an architectural model. In IDC’s case, the numbers include SDN-specific switching and routing as well as services and software (presumably including controllers and the applications that run on them). MarketsandMarkets is counting  SDN “switching, controllers, cloud virtualization applications, and network virtualization security solutions.”

Still, established networking vendors will argue that the SDN hype is out of proportion with on-the-ground reality. In that respect, they can cite recent numbers from Infonetics Research that estimate global revenue derived from sales of data-center network equipment — the market segment SDN is likely to make most headway during the next several years — was worth $2.2 billion in the first quarter of 2012. Those numbers include sales of Ethernet switches, application delivery controllers (ADCs), and WAN-optimization appliances.

This is where things get difficult and admittedly subjective. If we’re considering where the industry and customers stand today, then there’s no question that SDN gets more attention than it warrants. Most of us, including enterprise IT staff, do not wish to live in the past and don’t have the luxury of looking too far into the future.

That said, some people have the job of looking ahead and trying to figure out how the future will be different from the present. In the context of SDN, those constituencies would include the aforementioned market researchers as well as venture capitalists, strategic planners, and technology visionaries. I would also include in this class industry executives at established and emerging vendors, both those directly involved in networking technologies and those that interact with networking infrastructure in areas such as virtualization and data-center management and orchestration.

For these individuals, SDN is more than a sensationalized will-o’-the-wisp.  It’s coming. The only question is when, and getting that timing right will be tremendously important.

I suppose my point here is that some can afford to be dismissive of SDN, but others definitely cannot and should not. Is interest in SDN overdone? That’s subjective, and therefore it’s your call. I, for one, will continue to pay close attention to developments in a realm that is proving refreshingly dynamic, both technologically and as an emerging market.

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.

Time for HP to Show Its SDN Hand

Although HP has demonstrated mounting support for OpenFlow, it has yet to formulate what I would call a full-fledged strategy for software defined networking (SDN). Yes, HP offers OpenFlow-capable switches, but there’s more to SDN than OpenFlow. Indeed. there’s definitely more to SDN than the packet-shunting hardware at the bottom of the value chain.

The word “software” is prominent in the SDN acronym for a reason, and HP hasn’t told us much about its plans in that area. I am not able to attend this week’s Interop in Las Vegas, but I am hoping HP takes the opportunity this week to disclose a meaningful SDN strategy.

HP could start by telling us what it plans to do on the controller front. Does its strategy involve taking a wait-and-see attitude, working with the likes of Big Switch Networks? Does HP have a controller of its own in the works? As an august publication once trumpeted in a long-ago  advertising campaign, inquiring minds want to know.

Above the controller, how does HP see the ecosystem developing? Does it plan to provide applications, management, orchestration? I think we have a reasonably good idea where Cisco is going with its SDN strategy — though Cisco would rather talk about network programmability (more on which later) — but HP has yet to play its hand.

HP is in Las Vegas this week. It’s as good a time as any to put its SDN cards on the table.

At Dell, Networking’s Role Secondary but Integral

Dell made a networking announcement last week, and, for the most part, reaction was muted. That’s party because Dell’s networking narrative is evolving and in transition, and partly because the announcements related to incremental, though notable, progression.

To be fair, Dell’s networking narrative is part of a larger story the company is telling in the data center. Networking is integral to that story, but it’s not the centerpiece and never will be. Dell is working from the blueprint of its Virtual Network Architecture (VNA), so its purchase and stewardship of Force10 is framed within a bigger picture that involves not just converged infrastructure, but also workload-driven orchestration of virtualized environments.

Integration and Assimilation

Some good news for Dell is that its integration and assimilation of Force10 Networks seems to have gone well and is now complete.  Dell’s OpenManage Networking Manager (OMNM) 5.0. offers a new look and support for the full line of Dell networking products, including the Force10 portfolio. What’s more, in its Dell Force10 MXL blade interconnect, a  40Gb Ethernet switch for the M1000e Blade chassis, Dell brings delivers an apt metaphor as well as a blade-server switch.

In that sense, it’s helpful to recall that Dell’s acquisition of Force10 was motivated by a desire to integrate networking into an automated, orchestrated data center in which it already offered compute and storage. Dell concluded that needed to own networking technology just as it owned server and storage technology. It further deduced that it needed a comprehensive networking portfolio, extending across SAN and LAN environments. Just as it moved previously to shake its dependence on storage partners, it would do likewise in networking.

Dell sees networking as an integral enabling technology, but not as an end in itself. Dell believes it can be more flexible than HP and IBM in certain enterprise demographics, and it believes it can outflank Cisco by being less “network centric” and more open to developments such as software defined networking (SDN).Force10, which was thought to be between a rock and hard place just before being acquired, understands and accepts its role in the Dell universe.

Fitting Into VNA

The key to understanding Dell’s data-center strategy is Virtual Network Architecture (VNA). The announcement of the new blade-server switch fits into that plan. Dell says VNA’s purpose is to virtualize, automate, and orchestrates network services so that they can adapt readily to application and business requirements. Core elements of VNA include the following:

  • High-performance switching systems for the campus and the data center
  • Virtualized Layer 4-7 services
  • Comprehensive automation & orchestration software
  • Open workload/hypervisor interfaces

So, what does it all mean? It means Dell is taking an approach that it believes will be differentiated and add considerable value in customers’ and prospective customers’ data centers. On the networking front, Dell believes it has espoused a strategy that encompasses and envelops the rise of SDN while also taking and accommodating approach to the networking gear already present in customer accounts.

Workload-Oriented Approach

In an article at The VAR Guy, Nathan Eddy quotes Dario Zamarian, VP and GM of Dell Networking, as follows:

“We are taking a workload-oriented approach — as in, ‘What does each require first?’ as opposed to starting with the network first [and] then trying to fit the application to it. In other words, networking is the enabler. The ultimate goal of VNA is to make networking as simple to set up, automate, operate, and manage as servers. VNA is doing for networking what VMware did for servers.”

Well, that’s the plan. In theory, in a slide show, all the pieces are there, but Dell has to execute and deliver on the vision. One can identify holes in the structure, places where Dell will need to buy, partner, or build to close the gaps. It’s clearly doing that, though, as the Force10 acquisition and others recently attest.

Taking Force10’s technology forward in alignment with its plans, Dell not only announced  a 40GbE-enabled blade server switch. It also introduced fabric- and network-management tools to simplify operations in the data center and the campus, and it announced data-center enhancements (stacking technology, L2 multipathing, data-center bridging, automated workload mobility through auto-provisioning of VLANs) to Force10’s FTOS for its S4810 10/40G switching platform.

Encompassing SDN

On the SDN front, Dell announced interoperability with Big Switch Networks’ Open SDN architecture and its OpenFlow-based Floodlight controller. That interoperability will be showcased next week in joint demonstrations at Interop, with the application emphasis on cloud multi-tenancy.

Regardless of where Dell goes with SDN, and regardless of how quickly (or slowly) SDN makes encroachments into the enterprise, Dell’s VNA model accounts for it and much else besides. Dell believes it can win in workload and network orchestration, with its Advanced Infrastructure Manager (AIM) providing virtual-network programming interfaces and doubtless with some forthcoming orchestration technologies it has yet to introduce (or buy).

Dell’s VNA seems a viable plan. But can the company continue to execute on it? Dell would have more focus and resources to do so if it jettisoned its woebegone consumer business, but that divestiture doesn’t seem to be in the cards.

Big Switch’s Open Invocation

In my last post, which focused on the nascent market and fluid ecosystem for software defined networking (SDN), I commented on the early jockeying for position in the wide-open controller race.

These still are early days for SDN, especially in the enterprise, where the technology’s footprint is negligible and where networking professionals are inclined to view it as a solution in search of a problem. As such, emergent vendors are trying to get a fast start, hoping that it might be extended into an insurmountable lead in an expanding market . That’s clearly the thinking behind the “Open SDN” strategy at Big Switch Networks.

Big Switch’s conundrum is easy to understand. It seemingly wants to become the Red Hat of SDN, but it first must create a meaningful market for its technology. If all goes according to plan, Big Switch would sell a “premium” version of its Floodlight controller, and it also could provide applications and services that run on it.

Help Wanted

But Big Switch can’t do it alone. It needs other vendors and the broader SDN community to buy into its vision and support the cause. For its controller to succeed, especially among enterprise networking professionals who already tend to be skeptical and even scornful of OpenFlow-based SDN, it will need to enlist third parties to develop and deliver compelling applications and services.

Hence, its “Open SDN” blueprint, which it has trademarked, and which rests on three pillars (networking companies love their pillars):

1) Open Standards, which connotes support for established networking-industry standards (there are plenty from which to choose) as well as for new ones, such as OpenFlow. The desired outcome is easier integration and interoperability between and among products in the SDN ecosystem.

2) Open APIs, which are intended to facilitate the creation of a vibrant ecosystem of infrastructure, network services, and orchestration applications.

3) Open Source, which offers the successfully community templates formed around Linux, MySQL, and Hadoop, and which is seen as an increasingly important factor as networking becomes more software oriented.

Open Invocation

Some people equate “open” with virtuous, as if a stark Manichean melodrama is unfolding between proprietary black-hat vendors and the good guys in white hats who fly the open-source flag. The truth is, each and every vendor is in business to make money. These are not non-profit organizations with altruistic mandates and motives. Vendors might differ in how they make their money, but not in their common desire to make it.

As a vendor of technology that is disruptive to the networking status quo, Big Switch has little to lose (and potentially much to gain) by playing the open-source card. If it can cultivate a community of application vendors around its Floodlight controller and leverage what it hopes will be a growing pool of OpenFlow-compatible switches, Big Switch will have a fighting chance of making the networking cut against established and neophyte players alike.

Enterprise Resistance

But time, as always, is a critical factor. Big Switch must establish and maintain market momentum, providing evidence of customer wins as early and as often as possible. It’s about inertia and perception, which tend to feed off one another. The company that makes perceptible progress will be well placed to make further perceptible progress, but the company that is seen to stumble shortly after leaving the gate might never recover.

Given the company’s enterprise, private-cloud orientation, Big Switch’s “Open SDN” gambit is probably the right call. It’s another matter entirely as to whether that strategy will be sufficient to overcome the SDN doubts of enterprise networking professionals.

Still Early Days in SDN Ecosystem

Jason Edelman has provided a helpful overview of the software-defined networking (SDN) ecosystem and the vendors currently active within it. Like any form chart, though, it’s a snapshot in time, and therefore subject to change, as I’m sure Edelman would concede.

Still, what Edelman has delivered is a useful contextual framework to understand where many vendors stand today, where “stealth” vendors might attempt to make their marks shortly, and where and how the overall space might evolve.

Edelman presents the somewhat-known entities — Nicira, Big Switch, NEC, and Embrane (L4-7) at the applications/services layer — and he also addresses  vendors providing controllers, where no one platform has gained an appreciable commercial advantage because the market remains nascent.  He also covers the “switch infrastructure” vendors, which include HP Networking, Netgear, IBM, Pica8, NEC, Arista, Juniper, and others. (In a value-based analysis of the SDN market, “switch infrastructure” is the least interesting layer, but it is essential to have an abundance of interoperable hardware on the market.)

Cards Still to be Played

The real battle, from which it might take considerable time for clears winners to emerge, will occur at the two upper layers, where controller vendors will be looking to win the patronage of purveyors of applications and services. At the moment, the picture is fuzzy. It remains possible that an eventual winner of the inevitable controller-market shakeout has yet to enter the frame.

In that regard, look for established networking players and new entrants to make some noise in the year ahead. Edelman has listed many of them, and I’ve heard that a few more are lurking in the shadows. Names that  are likely to be in the news soon include Plexxi, LineRate Systems (another L4-7 player, it seems), and Ericsson (with its OpenFlow/MPLS effort).

These are, as the saying goes, early days.

Cisco’s Latest Spin-In Reportedly Poaching Aggressively (And Not At Cisco This Time)

Insieme (everybody keeps calling it “Insiemi,” but I have been told that the correct spelling is the former) is back in the spotlight again, even though nobody can say with any precision exactly what the Cisco spin-in venture has been mandated to do.

Om Malik is the latest industry observer to attempt to shed light on Insieme. He doesn’t provide many specifics on what Mario Mazzola, Luca Cafiero, Prem Jain and their band of merry engineers will be building — “a new very high-speed data center switch along with a software management platform,” Om offers — but he does deliver some interesting insight into how the spin-in venture is recruiting new members to its team.

Om’s sources tell him that Insieme is aggressively raiding the engineering ranks of Cisco competitors, allegedly offering nearly $2 million a pop as an inducement — and that’s quite an inducement — to engineers and executives at competing companies willing to jump ship and join the networking pirates at the Cisco-sponsored venture.

Although Om, through his sources, originally reported significant executive defections from Nicira (four) and Arista (four), he has since revised his post to indicate that Insieme has managed to snare five engineers in total, plucked from Arista, Nicira, Big Switch Networks, and Cumulus Systems. Other engineers at those companies are said to have declined offers to join the Cisco spin-in venture.

Change of Tack

Nonetheless, this tactic marks a change for Cisco spin-in creations fronted by Mazzola, Cafiero, and Jain. Usually, their ventures plunder from within the ranks of Cisco rather than from beyond the walls of the networking giant. As written here and elsewhere previously, the spin-in ventures’ practice of recruiting Cisco’s best and brightest — or at least those seen as most useful to the project at hand — has engendered envy and resentment among those not tapped for the gravy train.

To be sure, Cisco’s previous spin-in ventures — including the Mazzola-helmed, Italian-themed Andiamo and Nuova — included engineers recruited from company’s other than Cisco. Still, there’s no question that Mazzola and friends poached extensively from the engineering teams with which they were most familiar. One wonders whether Chambers and the Cisco executive team might be trying to discourage that practice this time around.

Another plausible explanation is that the hardware-heavy Insieme engineering team is looking for engineering capabilities in software, and specifically in software-defined networking (SDN), that are better found at the aforementioned companies than at Cisco itself.

Either way, the incipient Insieme appears to be roiling the network-engineering waters in Silicon Valley.

Further Thoughts on Cisco’s Latest Spin-In Venture

This is a follow-up post to my last missive regarding Cisco’s latest reported spin-in venture, Insieme (not Insiemi, apparently). As you will recall, we had heard for some time that Cisco’s masters of the spin-in venture were getting back in the saddle for at least one more stretch run.

The question had become not whether they’d come back, but what they would put on the playlist for their reunion. Now, as indicated in an article in the New York TImes, the widely held assumption is that Insieme will provide Cisco’s answer to software-defined networking (SDN).

But, as we know, SDN means different things to different vendors. Given the composition and capabilities of the team at Insieme, I wouldn’t expect this group to recreate the sort of logically centralized control plane and server-based programmable networking that the likes of Nicira and Big Switch Networks have championed.

ASICs in the Mix 

After all, the central protagonists at Insieme — Mario Mazzola, Luca Cafiero, Prem Jain — are hardware engineers. Throughout their long, storied, and illustrious careers, they have built switches. There is no reason to think they will be cast against type in this particular venture. A variation on what they’ve done in their previous spin-in ventures for Cisco –  Andiamo, which was responsible for Cisco’s storage-area networking (SAN) switches, and Nuova, which provided Cisco with its Nexus data-center switches — is probably what they’ll do this time, too.

Admittedly, there is some software talent on the Insieme roster. Network World’s Jim Duffy reported that Ronak Desai, the architect of Cisco’s NX-OS FabricPath and Virtual Device Context software, and of the MDS SAN switch operating system, is on the team. Michael Smith, a distinguished engineer who worked on Cisco’s Nexus 1000v virtual switch, also might be part of the Insieme squad.

Still, John Chambers recently reiterated Cisco’s unswerving commitment to the propriety switching ASIC, which Cisco sees a point of differentiation against Arista Networks and others. Chambers’ words suggest that Cisco isn’t about to get the newfangled SDN religion. In fact, if anything, they suggest that Cisco is still working from its well-thumbed playbook of ASIC-based switches in a network-centric world.

Moreover, with Tom Edsall, the lead ASIC architect on the Nexus and MDS switching lines, reportedly on board with Insieme, we can probably safely deduce that the ASIC will be front and center in whatever the spin-in effort delivers. So, if it’s an SDN architecture Insieme has been mandated to deliver, it will be one with a distributed control plane and absolutely no role for dumb, off-the-rack switches.

Two Possible Scenarios

With regard to the increasingly contested definition of SDN — look no further than the marketing messages of certain vendors or to the software-driven networking hijinks now occurring in the IETF — there’s also the possibility that what the Insieme pack are doing could be only incidentally connected to what many consider SDN.

With that in mind, I want to turn to some intriguing speculation that William Koss, now at Plexxi, has provided on what he believes Cisco’s latest spin-in venture might be building. In a post on his blog, Koss reviews Cisco’s switching history, much of it involving the three musketeers now reuniting at Insieme, He then explains why Cisco does spin-in ventures before he offers his assessment of what Insieme might be  trying to accomplish.

He offers two possible paths Insieme might take. The first path would involve Cisco attending to what Koss terms “unfinished business” (including Brocade) in the storage space. In this scenario, the Insieme team would build a successor switch to the Nexus line with storage-networking hooks. This switch would be intended as a crushing reply to Xsigo’s I/O Director, while simultaneously representing an attempt to limit further market encroachments by Arista Networks, currently well entrenched in low-latency application environments, and also to potentially inoculate against potential traction from SDN startups such as Nicira and Big Switch.

As for the second option, he envisions something proceeding along an “SDN OpenFlow strategy path.” In this scenario, Koss foresees a  new platform that functions as a “Nexus OS-to-OpenFlow arbitration box,” which he describes as analogous to a session border controller (SBC) between the two networks. This would give Cisco’s installed base to SDN-like capabilities while keeping them wrapped inside Cisco’s proprietary cocoon.

Surprise Not Likely

In my view, both paths described by Koss are plausible scenarios for Insieme.  My gut feeling is that the first is more likely. The second option is more software intensive, and it would seem to feature less of the ASIC and storage-networking expertise possessed by known members of the Insieme team. Perhaps Mario, Luca, and Prem will blaze an entirely different path and surprise us all, but Koss might be on the right track with his speculative musings.

As always, we shall see.