SDN’s Continuing Evolution

At the risk of understatement, I’ll begin this post by acknowledging that we are witness to intensifying discussion about the applicability and potential of software-defined networking (SDN). Frequently, such discourse is conjoined and conflated with discussion of OpenFlow.

But the two, as we know, are neither the same nor necessarily inextricable. Software-defined networking is a big-picture concept involving controller-driven programmable networks whereas OpenFlow is a protocol that enables interaction between a control plane and the data plane of a switch.

Not Necessarily Inextricable

A salient point to remember — there are others, I’m sure, but I’m leaning toward minimalism today — is that, while SDN and OpenFlow often are presented as joined at the hip, they need not be. You can have SDN without Open Flow. Furthermore, it’s worth bearing in mind that the real magic of SDN resides beyond OpenFlow’s reach, at a higher layer of  abstraction in the SDN value hierarchy.

So, with that in mind, let’s take a brief detour into SDN history, to see whether the past can inform the present and illuminate the future. I was fortunate enough to have some help on this journey from  Amin Tootoonchian, a PhD student in the Systems and Networking Group, Department of Computer Science, University of Toronto.

Tootoonchian is actively involved in research projects related to software-defined networking and OpenFlow. He wrote a paper in conjunction with Yashar Ganjali, his advisor and an assistant professor at the University of Toronto, on HyperFlow, an application that runs on the open-source NOX controller to create a logically centralized but physically distributed control plane for OpenFlow. Tootoonchian developed and implemented HyperFlow, and he also is working on the next release of NOX. Recently, he spent six months pursuing SDN research at the University of California Berkeley.

His ongoing research has afforded insights into the origins and evolution of SDN. During a discussion over a coffee, he kindly recommended some reference material for my edification and enlightenment. I’m all for generosity here, so I’m going to share those recommendations with you over in what might become a series of posts. (I’d like to be more definitive, I really would, but I never know where I’m going to steer this thing I call a blog. It all comes down to time, opportunity, circumstances, and whether I get hit by a bus.)

Anyway, let’s start, strangely enough, at the beginning, with SDN concepts that ultimately led to the development of the OpenFlow protocol.

4D and Ethane: SDN Milestones 

Tootoonchian pointed me to papers and previous research involving academic projects such as 4D and Ethane, which served as recent antecedents to OpenFlow. There are other papers and initiatives he mentioned, a few of which I will reference, if all goes according to my current plan, in forthcoming posts.

Before 4D and Ethane, however, there were other SDN predecessors, most of which were captured in a presentation by Edward Crabbe, network architect at Google. Helpfully titled “The (Long) Road to SDN,” Crabbe’s presentation was given at a Tech Field Day last autumn.

Crabbe draws an SDN evolutionary line from Ipsilon’s General Switch Management Protocol (GSMP) in 1996 through a number of subsequent initiatives — including the IEFT’s Forwarding and Control Element Separation (FORCES) and Path Computation Element (PCE) working groups — gradually progressing toward the advent of OpenFlow in 2008. He points to common threads in SDN that include partitioning of resources and control within network elements; and minimization of the network-element local control plane, involving offline control of forwarding state and offline control of network-element resource allocation.

As for why SDN has drawn growing interest, development and support, Crabbe cites two main reasons: cost and “innovation velocity.” I (and others) have touched on the cost savings previously, but Crabble’s particular view from the parapets of Google warrants attention.

Capex and Opex Savings 

In his presentation, Crabbe cites cost savings relating to both capital and operating expenditures.

On the capex side, he notes that SDN can deliver efficient use of  IT infrastructure resources, which, I note, results in the need to purchase fewer new resources. He makes particular mention of how efficient resource utilization applies to network element CPU and memory as well as to underlying network capacity. He also notes SDN’s facility at moving the “heaviest workloads off expensive, relatively slow embedded systems to cheap, fast, commodity hardware.” Unstated, but seemingly implicit, is that the former are often proprietary whereas the latter are not.

Crabbe also mentions that capex savings can accrue from SDN’s ability to “provide visibility into, and synchronized control of, network state, such that underlying capacity may be used more efficiently.” Again, efficient utilization of the resources one owns means one derives full value from them before having to allocate spending to the purchase of new ones.

As for lower operating expenditures, Crabbe broadly states that SDN enables reduced network complexity, which results in less operational overhead and fewer outages. He offers a number of supporting examples, and the case he makes is straightforward and valid. If you can reduce network complexity, you will mitigate operational risk, save time, boost network-related productivity, and perhaps get the opportunity to allocate valuable resources to other, potentially more productive uses.

Enterprise Narrative Just Beginning 

Speaking of which, that brings us to Crabbe’s assertion that SDN confers “innovation velocity.” He cites several examples of how and where such innovation can be expedited, including faster feature implementation and deployment; partitioning of resources and control for relatively safe experimentation; and implementations on “relatively simple, well-known systems with well-defined interfaces.” Finally, he also emphasizes that the decoupling of the control plane from the network element facilitates “novel decision algorithms and hardware uses.”

It makes sense, all of it, at least insofar as Google is concerned. Crabbe’s points, of course, are similarly valid for other web-scale, cloud service providers.  But what about enterprises, large and small? Well, that’s a question still to be explored and answered, though the early adopters IBM and NEC brought forward earlier this week indicate that SDN also has a future in at least a few enterprise application environments.

IBM and NEC Find Early Adopters for OpenFlow-based SDNs

News arrived today that IBM and NEC have joined forces to work on OpenFlow deployments. The two companies’ joint solution integrates IBM’s Open Flow-enabled RackSwitch G8264 10/40GbE top-of-rack switch with NEC’s ProgrammableFlow Controller, PF5240 1/10 Gigabit Ethernet Switch, and PF5820 10/40 Gigabit Ethernet Switch.

What’s more, the two technology partners boast early adopters, who are using OpenFlow-based software-defined networks (SDNs) for real-world applications.

Actual Deployments by Early Adopters

Granted, one of those organizations, Stanford University, is firmly ensconced in academia, but the other two are commercial concerns, which are using the technology for applications that apparently confer significant business value. As Stacey Higginbotham writes at GigaOm, these deployments validate the commercial potential of SDNs that utilize the OpenFlow protocol in enterprise environments.

The three early adopters cover some intriguing application scenarios. Tervela, a purveyor of a distributed data fabric,  says the joint solution delivers dynamic networking that ensures predictable performance of Big Data for complex, demanding applications such as global trading, risk analysis, and e-commerce.

Another early adopter is Selerity Corporation. At Network Computing, Mike Fratto provides an excellent overview of how Selerity — which provides real-time, machine-readable financial information to its subscribers — is using the technology to save money and reduce complexity by replacing a convoluted set of VLANs, high-end firewalls, and  application-level processes with flow rules defined on NEC’s Programmable Flow Controller.

More to Come

Stanford, which, along with the University of California Berkeley, first developed the OpenFlow protocol, is using the NEC-IBM networking gear to  deploy a campus-wide experimental network that will run alongside its production backbone network. As Higginbotham writes (see link above), Stanford is using network programmability to provision bandwidth on demand for campus researchers.

It’s good to read details about OpenFlow deployments and about how bigger-picture SDNs can be applied for real-world benefits. I suspect we’ll be reading about more SDN deployments as the year progresses.

One quibble I have with the IBM press release is that it does not demarcate clearly between where OpenFlow ends at the controller and where SDN abstraction and higher-layer application intelligence take over.

Applications Drive Adoption

Reading about these early deployments, I couldn’t help but conclude that most of the value — and doubtless professional-service revenue for IBM — is derived through the application logic that informs the controller. Those applications ride above OpenFlow, which only serves the purpose of allowing the controller to communicate with the switch so that it forwards packets in a prescribed manner.

Put another way, as pointed out by those with more technical acumen than your humble scribe, OpenFlow is a protocol for interaction between the control and the forwarding plane. It serves a commendable purpose, but it’s a purpose that can be fulfilled in other ways.

What’s compelling and potentially unique about emerging SDNs are the new applications that drive their adoption. Others have written about where SDNs do and don’t make sense, and now we’re beginning to see tangible confirmation from the marketplace, the ultimate arbiter of all things commercial.

Exploring the Symbiosis Between Merchant Silicon and Software-Defined Networking

In a recent post at EtherealMind.com, Greg Ferro examined possible implications associated with the impending dominance of merchant silicon in the networking industry.

Early in his post, Ferro reproduces a Broadcom graphic illustrating that the major switch vendors all employ Broadcom’s Trident chipset family in their gear. Vendors represented on the graphic include Cisco, Juniper, Dell, Arista, HP, IBM (BNT), and Alcatel-Lucent.

Abyss Awaits

Custom switching ASICs haven’t gone the way of eight-track cartridges just yet, but the technology industry’s grim reaper is quickening his loping stride and approaching at a baleful gallop, scythe at the ready. Interrelated economic and technological factors have conspired, as they will, to put the custom ASIC on a terminal path.

There’s a chicken-and-egg debate as to whether economics occasioned and hastened this technological change or whether the causation was reversed, but, either way, the result will be the same. At some point, for switching purposes, it will become counterproductive and economically untenable to continue to design, develop, and incorporate custom ASICs into shipping products.

What’s more, the custom ASIC’s trip to the boneyard will be expedited, at least in part, by the symbiotic relationship that has developed between merchant silicon and software-defined networking (SDN).

Difficult Adjustment for Some

Commercially, of course, merchant silicon preceded SDNs by a number of years. Recently, however, the two have converged dynamically, so much so that, as Ferro acknowledges, future differentiation in networking will derive overwhelmingly from advances in software rather than from those in hardware. Vendors will offer identical hardware. They will compete on the basis of their software, including the applications and, yes, the management capabilities they bring to market.

For companies that have marketed and sold their products primarily on the basis of hardware speeds and feeds and associated features and benefits, the adjustment will be difficult.  The bigger the ship, the harder it will be to turn.

There are some caveats, of course. While seemingly inevitable, this narrative could take some time to play out.  Although the commercial success of merchant silicon was not contingent on the rise of software-defined networks, the continued ascent of the latter will accelerate and cement the dominance of the former. To the extent that the SDN movement — perhaps torn between OpenFlow and other mechanisms and protocols — fragments or is otherwise slowed in its progress, the life of the custom ASIC might be prolonged.

Timing the Enterprise Transition

Similarly, even if we presuppose that SDN technology and its ecosystem progress smoothly and steadily, SDN is likely to gain meaningful traction first with service providers and only later with enterprises. That said, the line demarcating enterprises and service providers will move and blur as applications and infrastructure migrate, in whole or in part, to the cloud. It’s anybody’s guess as to when and exactly how that transition will transform the enterprise-networking market, but we can see the outlines of change on the horizon.

Nothing ever plays out in the real world exactly as it does on paper, so I expect complications to spoil the prescience of the foregoing forecast.

Still, I know one thing for sure: As the SDN phenomenon eventually takes hold, the role of the switch will change, and that means the design of the switch will change. If the switch is destined to become a dumbed-down data-forwarding box, it doesn’t need a custom ASIC. Merchant silicon is more than up to that task.

Big Switch Hopes Floodlight Draws Crowd

As the curtain came down on 2011, software-defined networking (SDN) and its open-source enabling protocol, OpenFlow, continued to draw plenty of attention. So far, 2012 has been no different, with SDN serving as a locus of intense activity, heady discourse, and steady technological advance.

Just last week, for instance, Big Switch Networks announced the release of Floodlight, a Java-based, Apache-licensed OpenFlow controller. In making Floodlight available under the Apache license, which allows the code to be reused for both research and commercial purposes, Big Switch hopes to establish the controller as a platform for OpenFlow application development.

Big Switch acknowledges that other OpenFlow controllers are available — the company even asks rhetorically, in a blog post accompanying the announcement, whether the world really needs another OpenFlow controller — but it believes that Floodlight is differentiated through its ease 0f use, extensibility, and robustness.

Controller as Platform 

I think we all realize by now that OpenFlow is just an SDN protocol. It allows data-path flow tables on switches to be programmed by a software-based controller, represented by the likes of Floodlight.  While OpenFlow might be essential as a mechanism for the realization of software-defined networks, it is not where SDN business value will be delivered or where vendors will find their pots of gold.

Next up in the hierarchy of SDN value are the controllers. As Big Switch recognizes, they can serve as platforms for SDN application development. Many vendors, including HP, believe that applications will define the value (and hence the money-making potential) in the SDN universe. That’s a fair assumption.

Big Switch Networks has indicated that it wants to be the “VMware of networking,” delivering network virtualization and providing enterprise-oriented OpenFlow applications. If it can establish its controller as a popular platform for OpenFlow application development, it will set a foundation both for its own commercial success as well as for enterprise OpenFlow in general.

Seeking Enterprise Value

The key to success, of course, will be the degree to which the applications, and the business value that accrues from them, are compelling. We’ll also see management and orchestration, perhaps integrated with the controller(s), but the commercial acceptance of the applications will determine the need and scope for automated management of the overall SDN environment. This is particularly true in the enterprise market that Big Switch has targeted.

What will those enterprise applications be? Well, if I knew answer to that question, I might be on a personal trajectory to obscene wealth, membership in an exclusive secret society, and perhaps ownership of a professional sports team (or, at minimum, a racehorse).

Service Providers Have Different Agenda

Meanwhile, in the rarefied heights of the largest cloud providers, such as the companies that populate the board at the Open Networking Foundation (ONF), I suspect that nearly everything of meaningful business value connected with OpenFlow and SDN will be done internally. Google and Facebook, for instance, will design and build (perhaps through ODMs) their own bare-bones servers and switches, and they will develop their own SDN controllers and applications. Their network infrastructure is a business asset, even a competitive advantage, and they will prefer to build and customize their own SDN environments rather than procure products and solutions from networking vendors, whether established players or startups.

Most enterprises, though, will be inclined to look toward the vendor community to equip them with SDN-related products, technologies, and expertise. This is presuming, of course, that an enterprise market for OpenFlow-based SDNs actually finds its legs.

Plenty of Work Ahead

So, again, it all comes back to the power and value of the applications, and this is why Big Switch is so keen to open-source its controller.  The enterprise market for OpenFlow-based SDNs won’t grow unless IT departments are comfortable adopting it. Vendors such as Big Switch will have to demonstrate that they are safe bets, capable of providing unprecedented value at minimal risk.

It’s a daunting challenge. OpenFlow definitely possesses long-term enterprise potential, but today it remains a long way from being able to check all the enterprise boxes. Big Switch, not to mention the enterprise OpenFlow community, needs a meaningful ecosystem to materialize sooner rather than later.

Why Nicira Says Networking Doesn’t Need a VMware

At Martin Casado’s Network Heresy blog yesterday, a guest post was offered by Andrew Lambeth, who once led the vDS distributed switching project at VMware but is now, like Casado, ensconced at Nicira.  The post was titled provocatively, “Networking Doesn’t Need a VMWare.”

It was different in substance and tone from Casado’s posts, which typically are balanced, logical, and carefully constructed. I appreciate those qualities. Words matter, and Casado invariably takes the time to choose the right ones and to compose posts that communicate complicated ideas clearly. Even better, he does so without undue vendor bias.

Maybe he’s really a shrewd master of manipulation, but I always get the impression Casado is sincere, that he means what he says and says what he means.  One actually learns something from reading his blog. That’s always refreshing, in this industry or any other.

Defining (or Redefining) Network Virtualization 

As I said, the post from Lambeth was a departure in more ways than one. It was logical and carefully constructed, just like Casado’s writing, but it did not attempt to achieve any sort of balance. Instead, given the venue, it was strikingly partisan and tendentious.

Despite the technical window-dressing, it was devised to differentiate and distinguish Nicira’s approach to network virtualization from those of other players in the space, established vendors and startups alike. It also sought, implicitly if not explicitly, to derogate OpenFlow in the still-unfolding SDN hierarchy of value.

Just to summarize, though I encourage you to read the post yourself, Lambeth argues that, while there’s industry consensus on the desirability of network virtualization, there’s a significant difference of opinion on how it should be achieved. Network virtualization is not at all the same as server virtualization, he writes, citing the need in the former for “scale (lots of it) and distributed state consistency.” He concludes by saying that the current preoccupation with the data path, the realm of OpenFlow, is akin to “worrying about a trivial component of an otherwise enormously challenging problem.”

Positioning and Differentiation

Commenting on Lambeth’s post, Chris Hoff, formerly of Cisco and now with Juniper Networks (and a prolific tweeter,  I might add), concluded correctly that it “smacks of positioning against both OpenFlow as well as other network virtualization startups.”

In issuing that positioning statement, Nicira not only is attempting to distance itself from the OpenFlow crowd; it also has at least a couple specific vendors in mind.

One obvious target is Big Switch Networks. If you visit that vendor’s website,  you will find that it expresses unqualified love for OpenFlow on its home page. It also says candidly that “networking needs a VMware.” Diametrically opposing that view, Nicira says networking doesn’t need a VMware. Furthermore, as I noted in a previous post, Nicira continues to  expend considerable effort to downplay the significance of OpenFlow.

Thinking Beyond Big Switch

But Nicira is thinking about competitors other than Big Switch, too. Readers of this blog will know that of one of my recurring themes — some would call it a conspiracy theory — is that the VCE partnership between Cisco and EMC is subject to increasing strain and tension. In short, EMC acquired VMware, Cisco didn’t, and now virtualization — and maybe VWware — is becoming integral to the future of networking.

Nicira’s Lambeth, formerly involved with distributed switching at VMware, and his counterparts at Big Switch agree that network virtualization is important. Where they disagree, perhaps, is in how it should be achieved.

Meanwhile, both vendors at one time or another, as Lambeth concedes at the outset of his post, have espoused variations on the claim that “networking needs a VMware.” Apparently, the team at Nicira has reconsidered that premise and is going in a different direction.

It might have adjusted course for reasons other than (or in addition to) those relating to architecture and technological requirements.

VMware’s Networking Ambitions

You see, VMware seems to believe that networking already has a VMware, whose name, conveniently enough, is VMware. Circumstantial evidence, including a recent post by VMware CTO Steve Herrod, suggests that VMware has ambitions that extend beyond server virtualization and well into network virtualization. Back in June, Greg Ferro also noted VMware’s interest in carving out a significant role for itself in network virtualization. In his commentary, Ferro cited a post by Allwyn Sequeira, security CTO at VMWare.

Herrod has predicted that “software-defined networking will become a mainstay of data- center architectures” in 2012. It’s safe to assume that he foresees his company playing a major part in making his prognostication a reality.

Questioning Cisco’s CES Presence

In a recent piece at Forbes, Roger Kay complained that parasitic vendors are killing the annual Consumer Electronics Show (CES) in Las Vegas, the 2012 edition of which kicks off next week. When Kay refers to parasites, he means vendors that avail themselves of nearby hotel suites, where they host and entertain a select audience of invitation-only customers and partners, while evading the time-sucking clutches of the hoi polloi that pack the show floor.

As a vendor strategy, Kay allows, the hotel-suite gambit might make sense, but he’s concerned about the effect of the big-vendor exodus from the show floor. Among the industry players Kay calls on the carpet are Microsoft (exhibiting for the last time at CES this year), Dell, Acer, and Cisco.

Avoiding the Floor, Not the Show

Cisco? Yes, that Cisco. The networking titan that was supposed to be refocusing away from consumerist distractions has decided to hole up in a Las Vegas hotel suite next week on the periphery of a consumer-oriented electronics trade show. Unlike Kay, my problem with Cisco at CES is not that it prefers a sumptuous hotel suite to the lesser glories of the show floor, but that it will be there at all.

In the long-ago spring of 2011, when Cisco announced that it was immolating its Flip video camcorder business, the company stated that it was refocusing around five key technology areas: routing, switching, and services; collaboration; data center virtualization and the cloud; architectures; and video. Despite the apparent contradiction that Cisco was killing the Flip video camcorder while strategically prioritizing video, it seemed pretty clear Cisco’s denotation of “video” encompassed enterprise-related video, such as telepresence and videoconferencing, rather than the consumer-oriented video represented by the defunct Flip.

Belated Acknowledgment

Or did it? After all, Cisco kept its consumer-oriented umi telepresence systems even as it binned Flip. Then again, Cisco belatedly acknowledged that particular error of omission, recently shuttering the umi business, such as it was.

That means Cisco finally is getting itself aligned with its strategic mandate — except, of course, when it isn’t. You see, Cisco still has its home-networking offerings, represented by the Linksys product portfolio, and, unless the company is exceptionally free with its definitions and interpretations, it would encounter great difficulty reconciling that business with its self-proclaimed strategic priorities.

Last year, Cisco said it would attempt to align the Linksys business with its core network-infrastructure business, though that would appear more a theoretical than a practical exercise. Meanwhile, some analysts expected Cisco to divest its low-growth, low-margin consumer businesses, but Cisco’s home-networking group, which definitely checks those divestiture-qualifying boxes, remains in the corporate fold.

Still, speculation persists about a potential sale of the Linksys unit, even as representatives of that unit attempt to portray it as a “key part” of Cisco’s strategy.  According to that defiant narrative, Linksys’ solutions are supposed to be the centerpiece of a master plan that would put Cisco at the forefront of home-entertainment networks that distribute Internet-based video throughout the home to devices such as television sets and BluRay players. But with Cisco’s recent retreat from its umi videoconferencing, the company has decided that it will refrain from handling at least one type of video content in the home.

More Strategic Rigor Required

Look, I understand why Cisco likes video. It consumes a lot of bandwidth, and that means Cisco’s customers, including telcos and cable MSOs as well as enterprises, will need to spend more on network infrastructure to accommodate the rising tide of video traffic. I get the synergies with its core businesses, I really do.

But is Cisco truly equipped as a vendor and a brand that can win the hearts and minds of consumers and cross the threshold into the home? The company’s track record would suggest that the answer to that question is an emphatic and resounding no. Furthermore, does Cisco really need to be in the home to capture its “fair share” of video-based revenue? Again, the answer would seem to be negative.

When I read that Cisco was ramping up for CES, even though it doesn’t have a booth on the show floor, I was reminded that the company still needs to apply more rigor to its refocusing efforts. In the big picture, perhaps the resources expended to stage a consumer-oriented promotional blitz in Las Vegas next week do not distract significantly from Cisco’s professed strategic priorities. Nonetheless, I would argue that its CES excursion doesn’t help, and that an opportunity cost is still being incurred.

Dell’s Bid for Data-Center Distinction

Since Dell’s acquisition of Force10 Networks, many of us have wondered how Dell’s networking business, under the leadership of former Cisco Systems executive Dario Zamarian, would chart a course of distinction in data-center networking.

While Zamarian has talked about adding Layer 4-7 network services, presumably through acquisition, what about the bigger picture? We’ve pondered that question, and some have asked it, including one gentleman who posed the query on the blog of Brad Hedlund, another former Ciscoite now at Dell.

Data Center’s Big Picture

The question surfaced in a string of comments that followed Hedlund’s perceptive analysis of Embrane’s recent Heleos unveiling. Specifically, the commenter asked Hedlund to elucidate Dell’s strategic vision in data-center networking. He wanted Hedlund to provide an exposition on how Dell intended to differentiate itself from the likes of Cisco’s UCS/Nexus, Juniper’s QFabric, and Brocade’s VCS.

I quote Hedlund’s response:

 “This may not be the answer you are looking for right now, but .. Consider for a moment that the examples you cite; Cisco UCS/Nexus; Juniper QFabric; Brocade VCS — all are either network only or network centric strategies. Think about that for a second. Take your network hat off for just a minute and consider the data center as a whole. Is the network at the center of the data center universe? Or is network the piece that facilitates the convergence of compute and storage? Is the physical data center network trending toward a feature/performance discussion, or price/performance?

Yes, Dell now has a Tier 1 data center network offering with Force10. And with Force10, Dell can (and will) win in network only conversations. Now consider for a moment what Dell represents as a whole .. a total IT solutions provider of Compute, Storage, Network, Services, and Software. And now consider Dell’s heritage ofproviding solutions that are open, capable, and affordable.”

Compare and Contrast

It’s a fair enough answer. By reframing the relevant context to encompass the data center in its entirety, rather than just the network infrastructure, Dell can offer an expansive value-based, one-stop narrative that its rivals — at least those cited by the questioner –  cannot match on their own.

Let’s consider Cisco. For all its work with EMC/VMware and NetApp on Vblocks and FlexPods, respectively, Cisco does not provide its own storage technologies for converged infrastructure. Juniper and Brocade are pure networking vendors, dependent on partners for storage, compute, and complementary software and services.

HP, though not cited by the commenter in his question, is one Dell rival that can offer the same pitch. Like Dell, HP offers data-center compute, storage, networking, software, and services. It’s true, though, that HP also resells networking gear, notably Brocade’s Fibre Channel storage-networking switches. The same, of course, applies to Dell, which also continues to resell Brocade’s Fibre Channel switches and maintains — at least for now — a nominal relationship with Juniper.

IBM also warrants mention. Its home-grown networking portfolio is restricted to the range of products it obtained through its acquisition of Blade Network Technologies last year. Like HP, but to a greater degree, IBM resells and OEMs networking gear from other vendors, including Brocade and Juniper. It also OEMs some of its storage portfolio from NetApp, but it also has a growing stable of orchestration and management software, and it definitely has a prodigious services army.

Full-Course Fare 

Caveats aside, Dell can tell a reasonably credible story about its ability to address the full range of data-center requirements. Dell’s success with that strategy will depend not only its sales execution, but also on its capacity to continually deliver high-quality solutions across the gamut of compute, storage, networking, software, and services. Offering a moderately tasty data-center repast won’t be good enough.  If Dell wants customers to patronize it and return for more, it must deliver a savory menu spanning every course of the meal.

To his credit, Hedlund acknowledges that Dell must be “capable.” He also notes that Dell must  be open and affordable. To be sure, Dell doesn’t have the data-center brand equity to extract the proprietary entitlements derived from vendor lock-in, certainly not in the networking sphere, where even Cisco is finding that game to be harder work these days.

Dell, HP, and IBM each might be able to craft a single-vendor narrative that spans the entire data center, but the cogency of those pitches are only as credible as the solutions the vendors deliver. For many customers, a multivendor infrastructure, especially in a truly interoperable standards-based world, might be preferable to a soup-to-nuts solution from a single vendor. That’s particularly true if the single-vendor alternative has glaring deficiencies and weaknesses, or if it comes with perpetual proprietary overhead and constraints.

Still Early

I think the real differentiation isn’t so much in whether data-center solutions are delivered by a single vendor or by multiple vendors. I suspect the meaningful differentiation will be delivered in how those environments are further virtualized, automated, orchestrated, and managed as coherent unified entities.

Dell has bought itself a seat at the table where that high-stakes game will unfold. But it isn’t alone, and the big cards have yet to be played.

Reflecting on the Big Acquisition Cisco Didn’t Make

It has been nearly eight years since EMC acquired VMware. The acquisition announcement went over the newswires on December 15, 2003. EMC paid approximately $635 million for VMware, and Joe Tucci, EMC’s president and CEO, had this to say about the deal:

“Customers want help simplifying the management of their IT infrastructures. This is more than a storage challenge. Until now, server and storage virtualization have existed as disparate entities. Today, EMC is accelerating the convergence of these two worlds .“

“We’ve been working with the talented VMware team for some time now, and we understand why they are considered one of the hottest technology companies anywhere. With the resources and commitment of EMC behind VMware’s leading server virtualization technologies and the partnerships that help bring these technologies to market, we look forward to a prosperous future together.”

Virtualization Goldmine

Oh, the future was prosperous . . . and then some. It’s a deal that worked out hugely in EMC’s favor. Even though the storage behemoth has spun out VMware in the interim, allowing it to go public, EMC still retains more than 80 percent ownership of its virtualization goldmine.

Consider that EMC paid just $635 million in 2003 to buy the server-virtualization market leader. VMware’s current market capitalization is more than $38 billion. That means EMC’s stake in VMware is worth more than $30 billion, not including the gains it reaped when it took VMware public. I don’t think it’s hyperbolic to suggest that EMC’s purchase of VMware will be remembered as Tucci’s defining moment as EMC chieftain.

Now, let’s consider another vendor that had an opportunity to acquire VMware back in 2003.

Massive Market Cap, Industry Dominance

A few years earlier, at the pinnacle of the dot-com boom in March 2000, Cisco was the most valuable company in the world, sporting a market capitalization of more than US$500 billion.  It was a networking colossus that bestrode the globe, dominating its realm of the industry as much as any other technology company during any other period. (Its only peers in that regard were IBM in the mainframe era and Microsoft and Intel in the client-server epoch.)

Although Juniper Networks brought its first router to market in the fall of 1998 and began to challenge Cisco for routing patronage at many carriers early in the first decade of the new millennium, Cisco remained relatively unscathed in enterprise networking, where its Catalyst switches grew into a multibillion-dollar franchise after it saw off competitive challenges in the late 90s from companies such as 3Com, Cabletron, Nortel, and others.

As was its wont since its first acquisition, involving Crescendo Communications in 1993, Cisco remained an active buyer of technology companies. It bought companies to inorganically fortify its technological innovation, and to preclude competitors from gaining footholds among its expanding installed base of customers.

Non-Buyer’s Remorse?

It’s true that the post-boom dot-com bust cooled Cisco’s acquisitive ardor. Nonetheless, the networking giant made nine acquisitions from May 2002 through to the end of 2003. The companies Cisco acquired in that span included Hammerhead Networks, Navarro Networks, AYR Networks, Andiamo Systems, Psionic Software, Okena, SignalWorks, Linksys, and Latitude Communications.

The biggest acquisition in that period involved spin-in play Andiamo Systems, which provided the technological foundation for Cisco’s subsequent push to dominate storage networking. Cisco was at risk of paying as much as $2.5 billion for Andiamo, but the actual price tag for that convoluted spin-in transaction was closer to $750 million by the time it finally closed in 2004. The next-biggest Cisco acquisition during that period involved home-networking vendor Linksys, for which Cisco paid about $500 million.

Cisco announced the acquisitions of Hammerhead Networks and Navarro Networks in a single press release. Hammerhead, for which Cisco exchanged common stock valued at up to $173 million, developed software that accelerated the delivery of IP-based billing, security, and QoS; the company was folded into the Cable Business Unit in Cisco’s Network Edge and Aggregation Routing Group. Navarro Networks, for which Cisco exchanged common stock valued at up to $85 million, designed ASIC components for Ethernet switching.

To acquire AYR Networks, a vendor of “high-performance distributed networking services and highly scalable routing software technologies,” Cisco parted with about $113 million in common stock. AYR’s technology was intended to augment Cisco’s IOS software.

Andiamo Factor

Although the facts probably are familiar to many readers, Cisco’s acquisition of Andiamo was noteworthy for several reasons.  It was a spin-in acquisition, in which Cisco funded the company to go off and develop technology on its own, only later to be brought back in-house through acquisition. Andiamo was led by its CEO Buck Gee, and it included a core group of engineers who also were at Cresendo Communications.  The concept and execution of the spin-in move at Cisco was highly controversial within the company, seen as operationally and strategically innovative by many senior executives even though others claimed it engendered envy, invidious, and resentment among rank-and-file employees.

No matter, Andiamo was meant to provide market leadership for Cisco in the IP-based storage networking and to give Cisco a means of battering Brocade in Fibre Channel. That plan hasn’t come to fruition, with Brocade still leading in a tenacious Fibre Channel market and Cisco banking on Fibre Channel over Ethernet (FCoE) to go from the edge to the core. (The future of storage networking, including the often entertaining Fiber Channel-versus-FCoE debates, are another matter, and not within the purview of this post.)

While we’re on the topic of Andiamo, its former engineers continue to make news. Just this week, former Andiamo engineers Dante Malagrinò and Marco Di Benedetto officially launched Embrane, a company that is committed to delivering a platform for virtualized L4-7 network services at large cloud service providers. Those two gentlemen also were involved in Cisco last big spin-in move, Nuova Systems, which provided the foundation for Cisco’s Unified Computing Systems (UCS).

As for Cisco’s post-Andiamo acquisition announcements in 2002, Okena and Psionic both were involved in intrusion-detection technology. Of the two, Okena represented the larger transaction, valued at about $154 million in stock.

Interestingly, not much is available publicly these days regarding Cisco’s announced acquisition of SignalWorks in March of 2003. If you visit the CrunchBase profile for SignalWorks and click on a link that is supposed to take you to a Cisco press release announcing the deal, you’ll get a “Not Found” message. A search of the Cisco website turns up two press releases — relating to financial results in Cisco’s third and fourth quarters of fiscal year 2003, respectively — that obliquely mention the SignalWorks acquisition. The purchase price of the IP-audio company was about $16 million. CNet also covered the acquisition when it first came to light.

Other Strategic Priorities

Cisco’s last announced acquisitions in that timeframe involved home-networking player Linksys, part of Cisco’s ultimately underachieving bid to become a major player in the consumer space, and web-conferencing vendor Latitude Communications.

And now we get the crux of this post. Cisco announced a number of acquisitions in 2002 and 2003, but it was one they didn’t make that reverberates to this day. It was a watershed acquisition, a strategic masterstroke, but it was made by EMC, not by Cisco. As I said, the implications resound through to this day and probably will continue to ramify for years to come.

Some might contend that Cisco perhaps didn’t grasp the long-term significance of virtualization. Apparently, though, some at Cisco were clamoring for the company to buy VMware.  The missed opportunity wasn’t attributable to Cisco failing to see the importance of virtualization — some at Cisco had the prescience to see where the technology would lead — but because an acquisition of VMware wasn’t considered as high a priority as the spin-in of Andiamo for storage networking and the acquisition of Linksys for home networking.

Cisco placed its bets elsewhere, perhaps thinking that it had more time to develop a coherent and comprehensive strategy for virtualization. Then EMC made its move.

Missed the Big Chance

To this day, in my view, Cisco is paying an exorbitant opportunity cost for failing to take VMware off the market, leaving it for EMC and ultimately allowing the storage leader, yeas later, to gain the upper hand in the Virtual Computing Environment (VCE) Company joint venture that delivers UCS-encompassing VBlocks. There’s a rich irony there, too, when one considers that Cisco’s UCS contribution to the VBlock package is represented by technology derived from spin-in Nuova.

But forget about VCE and VBlocks. What about the bigger picture? Although Cisco likes to talk itself up as a leader in virtualization, it’s not nearly as prominent or dominant as it might have been. Is there anybody who would argue that Cisco, if it had acquired and then integrated and assimilated VMware as half as well as it digested Crescendo, wouldn’t have absolutely thrashed all comers in converged data-center infrastructure and cloud infrastructure?

Cisco belatedly recognized its error of omission, but it was too late. By 2009, EMC was not interested in selling its majority stake in VMware to Cisco, and Cisco was in no position to try to obtain it through an acquisition of EMC. In that regard, Cisco’s position has only worsened.

Although EMC’s ownership stake in VMware amounts to about 80 percent (or perhaps even just north of that amount), its has 98 percent of the voting shares in the company, which effectively means EMC steers the ship, regardless of public pronouncements VMware executives might issue regarding their firm being an autonomous corporate entity.

Keeping Cisco Interested but Contained 

Conversely, Cisco owns approximately five percent of VMware’s Class A shares, but none of its Class B shares, and it held just one percent of voting power as of March 2011.  As of that same date, EMC owned all of VMware’s 330,000,000 Class B Shares and 33,066,050 of its 118,462,369 shares of Class A common shares. Cisco has a stake in VMware, but it’s a small one and it has it at the pleasure of EMC, whose objective is to keep Cisco sufficiently interested so as not to pursue other strategic options in data-center virtualization and cloud infrastructure.

The EMC gambit has worked, up to the point. But Cisco, which missed its big chance  in 2003, has been trying ever since then to reassert its authority. Nuova, and all that flowed from it, was Cisco’s first attempt to regain lost ground, and now it is partnering, to varying degrees, with VMware and EMC competitors such as NetApp, Citrix, and Microsoft. It also has gotten involved involved with OpenStack and the oVirt Project in a bid to hedge its virtualization bets.

Yes, some of those moves are indicative of coopetition, and Cisco retains its occasionally strained VCE joint venture with EMC and VMware, but Cisco clearly is playing for time, looking for a way to redefine the rules of the game.

What Cisco is trying to do is break an impasse of its own making, a result of strategic choices it made nearly a decade ago.

Embrane Emerges from Stealth, Brings Heleos to Light

I had planned to write about something else today — and I still might get around to it — but then Embrane came out of stealth mode. I feel compelled to comment, partly because I have written about the company previously, but also because what Embrane is doing deserves notice.

Embrane’s Heleos

With regard to aforementioned previous post, which dealt with Dell acquisition candidates in Layer 4-7 network services, I am now persuaded that Dell is more likely to pull the trigger on a deal for an A10 Networks, let’s say, than it is to take a more forward-looking leap at venture-funded Embrane. That’s because I now know about Embrane’s technology, product positioning, and strategic direction, and also because I strongly suspect that Dell is looking for a purchase that will provide more immediate payback within its installed base and current strategic orientation.

Still, let’s put Dell aside for now and focus exclusively on Embrane.

The company’s founders, former Andiamo-Cisco lads Dante Malagrinò and Marco Di Benedetto, have taken their company out of the shadows and into the light with their announcement of Heleos, which Embrane calls “the industry’s first distributed software platform for virtualizing layer 4-7 network services.” What that means, according to Embrane, is that cloud service providers (CSPs) and enterprises can use Heleos to build more agile networks to deliver cloud-based infrastructure as a service (IaaS). I can perhaps see the qualified utility of Heleos for the former, but I think the applicability and value for the latter constituency is more tenuous.

Three Wise Men

But I am getting ahead of myself, putting the proverbial cart before the horse. So let’s take a step back and consult some learned minds (including  an”ethereal” one) on what Heleos is, how it works, what it does, and where and how it might confer value.

Since the Embrane announcement hit the newswires, I have read expositions on the company and its new product from The 451 Group’s Eric Hanselman, from rock-climbing Ivan Pepelnjak (technical director at NIL Data Communications), and from EtherealMind’s Greg Ferro.  Each has provided valuable insight and analysis. If you’re interested in learning about Embrane and Heleos, I encourage you to read what they’ve written on the subject. (Only one of Hanselman’s two The 451 Group pieces is available publicly online at no charge).

Pepelnjak provides an exemplary technical description and overview of Heleos. He sets out the problem it’s trying to solve, considers the pros and cons of the alternative solutions (hardware appliances and virtual appliances), expertly explores Embrane’s architecture, examines use cases, and concludes with a tidy summary. He ultimately takes a positive view of Heleos, depicting Embrane’s architecture as “one of the best proposed solutions” he’s seen hitherto for scalable virtual appliances in public and private cloud environments.

Limited Upside

Ferro reaches a different conclusion, but not before setting the context and providing a compelling description of what Embrane does. After considering Heleos, Ferro ascertains that its management of IP flows equates to “flow balancing as a form of load balancing.” From all that I’ve read and heard, it seems an apt classification. He also notes that Embrane, while using flow management, is not an “OpenFlow/SDN business. Although I see conceptual similarities between what Embrane is doing and what OpenFlow does, I agree with Ferro, if only because, as I understand it, OpenFlow reaches no higher than the network layer. I suppose the same is true for SDN, but this is where ambiguity enters the frame.

Even as I wrote this piece, there was a kerfuffle on Twitter as to whether or to what extent Embrane’s Heleos can be categorized as the latest manifestation of SDN. (Hours later, at post time, this vigorous exchange of views continues.)

That’s an interesting debate — and I’m sure it will continue — but I’m most intrigued by the business and market implications of what Embrane has delivered. On that score, Ferro sees Embrane’s platform play as having limited upside, restricted to large cloud-service providers with commensurately large data centers. He concludes there’s not much here for enterprises, a view with which I concur.

Competitive Considerations

Hanselman covers some of the same ground that Ferro and Pepelnjak traverse, but he also expends some effort examining the competitive landscape that Embrane is entering. In that Embrane is delivering a virtualization platform for network services, that it will be up against Layer 4-7 stalwarts such as F5 Networks, A10 Networks, Riverbed/Zeus, Radware, Brocade, Citrix, Cisco, among others. F5, the market leader, already recognizes and is acting upon some of the market and technology drivers that doubtless inspired the team that brought Heleos to fruition.

With that in mind, I wish to consider Embrane’s business prospects.

Embrane closed a Series B round of $18 million in August. It was lead by New Enterprise Associates and included the involvement of Lightspeed Venture Partners and North Bridge Venture Partners, both of whom participated in a $9-million series A round in March 2010.

To determine whether Embrane is a good horse to back (hmm, what’s with the horse metaphors today?), one has to consider the applicability of its technology to its addressable market — very large cloud-service providers — and then also project its likelihood of providing a solution that is preferable and superior to alternative approaches and competitors.

Counting the Caveats

While I tend to agree with those who believe Embrane will find favor with at least some large cloud-service providers, I wonder how much favor there is to find. There are three compelling caveats to Embrane’s commercial success:

1. L4-7 network services, while vitally important cloud service providers and large enterprises, represent a much smaller market than L2-L3 networking, virtualized or otherwise. Just as a benchmark, Dell’Oro reported earlier this year that the L2-3 Ethernet Switch market would be worth approximately $25 billion in 2015, with the L4-7 application delivery controller (ADC) market expected to reach more than $1.5 billion, though the virtual-appliance segment is expected show most growth in that space. Some will say, accurately, that L4-7 network services are growing faster than L2-3 networking. Even so, the gap is size remains notable, which is why SDN and OpenFlow have been drawing so much attention in an increasingly virtualized and “cloudified” world.
2. Embrane’s focus on large-scale cloud service providers, and not on enterprises (despite what’s stated in the press release), while rational and perfectly understandable, further circumscribes its addressable market.
3. F5 Networks is a tough competitor, more agile and focused than a Cisco Systems, and will not easily concede customers or market share to a newcomer. Embrane might have to pick up scraps that fall to the floor rather than feasting at the head table. At this point, I don’t think F5 is concerned about Embrane, though that could change if Embrane can use NaviSite — its first customer, now owned by TimeWarner Cable — as a reference account and validator for further business among cloud service providers.

Notwithstanding those reservations, I look forward to seeing more of Embrane as we head into 2012. The company has brought a creative approach and innovation platform architecture to market, a higher-layer counterpart and analog to what’s happening further down the stack with SDN and OpenFlow.

BMC Still Likelier to Buy than to be Bought

After reading a recent Network Computing piece on BMC Software, it struck me that the management-software purveyor finds itself in a Darwinian dilemma: acquire or be acquired.

If it chooses to acquire, something to which it has not been averse previously, BMC might wish to make a play in enterprise mobility management (EMM) or mobile device management (MDM). As the article at Network Computing explains, that is a current area of need for BMC.  There’s no shortage of fish in that pond, and BMC is likely to find one at the right price.

Conversely, BMC might decide that it can’t compete in the long run with much bigger systems-management rivals such as IBM, HP, Microsoft, and Oracle. Even as BMC continues its transition toward defining itself as a multiplatform, hardware-neutral cloud-management vendor, it might conclude that the odds and resources stacked against are too great to overcome.

Dell Could Come Knocking

That, though, is by no means inevitable. The company has been independent for a long time — about 31 years, if we’re counting — and it has been subject to almost as many takeover rumors in the last few years as has F5 Networks. Still, like F5, it remains an independent company, and it might continue to do so indefinitely.

Nonetheless, if BMC finally chose to entertain a buyer, Dell might be at the front of the queue. Yes, we know that Dell is shopping for other goods — Dario Zamarian, Dell’s networking GM and SVP, has suggested that a purchase in L4-L7 network services might be forthcoming — and BMC’s price tag might be a bit steep (its market capitalization is about $6 billion).

Then again, Dell sees itself as an up-and-coming player in converged data-center infrastructure, and BMC offers management-software capabilities that Dell might need if it is to weave a compelling cloud-management narrative.

Intangibles and Existing Partnership

As for intangibles, Dell and BMC are very familiar with one another. The companies have partnered since 2002, working to accelerate IT deployment and configuration in a growing number of data centers. Dell has been a BMC customer for many years, too. Last and least, they’re both Texas-based companies.

The current arrangement between the two companies involves integration of Dell’s Advanced Infrastructure Manager (AIM) with BMC’s Atrium Orchestrator. It also encompasses BMC Asset Management as well as integration between BMC Server Automation (part of the BMC BladeLogic Automation Suite) and the Dell Lifecycle Controller.

If Dell were to acquire BMC, it obviously would want to squeeze more from the marriage. One possible scenario would involve Dell recreating and expanding upon the sort of engagement BMC has with Cisco pertaining to the latter’s Unified Computing System (UCS).

Congruent Messages

In this case, though, BMC’s software would be wedded to Dell’s evolving Virtual Integrated System (VIS). A lot of the marketing language Dell uses on its website is uncannily similar to the sort of pitch BMC makes for its cloud-management software. Both companies talk about automating and simplifying data-center environments, they both emphasize management of physical and virtual infrastructure, and they both stress the openness of their respective architectures, especially the ability to manage multiplatform (and multivendor) hardware and software.

In selling itself to Dell, though, BMC would be walking away from its relationship with Cisco, and its partnerships with some others, too. What’s more, Dell would assume ownership of some parts of the BMC business, such as mainframe-management software, that might not seem a great fit, at least at first glance.  Still, a Dell-BMC combination seems more plausible than fanciful.

If I were to wager on whether BMC will buy or be bought, though, it’s probably easier to imagine it buying an EMM or MDM vendor than to envision it getting scooped up at a potentially considerable premium by Dell (or another vendor). Even so, either outcome is within the realm of rational deduction.

U.S. National-Security Concerns Cast Pall over Huawei

As 2011 draws to a close, Huawei faces some difficult questions about its business prospects in the United States.  The company is expanding worldwide into enterprise networking and mobile devices, such as smartphones and tablets, even as it continues to grow its global telecommunications-equipment franchise.

Huawei is a company that generated 2010 revenue of about $28 billion, and it has an enviable growth profile for a firm of its size. But a dark cloud of suspicion continues to hang over it in the U.S. market, where it has not made headway commensurate with its success in other parts of the world. (As its Wikipedia entry states, Huawei’s products and services have been deployed in more than 140 countries, and it serves 45 of the world’s 50 largest telcos. None of those telcos are in the U.S.)

History of Suspicion

The reason it has not prospered in the U.S. is at primarily attributable to persistent government concerns about Huawei’s alleged involvement in cyber espionage as a reputed proxy for China. At this point, I will point out that none of the charges has been proven, and that any evidence against the company has been kept classified by U.S. intelligence agencies.

Nonetheless, innuendo and suspicions persist, and they inhibit Huawei’s ability to serve customers and grow revenue in the U.S. market. In the recent past, the U.S. government has admonished American carriers, including Sprint Nextel, not to buy Huawei’s telecommunications equipment on national-security concerns. On the same grounds, U.S. government agencies prevented Huawei from acquiring ownership stakes in U.S.-based companies such as 3Com, subsequently acquired by HP, and 3Leaf Systems. Moreover, Huawei was barred recently from participating in a nationwide emergency network, again for reasons of national security.

Through it all, Huawei has asserted that it has nothing to hide, that it operates no differently from its competitors and peers in the marketplace, and that it has no intelligence-gathering remit from the China or any other national government. Huawei even has welcomed an investigation by US authorities, saying that it wants to put the espionage charges behind it once and for all.

Investigation Welcomed

Well, it appears Huawei, among others, will be formally investigated, but it also seems the imbroglio with the U.S. authorities might continue for some time. We learned in November that the U.S. House Permanent Select Committee on Intelligence would investigate potential security threats posed by some foreign companies, Huawei included.

In making the announcement relating to the investigation, U.S. Representative Mike Rogers, a Michigan Republican and the committee’s chairman, said China has increased its cyber espionage in the United States. He cited connections between Huawei’s president, Ren Zhengfei, and the People’s Liberation Army, to which the Huawei chieftain once belonged.

For its part, as previously mentioned, Huawei says it welcomes an investigation. Here’s a direct quote from William Plummer, a Huawei spokesman, excerpted from a recent Bloomberg article:

“Huawei conducts its businesses according to normal business practices just like everybody in this industry. Huawei is an independent company that is not directed, owned or influenced by any government, including the Chinese government.”

Unwanted Attention from Washington

The same Bloomberg article containing that quote also discloses that the U.S. government has invoked  Cold War-era national-security powers to compel telecommunication companies, including AT&T Inc. and Verizon Communications Inc., to disclose confidential information about the components and composition of their networks in a hunt for evidence of Chinese electronic malfeasance.

Specifically, the U.S. Commerce Department this past spring requested a detailed accounting of foreign-made hardware and software on carrier networks, according to the Bloomberg article. It also asked the telcos and other companies about security-related incidents, such as the discovery of “unauthorized electronic hardware” or suspicious equipment capable of duplicating or redirecting data.

Brand Ambitions at Risk

The concerns aren’t necessarily exclusive to alleged Chinese cyber espionage, and Huawei is not the only company whose gear will come under scrutiny. Still, Huawei clearly is drawing a lot of unwanted attention in Washington.

While Huawei would like this matter to be resolved expeditiously in its favor, the investigations probably will continue for some time before definitive verdicts are rendered publicly. In the meantime, Huawei’s U.S. aspirations are stuck in arrested development.

To be sure, the damage might not be restricted entirely to the United States. As this ominous saga plays out, Huawei is trying to develop its brand in Europe, Asia, South America, Africa, and Australia. It’s making concerted advertising and marketing pushes for its smartphones in the U.K., among other jurisdictions, and it probably doesn’t want consumers there or elsewhere to be inundated with persistent reports about U.S. investigations into its alleged involvement with cyber espionage and spyware.

Indulge me for a moment as I channel my inner screenwriter.

Scenario: U.K. electronics retailer. Two blokes survey the mobile phones on offer. Bloke One picks up a Huawei smartphone. 

Bloke One: “I quite fancy this Android handset from Huawei. The price is right, too.”

Bloke Two: “Huawei? Isn’t that the dodgy Chinese company being investigated by the Yanks for spyware?

Bloke One puts down the handset and considers another option.

Serious Implications

Dark humor aside, there are serious implications for Huawei as it remains under this cloud of suspicion. Those implications conceivably stretch well beyond the shores of the United States.

Some have suggested that the U.S. government’s charges against Huawei are prompted more by protectionism than by legitimate concerns about national security. With the existing evidence against Huawei classified, there’s no way for the public, in the U.S. or elsewhere, to make an informed judgment.

Revisiting the Nicira Break-In

While doing research on my last post, I spent some time on Martin Casado’s thought-provoking blog, Network Heresy. He doesn’t generate posts prolifically — he’s preoccupied with other matters, including his job as chief technology officer at Nicira Networks — but his commentaries typically are detailed, illuminating, intelligent, and invariably honest.

One of his relatively recent posts, Origins and Evolution of OpenFlow/SDN, features a video of his keynote at the Open Networking Summit, where, as the title of the blog post advertises, he explained how SDNs and OpenFlow have advanced. His salient point is that it’s the community,  not the technology, that makes the SDN movement so meaningful.  The technology, he believes, will progress as it should, but the key to SDN’s success will be the capacity of the varied community of interests to cohere and thrive. It’s a valid point.

Serious Work

That said, that’s not the only thing that caught my interest in the keynote video. Early in that presentation, speaking about how he and others got involved with SDNs and OpenFlow, he talks about his professional past. I quote directly:

“Back in 2002-2003, post-9/11, I used to work for the feds. I worked in the intelligence sector. The team I worked with, we were responsible for auditing and securing some of the most sensitive networks in the United States. This is pretty serious stuff. Literally, if these guys got broken into, people died . . . We took our jobs pretty seriously.”

It doesn’t surprise me that OpenFlow-enabled SDNs might have had at least some of their roots in the intelligence world. Many technologies have been conceived and cultivated in the shadowy realms of defense and intelligence agencies. The Internet itself grew from the Advanced Research Projects Agency Network (ARPANET),  which was funded by the Defense Advanced Research Projects Agency (DARPA) of the United States Department of Defense.

Old-School Break-In

When I heard those words, however, I was reminded of the armed break-in that Nicira suffered last spring, first reported in a Newsweek cover story on the so-called “Code War” and cyber-espionage published in July.  What was striking about the breach at Nicira, both in and of itself and within the context of the Newsweek article, is that it was a physical, old-school break-in, not a cyber attack. An armed burglar wearing a ski mask broke into Nicira Networks and made his way purposefully to the desk of “one of the company’s top engineers.” The perpetrator then grabbed a computer, apparently containing source code, and took flight.

Palo Alto constabulary portrayed the crime as a bog-standard smash and grab, but “people close to the company” and national-intelligence investigators suspect it was a professional job executed by someone with ties to Russia or China. The objective, as one might guess, was to purloin intellectual property.

The involvement of national-intelligence investigators in the case served as a red flag signaling that the crime was not committed by a crank-addled junkie hoping to sell a stolen computer. There’s a bigger story, and Newsweek touched on it before heading off in a different direction to explore cyber espionage, hack attacks, and the code-warrior industry.

Nicira’s Stealth Mode

Last month, the New York Times mentioned the Nicira break-in during the course of an article titled “What Is Nicira Up To?”.

Indeed, that is a fair question to ask. There still isn’t much meat on the bones of Nicira’s website, though we know the company is developing a network-virtualization platform that decouples network services from the underlying hardware, “like a server hypervisor separates physical servers from virtual machines.”

It’s essentially software-defined networking (SDN), with OpenFlow in the mix, though Nicira refrained assiduously from using those words in its marketing messages. On the other hand, as we’ve already seen, CTO Martin Casado isn’t shy about invoking the SDN acronym, or providing learned expositions on its underlying technologies, when addressing technical audiences.

Mystery Remains 

Let’s return to the break-in, however, because the New York Times provided some additional information. We learn that a significant amount of Nicira’s intellectual property was on the purloined computer, though CEO Steven Mullaney said it was “very early stuff, nothing like what we’ve got now.”

Still, the supposition remained that the thief was an agent of a foreign government. We also learned more about Casado’s professional background and about the genesis of the technology that eventually would be developed further and commercialized at Nicira.  Casado’s government work took place at Lawrence Livermore National Laboratory, where he was asked by U.S. intelligence agencies to design a global network that would dynamically change its levels of security and authorization.

We might never discover who broke into Nicira last May. As the Newsweek story recounted, government investigators have advised those familiar with the incident not to discuss it. Questions remain, but the mystery is likely to remain unsolved, at least publicly.