For Huawei and ZTE, Suspicions Persist

About two weeks ago, the U.S. House Permanent Select Committee on Intelligence held a hearing on “the national-security threats posed by Chinese telecom companies doing business in the United States.” The Chinese telecom companies called to account were Huawei and ZTE, each of which is keen to expand its market reach into the United States.

It is difficult to know what to believe when it comes to the charges leveled against Huawei and ZTE. The accusations against the companies, which involve their alleged capacity to conduct electronic espionage for China and their relationships with China’s government, are serious and plausible but also largely unproven.

Frustrated Ambitions

One would hope these questions could be settled definitively and expeditiously, but this inquiry looks be a marathon rather than a sprint. Huawei and ZTE want to expand in the U.S. market, but their ambitions are thwarted by government concerns about national security.  As long as the concerns remain — and they show no signs of dissipating soon — the two Chinese technology companies face limited horizons in America.

Elsewhere, too, questions have been raised. Although Huawei recently announced a significant expansion in Britain, which received the endorsement of the government there, it was excluded from participating in Australia’s National Broadband Network (NBN). The company also is facing increased suspicion in India and in Canada, countries in which it already has made inroads.

Vehement Denials 

Huawei and ZTE say they’re facing discrimination and protectionism in the U.S.  Both seek to become bigger players globally in smartphones, and Huawei has its sights set on becoming a major force in enterprise networking and telepresence.

Obviously, Huawei and ZTE deny the allegations. Huawei has said it would be self-destructive for the company to function as an agent or proxy of Chinese-government espionage. Huawei SVP Charles Ding, as quoted in a post published on the Forbes website, had this to say:

 As a global company that earns a large part of its revenue from markets outside of China, we know that any improper behaviour would blemish our reputation, would have an adverse effect in the global market, and ultimately would strike a fatal blow to the company’s business operations. Our customers throughout the world trust Huawei. We will never do anything that undermines that trust. It would be immensely foolish for Huawei to risk involvement in national security or economic espionage.

Let me be clear – Huawei has not and will not jeopardise our global commercial success nor the integrity of our customers’ networks for any third party, government or otherwise. Ever.

A Telco Legacy 

Still, questions persist, perhaps because Western countries know, from their own experience, that telecommunications equipment and networks can be invaluable vectors for surveillance and intelligence-gathering activities. As Jim Armitage wrote in The Independent, telcos in Europe and the United States have been tapped repeatedly for skullduggery and eavesdropping.

In one instance, involving the tapping  of 100 mobile phones belonging to Greek politicians and senior civil servants in 2004 and 2005, a Vodafone executive was found dead of an apparent suicide. In another case, a former head of security at Telecom Italia fell off a Naples motorway bridge to his death in 2006 after discovering the illegal wiretapping of 5,000 Italian journalists, politicians, magistrates, and — yes — soccer players.

No question, there’s a long history of telco networks and the gear that runs them being exploited for “spookery” (my neologism of the day) gone wild. That historical context might explain at least some of the acute and ongoing suspicion directed at Chinese telco-gear vendors by U.S. authorities and politicians.

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.

A Special Thank You

I wish to offer a special thank  you to all those who extended condolences last week.  I was and remain truly appreciative of your kind thoughts and warm sentiments.

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.

Back Soon

I’m still around. I had plans this week to write about several recent industry announcements and developments. I still intend to get around to writing those posts. 

Unfortunately, I first must deal with a death in my immediately family. I’ll be back soon.