Category Archives: Enterprise Networking

Cisco Puts ACE in the Hole (or Maybe Not)

Although Cisco reportedly confirmed that it will discontinue further development of its Application Control Engine (ACE), a Cisco representative now says that it isn’t the case, and that ACE will be developed further.

Regardless of what Cisco eventually does with ACE, we have not seen the last of the company in the application-delivery controller (ADC) market. In fact, the latest indications, as published in articles at SearchNetworking and The Register, suggest that Cisco, like Arnold Schwarzenegger in The Terminator, will be back.

The salient question is whether Cisco’s next foray into the ADC market, regardless of the form it takes, will produce results any different from its previous efforts, which were catalogued by yours truly about two years ago. Indeed, Cisco has been beaten consistently and repeatedly by F5 Networks in load balancing. Cisco’s losing streak goes back more than a decade, and it is likely to continue if the company stumbles back into the market halfheartedly.

While there is no question that F5 has gotten the better of Cisco continually in load balancing, a more interesting question relates to why Cisco has failed. One line of reasoning suggests that Cisco neither understands nor appreciates Layer 4-7 network services, including load balancing and WAN optimization. Cisco, this argument asserts, is a switching and routing company, proficient at layers 2 and 3, but woefully out of its comfort zone higher up the stack.

Bigger Picture

There’s some legitimacy to that argument, but it doesn’t provide a complete picture. More often than not, Cisco’s load-balancing products and technologies were predicated on the fruits of acquisitions rather than on organic innovation. That is true going all the way back to the long-dead LocalDirector, which was based on technology Cisco obtained through the acquisition of Network Translation Inc. in 1996. Subsequent to that, Cisco acquired former F5 competitor ArrowPoint Communications for $5.7 billion in 2000.  The personnel in these load-balancing companies clearly understood network services, even if the old-guard switching and routing stalwarts at Cisco did not.

So, we’re left with two possibilities. Cisco made bad acquisition choices, effectively acquiring the wrong load-balancing companies, or Cisco failed to execute properly in taking the products and technologies of the acquired companies to market. I’m leaning toward the latter scenario.

Cisco’s primary problem in areas such as load balancing and WAN optimization, as it has been expressed to me by former Cisco executives, is that the company strategically understands that it needs to play in these markets, but that it invariably fails to make the commitment necessary to success. Why is that?

A Matter of Focus and Priority

It comes down to market sizes and business priorities. Switching and routing always ruled the roost, and the resources, at Cisco. That’s still true today, perhaps even to a greater extent now that the company is coming under renewed attack in its core markets after failing to break new ground in many of what CEO John Chambers called the company’s market adjacencies. (Flip, anyone?)

Fundamentally, nothing seems to have changed. Cisco might take another run at ADCs, but there’s no reason to suppose that it would end differently this time unless Cisco makes a sustained and uncompromising commitment to the market and the technologies. Nothing less will do.

Cisco can be sure that is ADC competitors, as in the past, will not give it any breaks.

Questioning SDN Cynicism

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

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

Asking Why

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

It’s not an academic or an idle question.

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

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

Agents Provocateurs: Back in Action 

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

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

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

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

Northbound API: The Standardization Debate

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

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

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

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

Too Early?

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

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

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

Avaya Executive Departures, Intrigue Continue

Like many other vendors, Avaya showed off its latest virtualized wares at VMworld in San Francisco this week. While putting its best face forward at VMware’s annual conference and exhibition, Avaya also experienced further behind-the-scenes executive intrigue.

Sources report that Carelyn Monroe, VP of Global Partner Support Services, resigned from the company last Friday. Monroe is said to have reported to Mike Runda, SVP and president of Avaya Client Services. She joined Avaya in 2009, coming over from Nortel.

Meanwhile, across the pond, Avaya has suffered another defection. James Stevenson, described as a “business-services expert” in a story published online by CRN ChannelWeb UK, has left Avaya to become director of operations for reseller Proximity Communications.

Prior to the departures of Monroe and Stevenson, CFO Anthony Massetti bolted for the exit door immediately after Avaya’s latest inauspicious quarterly results were filed with the Securities and Exchange Commission (SEC). Massetti was replaced by Dave Vellequette, who has a long history of of working alongside Avaya CEO Kevin Kennedy.

In some quarters, Kennedy’s reunion with Vellequette is being construed as a circle-the-wagons tactic in which the besieged CEO attempts to surround himself with steadfast loyalists. It probably won’t be long before we see a “Hitler parody” on YouTube about Avaya’s plight (like this one on interoperability problems with unified communications).

Between What Is and What Will Be

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

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

Choppy Transition

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

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

No Wishful Thinking

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

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

Fighting Inevitability

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

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

Chinese Merchant-Silicon Vendor Joins ONF, Enters SDN Picture

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

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

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

Acquisition Rumor

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

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

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

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

Avaya Questions Mount

Those of you following the tortuous (some might call it torturous) saga of Avaya Inc. might wish to visit the investor-relations section of Avaya’s website or peruse Avaya’s latest Form-10Q filing on the SEC website.

Yes, Avaya’s numbers for its third fiscal quarter of 2012, which ended on June 30, are available for review. I have given the results a cursory look, and I’ve concluded that the story hasn’t changed appreciably since I last wrote about Avaya’s travails. There’s still no prospect of significant revenue growth, quarterly losses continue to accrue, channel sales are edging lower across the company’s product portfolio, and the long-term debt overhang remains formidable.

Goodwill Impairment? 

And there’s something else, which I neglected to mention previously: a persistently high amount of goodwill on the asset side of the ledger, at least some of which might have to be written down before long. The company’s goodwill assumptions seem willfully optimistic, and even Avaya concedes that “it may be necessary to record impairment charges in the future” if “market conditions continue to deteriorate, or if the company is unable to execute on its cost-reduction efforts.” While I believe the company will persist with its cost-reduction efforts, I don’t see a meaningful near-term turnaround in macroeconomic conditions or in the growth profile of the company’s product portfolio. Ergo, impairment charges seem inevitable.

In this regard, what you need to know is that Avaya is carrying goodwill of about $4.2 billion on its books as of June 30, up from nearly $4.1 billion as of September 30, 2011. The company’s total assets are about $8.24 billion, which means goodwill accounts for more than half that total.

For those desirous of a quick summary of revenue and net loss for the year, I can report that total revenue, including sales of products and services, amounted to $1.25 billion in the quarter, down from $1.37 billion in the corresponding quarter last year, a year-on-year decrease of $122 million or about 9 percent. Product sales were down across the board, except in networking, where sales edged up modestly to $74 million in the quarter this year from $71 million last year. Service revenue also was down. For the nine-month period ended on June 30, revenues also were down compared to the same period the previous year, dropping from $4.13 billion last year to about $3.9 billion this year.

Mulling the Options

Avaya’s net loss in the quarter was $166 million, up from $152 million last year.

The critical challenge for Avaya will be growth. The books show that the company is maintaining level spending on research and development, but one wonders whether its acquisition strategy or its R&D efforts will be sufficient to identify a new source of meaningful revenue growth, especially as it finds itself under mounting pressure to contain costs and expunge ongoing losses. Meanwhile, a foreboding long-term debt looms, kicked down the road but still a notable concern.

With the road to IPO effectively blocked — I really can’t see a way for Avaya to get back on that track now — Avaya’s private-equity sponsors, Silver Lake Partners and TPG Capital, must consider their options. Is there a potential strategic acquirer out there? Can the company be sold in whole, or will it have to be sold in parts? Or will the sponsors just hang on, hoping continued cost cutting and a strategic overhaul, perhaps including a change in executive leadership, might get the company back on course?