Between What Is and What Will Be

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

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

Choppy Transition

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

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

No Wishful Thinking

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

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

Fighting Inevitability

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

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

Advertisement

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.

Inevitability of Virtualized Infrastructure

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

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

Loosening a Tenacious Grip

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

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

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

OCP as Competitive Cudgel

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

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

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

Cracking the Nut

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

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

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

Infrastructure Virtualization Versus Converged Infrastructure

While writing about software-defined networking (SDN) and what it makes possible, I have been thinking about how its essential premise, and the premise behind infrastructure virtualization, conflicts with visions of converged infrastructure promulgated by the leading systems vendors in the information-technology (IT) industry.

According to the Wikipedia definition, converged infrastructure encompasses servers, storage, networking gear, and software for IT infrastructure management, automation, and orchestration. Accordingly, converged infrastructure leverages pooled IT resources to facilitate automated resource provisioning in support of dynamic application workloads.

Hardware Pedigrees in Software World

Leading vendors, most with more hardware than software pedigrees, have sought to offer proprietary converged-infrastructure offerings that closely integrate the hardware elements with software-based management attributes. In this regard,  we can cite vendors such as Cisco (with a storage assist from EMC or NetApp), Hewlett-Packard, Dell, Hitachi Data Systems, Oracle (though networking remains on open question there),  and, perhaps to a lesser extent, IBM.

Now, let’s think about SDN and where it ultimately leads. Cisco would like us to believe that SDN, if it leads anywhere, will eventually take us to network programmability, with a heavy emphasis on the significance of a northbound API (or APIs).  Cisco says that the means — in this case, SDN — are not as important as the desired ends, networking programmability, and many of Cisco’s enterprise customers will doubtless agree.

SDN End Games

Another SDN outcome is network virtualization, which admittedly can also be achieved through other means. But an interesting aspect of SDN’s approach to network virtualization, with its decoupling of the network’s control and data planes, is that it results in the abstracting of software-based network intelligence from the underlying hardware-based network brawn. It’s a software paradigm taken to a logical extreme, with server-based software running at the network edge controlling an abstracted pool of no-frills networking hardware.

Indeed, this is one end game for SDN, first playing out in the data centers of the major cloud service providers that guide the affairs of the Open Networking Foundation (ONF), and then — at some indeterminate future point too difficult to forecast without a Ouija board and a bottle of scotch  — also at large enterprises worldwide.

Let’s elaborate further. SDN facilitates network virtualization, which in turn is harnessed and orchestrated by cloud-management software, which also manages virtualized compute and storage infrastructure. As we’ve seen already in the compute world of servers, it’s getting increasingly difficult for a vanity hardware vendor to earn a buck in a virtualized world. Many service providers have found that they can get boxes that satisfy their needs, at lower prices, directly from ODMs that often build servers for name-brand OEMs.  Storage is being virtualized, too.

Network’s Turn

And now it is the network’s turn.

In such a world, how much longer will it make sense for customers to achieve converged infrastructure from single-source vendors that equip their hardware with proprietary fripperies and hooks to facilitate lock-in? Again, we can see these trend playing out at large service providers. Some have begun buying their networking hardware off the rack from ODMs, saving not only on capital expenditures (certainly the case for servers), but also on operating expenses relating to the ongoing management of network infrastructure. It’s true that they’re trading one sort of complexity for another, pushing it up the stack and into software rather than an operational hardware, but it’s a trade-off they’re clearly willing to make, probably because they have the resources and skill sets to make it work (and pay).

Obviously that is not a recipe for everybody, certainly not for most enterprises today. But times are changing, and it isn’t inconceivable to foresee a day when the enterprise will be able to avail itself of third-party private-cloud software and management tools that will allow it to exploit a similar model of virtualized infrastructure.

Prescience Pays Off

In the big picture, as far as the established networking vendors are concerned, the ONF’s conception of SDN is about more than just OpenFlow, and even about more than network programmability. It’s about how SDN supports a model of network virtualization, in service to infrastructure virtualization, that significantly enfeebles hardware-based business models. Some of these hardware-oriented vendors will not successfully pivot to a model of virtualized infrastructure and software primacy.

On the other hand, some vendors have had the prescience to see this trend approaching on the horizon; they understand its inevitability, and they have positioned themselves better than others to survive, and perhaps even thrive, after the eventual market transition.

We’ll look at one of those vendors in a subsequent post.

SDN Focus Turns to Infrastructure

At this year’s SIGCOMM conference in Helsinki, Finland, a workshop called Hot Topics in Software-Defined Networking (HotSDN) will be held on August 13.  A number of papers will be presented as part of HotSDN’s technical program, but one has been written as a “call to arms for the SDN community.”

The paper is called: “Fabric: A Retrospective on Evolving SDN.” Its authors are Martin Casado, CTO of Nicira Networks; Teemu Koponen of the International Computer Science Institute (ICSI); Scott Shenker, a co-founder of Nicira Networks (along with Casado) and also a professor of computer science at University of California, Berkeley; and Amin Tootoonchian, a PhD candidate at the University of Toronto and a visiting researcher at ICSI.

SDN Fabrics

We’ll get to their definition of fabric soon enough, but let’s set the stage properly by explaining at the outset that the paper discusses SDN’s shortcomings and proposes “how they can be overcome by adopting the insight underlying MPLS,” which is seen as helping to facilitate an era of simple network hardware and flexible network control.

In the paper’s introductory section, the authors contend that “current networks are too expensive, too complicated to manage, too prone to vendor lock-in, and too hard to change. “ They write that the SDN community has done considerable research on network architecture, but not as much on network infrastructure, an omission that they then attempt to rectify.

Network infrastructure, the paper’s authors contend, has two components: the underlying hardware, and the software that controls the overall behavior of the network. Ideally, they write, hardware should be simple, vendor-neutral, and future-proof, while the control plane should be flexible.

Infrastructure Inadequacies

As far as the authors are concerned, today’s network infrastructure doesn’t satisfy any of those criteria, with “the inadequacies in these infrastructural aspects . . .  probably more problematic than the Internet’s architectural deficiencies.” The deficiencies cannot be overcome through today’s SDN alone, but a better SDN can be built by, as mentioned above, “leveraging the insights underlying MPLS.”

And that’s where network fabrics enter the picture. The authors define a network fabric as “a contiguous and coherently controlled portion of the network infrastructure, and do not limit its meaning to current commercial fabric offerings.” Later, they refer to a network fabric as “a collection of forwarding elements whose primary purpose is packet transport. Under this definition, a network fabric does not provide more complex network services such as filtering or isolation.”

Filtering, isolation, policy, and other network services will be handled in software at the network edge, while the fabric will serve primarily as a “fast and cheap” interconnect. The authors contend that we can’t reach that objective with today’s SDN and OpenFlow.

OpenFlow’s Failings

They write that OpenFlow’s inability to “distinguish between the Host-Network interface (how hosts inform the network of requirements) and the Packet-Switch interface (how a packet identifies itself to a switch) has resulted in three problems, the first of which is that OpenFlow, in its current form, does not “fulfill the promise of simplified hardware” because the protocol requires switch hardware to support lookups of hundreds of bits.

The second problem relates to flexibility. As host requirements evolve, the paper’s authors anticipate “increased generality in the Host-Network interface,” which will mean increasing the generality in . . . “matching allowed and the actions supported” on any every switch supported by OpenFlow. The authors are concerned that “needing functionality to be present on every switch will bias the decision towards a more limited feature set, reducing OpenFlow’s generality.”

The third problem, similar to the second, is that the current implementation of OpenFlow “couples host requirements to the network core behavior.” Consequently, if there is a change in external network protocols (such as a transition from IPv4 to IPv6), the change in packet matching would necessarily extend into the network core.

Toward a New Infrastructure

Accordingly, the authors propose a network fabric that borrows heavily from MPLS, with its labels and encapsulation, and that also benefits from proposed modifications to the SDN model and to OpenFlow itself. What we get is a model that includes a network fabric as “architectural building block” within SDN. A diagram illustrating this SDN model shows a source host connecting to an ingress edge switch, which then applies MPLS-like label-based forwarding within the “fabric elements.” On the other side of the fabric, an egress edge switch ensures that packets are delivered to the destination host. The ingress and egress edge switches answer to an “edge controller,” while a “fabric controller” controls the fabric elements.

The key properties associated with the SDN fabric are separation of forwarding and separation of control. Separation of forwarding is intended to simplify the fabric forwarding elements, but also to “allow for independent evolution of fabric and edge.” As for separation of control, I quote from the paper:

While there are multiple reasons to keep the fabric and the edge’s control planes separate, the one we would like to focus on is that they are solving two different problems. The fabric is responsible for packet transport across the network, while the edge is responsible for providing more semantically rich services such as network security, isolation, and mobility. Separating the control planes allows them each to evolve separately, focusing on the specifics of the problem. Indeed, a good fabric should be able to support any number of intelligent edges (even concurrently) and vice versa.

Two OpenFlows?

As the authors then write, “if the fabric interfaces are clearly defined and standardized, then fabrics offer vendor independence and . . . limiting the function of the fabric to forwarding enables simpler switch implementations.”

The paper goes on to address the fabric-service model, fabric path setup, addressing and forwarding in the fabric, and how the edge context is mapped to the fabric (the options are address translation and encapsulation, which is the authors’ favored mechanism.)

To conclude, the authors look at fabric implications, one of which involves proposed changes to OpenFlow. The authors prescribe an “edge” version of OpenFlow, more general than the current manifestation of the protocol, and a “core” version of OpenFlow that is similar to MPLS forwarding. The authors say the current OpenFlow is an “unhappy medium,” insufficiently general for the edge and not simple enough for the core. The authors say the generic “edge version of OpenFlow should aggressively adopt the assumption that it will be processed in software, and be designed with that freedom in mind.”

Refinements to the Model

In the final analysis, the authors believe their proposal to address infrastructure as well as architecture will result in an SDN model “where the edge processing is done in software and the core in simple (network) hardware,” the latter of which would deliver the joint benefits of reduced costs and “vendor neutrality. “

The paper essentially proposes a refinement to both OpenFlow and to the SDN architectural model. We might call it SDN 2.0, though that might seem a little glib and presumptuous (at least on my part). Regardless of what we call it, it is evident that certain elements in the vanguard of the SDN community continue to work hard to deliver a new type of cloud-era networking that delivers software-based services running over a brawny but relatively simple network infrastructure.

How will the broader SDN community and established vendors in network infrastructure respond? We won’t have to wait long to find out.

Cisco’s SDN Response: Mission Accomplished, but Long Battle Ahead

In concluding my last post, I said I would write a subsequent note on whether Cisco achieved its objectives in its rejoinder to software-defined networking (SDN) at the Cisco Live conference last week in San Diego.

As the largest player in network infrastructure, Cisco’s words carry considerable weight. When Cisco talks, its customers (and the industry ecosystem) listen. As such, we witnessed extensive coverage of the company’s Cisco Open Network Environment (Cisco ONE) proclamations last week.

Really, what Cisco announced with Cisco ONE was relatively modest and wholly unsurprising. What was surprising was the broad spectrum of reactions to what was effectively a positioning statement from the networking market’s leading vendor.

Mission Accomplished . . . For Now

And that positioning statement wasn’t so much about SDN, or about the switch-control protocol OpenFlow, but about something more specific to Cisco, whose installed base of customers, especially in the enterprise, is increasingly curious about SDN. Indeed, Cisco’s response to SDN should be seen, first and foremost, as a response to its customers. One could construe it as a cynical gesture to “freeze the market,” but that would not do full justice to the rationale. Instead, let’s just say that Cisco’s customers wanted to know how their vendor of choice would respond to SDN, and Cisco was more than willing to oblige.

In that regard, it was mission accomplished. Cisco gave its enterprise customers enough reason to put off a serious dalliance with SDN, at least for the foreseeable future (which isn’t that long). But that’s all it did. I didn’t see a vision from Cisco. What I saw was an effective counterpunch — but definitely not a knockout — against a long-term threat to its core market.

Cisco achieved its objective partly by offering its own take on network programmability, replete with a heavy emphasis on APIs and northbound interfaces; but it also did it partly by bashing OpenFlow, the open  protocol that effects physical separation of the network-element control and forwarding planes.

Conflating OpenFlow and SDN

In its criticism of OpenFlow, Cisco sought to conflate the protocol with the larger SDN architecture. As I and many others have noted repeatedly, OpenFlow is not SDN;  the two are not inseparable. It is possible to deliver an SDN architecture without OpenFlow. Even when OpenFlow is included, it’s a small part of the overall picture.  SDN is more than a mechanism by which a physically separate control plane directs packet forwarding on a switch.

If you listened to Cisco last week, however, you would have gotten the distinct impression that OpenFlow and SDN are indistinguishable, and that all that’s happening in SDN is a southbound conversation from a server-based software controller and OpenFlow-capable switches. That’s not true, but the Open Networking Foundation (ONF), the custodians of SDN and OpenFlow, has left an opening that Cisco is only too happy to exploit.

The fact is, the cloud service-provider principals steering the ONF see SDN playing a much bigger role than Cisco would have you believe. OpenFlow is a starting point. It is a means to, well, another means — because SDN is an enabler, too. What SDN enables is network virtualization and network programmability, but not how Cisco would like its customers to get there.

Cisco Knows SDN More Than OpenFlow

To illustrate my point, I refer you to the relatively crude ONF SDN architectural stack showcased in a white paper, Software-Defined Networking: The New Norm for Networks. If you consult the diagram in that document, you will see that OpenFlow is the connective tissue between the controller and the switch — what ONF’s Dan Pitt has described as an “open interface to packet forwarding” — but you will also see that there are abstraction layers that reside well above OpenFlow.

If you want an ever more detailed look at a “modern” SDN architecture, you can consult a presentation given by Cisco’s David Meyer earlier this year. That presentation features physical hardware at the base, with SDN components in the middle. These SDN components include the “forwarding interface abstraction” represented by OpenFlow, a network operation system (NOS) running on a controller (server), a “nypervisor” (network hypervisor), and a global management abstraction that interfaces with the control logic of higher-layer application (control) programs.

So, Cisco clearly knows that SDN comprises more than OpenFlow, but, in its statements last week at Cisco Live, the company preferred to use the protocol as a strawman in its arguments for Cisco-centric network programmability. You can’t blame Cisco, though. It has customers to serve — and to keep in the revenue- and profit-generating fold — and an enterprise-networking franchise to protect.

Mind the Gap

But why did the ONF leave this gap for Cisco to fill? It’s partly because the ONF isn’t overly concerned with the enterprise and partly because the ONF sees OpenFlow as an open, essential precondition for the higher, richer layers of the SDN architectural model.

Without the physical separation of the control plane from the forwarding plane, after all, some of the ONF’s service-provider constituency might not have been able to break free of vendor hegemony in their networks. What’s more, they wouldn’t be able to set the stage for low-priced, ODM-manufactured networking hardware built with merchant silicon.

As you can imagine, that is not the sort of change that Cisco can get behind, much less lead. Therefore, Cisco breaks out the brickbats and goes in hot pursuit of OpenFlow, which it then portrays as deficient for the purposes of far-reaching, north-and-south network programmability.

Exiting (Not Exciting) Plumbing

Make no mistake, though. The ONF has a vision, and it extends well beyond OpenFlow. At a conference in Garmisch, Germany, earlier this year, Dan Pitt, the ONF’s executive director, offered a presentation called “A Revolution in Networking and Standards,” and made the following comments:

“I think networking is going to become an integral part of computing in a way that makes it less important, because it’s less of a problem. It’s not the black sheep any longer. And the same tools you use to create an IT computing infrastructure or virtualization, performance, and policy will flow through to the network component of that as well, without special effort.

I think enterprises are going to be exiting technology – or exiting plumbing. They are not going to care about the plumbing, whether it’s their networks or the cloud networks that increasingly meet their needs, and the cloud services. They’re going to say, here’s the function or the feature I want for my business goal, and you make it happen. And somebody worries about the plumbing, but not as many people who worry about plumbing today. And if you’ve got this virtualized view, you don’t have to look at the plumbing. . . .

The operators are gradually becoming software companies and internet companies. They are bulking up on those skills. They want to be able to add those services and features themselves instead of relying on the vendors, and doing it quickly for their customers. It gives opportunities to operators that they didn’t have before of operating more diverse services and experimenting at low cost with new services.”

No Cartwheels

Again, this is not a vision that would have John Chambers doing cartwheels across the expansive Cisco campus.

While the ONF is making plans to address the northbound interfaces that are a major element in Cisco’s network programmability, it hasn’t done so yet. Even when it does, the ONF is unlikely to standardize higher-layer APIs, at least in the near term. Instead, those APIs will be associated with the controllers that get deployed in customer networks. In other words, the ONF will let the market decide.

On that tenet, Cisco can agree with the ONF. It, too, would like the market to decide, especially since its market presence — the investments customers have made in its routers and switches, and in its protocols and management tools — towers imperiously over the meager real estate being claimed in the nascent SDN market.

With all that Cisco network infrastructure deployed in customer networks, Cisco believes it’s in a commanding position to set the terms for how the network will deliver software intelligence to programmers of applications and management systems. Theoretically, that’s true, but the challenge for Cisco will be in successfully engaging a programming constituency that isn’t its core audience. Can Cisco do it? It will be a stretch.

Do They Get It?

All the while, the ONF and its service-provider backers will be advancing and promoting the SDN model and the network virtualization and programmability that accompany it. The question for the ONF is not whether its movers and shakers understand programmers — it’s pretty clear that Google, Facebook, Microsoft, and Yahoo are familiar with programmers — but whether the ONF understands and cares enough about the enterprise to make that market a priority in its technology roadmap.

If the ONF leaves the enterprise to the dictates of the Internet Engineering Task Force (IETF) and Institute of Electrical and Electronics Engineers (IEEE), Cisco is likely to maintain its enterprise dominance with an approach that provides some benefits of network programmability without the need for server-based controllers.

Meanwhile, as Tom Nolle, president of CIMI Corporation has pointed out, Cisco ONE also serves as a challenge to Cisco’s conventional networking competitors, which are devising their own answers to SDN.

But that is a different thread, and this one is too long already.

Understanding Cisco’s Relationship to SDN Market

Analysts and observers have variously applauded or denounced Cisco for its network-Cisco ONE programmability pronouncements last week.  Some pilloried the company for being tentative in its approach to SDN, contrasting the industry giant’s perceived reticence with its aggressive pursuit of previous emerging technology markets such as IP PBX, videoconferencing, and converged infrastructure (servers).

Conversely, others have lauded Cisco’s approach to SDN as far more aggressive than its lackluster reply to challenges in market segments such as application-delivery controllers (ADCs) and WAN optimization, where F5 and Riverbed, respectively, demonstrated how a tightly focused strategy and expertise above the network layer could pay off against Cisco.

Different This TIme

But I think they’ve missed a very important point about Cisco’s relationship to the emerging SDN market.  Analogies and comparisons should be handled with care. Close inspection reveals that SDN and the applications it enables represent a completely different proposition from the markets mentioned above.

Let’s break this down by examining Cisco’s aggressive pursuit of IP-based voice and video. It’s not a mystery as to why Cisco chose to charge headlong into those markets. They were opportunities for Cisco to pursue its classic market adjacencies in application-related extensions to its hegemony in routing and switching. Cisco also saw video as synergistic with its core network-infrastructure business because it generated bandwidth-intensive traffic that filled up existing pipes and required new, bigger ones.

Meanwhile, Cisco’s move into UCS servers was driven by strategic considerations. Cisco wanted the extra revenue servers provided, but it also wanted to preemptively seize the advantage over its former server partners (HP, Dell, IBM) before they decided to take the fight to Cisco. What’s more, all the aforementioned vendors confronted the challenge of continuing to grow their businesses and public-market stock prices in markets that were maturing and slowing.

Cisco’s reticence to charge into WAN optimization and ADCs also is explicable. Strategically, at the highest echelons within Cisco, the company viewed these markets as attractive, but not as essential extensions to its core business. The difficulty was not only that Cisco didn’t possess the DNA or the acumen to play in higher-layer network services — though that was definitely a problem — but also that Cisco did not perceive those markets as conferring sufficiently compelling rewards or strategic advantages to warrant the focus and resources necessary for market domination. Hence, we have F5 Networks and its ADC market leadership, though certainly F5’s razor-sharp focus and sustained execution factored heavily into the result.

To Be Continued

Now, let’s look at SDN. For Cisco, what sort of market does it represent? Is it an opportunity to extend its IP-based hegemony, like voice, video, and servers? No, not at all. Is it an adjunct market, such as ADCs and WAN optimization, that would be nice to own but isn’t seen as strategically critical or sufficiently large to move the networking giant’s stock-price needle? No, that’s not it, either.

So, what is SDN’s market relationship to Cisco?

Simply put, it is a potential existential threat, which makes it unlike IP PBXes, videoconferencing, compute hardware, ADCs, and WAN optimization. SDN is a different sort of beast, for reasons that have been covered here and elsewhere many times.  Therefore, it necessitates a different sort of response — carefully calculated, precisely measured, and thoroughly plotted. For Cisco, the ONF-sanctioned approach to SDN is not an opportunity that the networking giant can seize,  but an incipient threat to the lifeblood of its business that it must blunt and contain — and, whatever else, keep out of its enterprise redoubt.

Did Cisco achieve its objective? That’s for a subsequent post.

Dell’s Steady Progression in Converged Infrastructure

With its second annual Dell Storage Forum in Boston providing the backdrop, Dell made a converged-infrastructure announcement this week.  (The company briefed me under embargo late last week.)

The press release is available on the company’s website, but I’d like to draw attention to a few aspects of the announcement that I consider noteworthy.

First off, Dell now is positioned to offer its customers a full complement of converged infrastructure, spanning server, storage, and networking hardware, as well as management software. For customers seeking a single-vendor, one-throat-to-choke solution, this puts Dell  on parity with IBM and HP, while Cisco still must partner with EMC or with NetApp for its storage technology.

Bringing the Storage

Until this announcement, Dell was lacking the storage ingredients. Now, with what Dell is calling the Dell Converged Blade Data Center solution, the company is adding its EqualLogic iSCSI Blade Arrays to Dell PowerEdge blade servers and Dell Force10 MXL blade switching. Dell says this package gives customers an entire data center within a single blade enclosure, streamlining operations and management, and thereby saving money.

Dell’s other converged-infrastructure offering is the Dell vStart 1000. For this iteration of vStart, Dell is including, for the first time, its Compellent storage and Force10 networking gear in one integrated rack for private-cloud environments.

The vStart 1000 comes in two configurations: the vStart 1000m and the vStart 1000v. The packages are nearly identical — PowerEdge M620 servers, PowerEdge R620 management servers, Dell Compellent Series 40 storage, Dell Force10 S4810 ToR Networking and Dell Force10 S4810 ToR Networking, plus Brocade 5100 ToR Fibre-Channel Switches — but the vStart 1000m comes with Windows Server 2008 R2 Datacenter (with the Hyper-V hypervisor), whereas the vStart 1000v features trial editions of VMware vCenter and VMware vSphere (with the ESXi hypervisor).

An an aside, it’s worth mentioning that Dell’s inclusion of Brocade’s Fibre-Channel switches confirms that Dell is keeping that partnership alive to satisfy customers’ FC requirements.

Full Value from Acquisitions

In summary, then, is Dell delivering converged infrastructure with both its in-house storage options, demonstrating that it has fully integrated its major hardware acquisitions into the mix.   It’s covering as much converged ground as it can with this announcement.

Nonetheless, it’s fair to ask where Dell will find customers for its converged offerings. During my briefing with Dell, I was told that mid-market was the real sweet spot, though Dell also sees departmental opportunities in large enterprises.

The mid-market, though, is a smart choice, not only because the various technology pieces, individually and collectively, seem well suited to the purpose, but also because Dell, given its roots and lineage, is a natural player in that space. Dell has a strong mandate to contest the mid-market, where it can hold its own against any of its larger converged-infrastructure rivals.

Mid-Market Sweet Spot

What’s more, the mid-market — unlike cloud-service providers today and some large enterprise in the not-too-distant future — are unlikely to have the inclination, resources, and skills to pursue a DIY, software-driven, DevOps-oriented variant of converged infrastructure that might involve bare-bones hardware from Asian ODMs. At the end of the day, converged infrastructure is sold as packaged hardware, and paying customers will need to perceive and realize value from buying the boxes.

The mid-market would seem more than receptive to the value proposition that Dell is selling, which is that its converged infrastructure will reduce the complexity of IT management and deliver operational cost savings.

This finally leads us to a discussion of Dell’s take on converged infrastructure. As noted in an eChannelLine article, Dell’s notion of converged infrastructure encompasses operations management, services management, and applications management. As Dell continues down the acquisition trail, we should expect the company to place greater emphasis on software-based intelligence in those areas.

That, too, would be a smart move. The battle never ends, but Dell — despite its struggles in the PC market — is now more than punching its own weight in converged infrastructure.