According to a SeekingAlpha.com transcript of the earnings call, CTO David Stevens said sales of the VDX switching line are accelerating and expanding. In the first year the technology was on the market, Brocade saw mostly pilot projects, but “now we’re seeing a fair number of those accounts scale out into broad production use of the technology. In fact, some of the customers [are] hitting the limits of” the original VDX architecture.

Brocade announced the VDX 8770 chassis switch this year to increase the scale of the VCS fabric.  The company now has 800 VDX customers.

“Over time, we’re going to see more scale-out production use of the technology, both… within [the] installed base where we sold the product to date but also as we gain new name accounts going forward,” Stevens said.

In its final quarter for fiscal 2012, Brocade reported $578 million in revenue, a 5% bump year-over-year.  It was a record quarter for the company, driven mostly by a robust sales in storage area network (SAN) sales. Its IP networking business declined by 3%, pushed down by routing. Switching actually grew by 5%.

During the earnings call one financial analyst, Mark Sue of RBC Capital Markets, pushed Brocade’s executives on the idea that it should focus its Ethernet business in the data center, saying “the business might benefit from some focus… Is there some thought of driving that deeper into the data center and perhaps less in the campus and less in the enterprise just because the market doesn’t seem to be growing that margin? It is very crowded.”

Jason Nolet, VP of Data Center Networking Group, said Brocade has invested substantially in its VCS fabric and its VDX switches. Investments in campus networking aren’t taking away from that data center focus, he added. Stevens, the outgoing CTO, added that investments in campus networking are relatively small compared to the investments the company has made in developing VCS and service provider networking.

Brocade started refreshing its campus networking products a year ago with the ICX 6610 series. Next year it will release HyperEdge, a campus LAN management technology that establishes a single management IP address where admins can make changes to an entire network through a single CLI session.

Stevens added that customers are starting to engage with Brocade about the need for software defined networking technology, especially for implementing network virtualization.

“I think it’s starting to gain a lot of interest,” he said. “When you think about adding another layer to the network with network virtualization, you’re going to add logical networks through tunnel technology. You’re actually adding to the overall administrative burden of that environment, because the physical infrastructure doesn’t go away. It still needs to be scaled, maintained and managed to upgrade, et cetera.”

Customers are telling Brocade that the VCS fabric’s ability to “simplify and reduce the operational overhead of that underlying transport as a result of the very high level of automation and efficiency that we’ve built into the fabric” allows them to focus more on how they’re going to deploy and run network virtualization, Stevens said.

“It also prevents them from just doubling up their operational overhead as a result of having adding that additional virtualization layer to the network environment,” he added.

But what about the technology strategy that is coalescing around Insieme and the other moves Cisco is making with software-defined networks? Shouldn’t the bigger concern be that Cisco might be making a strategic blunder?

Last week Cisco circulated an internal memo that confirmed for employees its $100-milllion investment in Insieme, the spin-in that will form part of Cisco’s “build, buy, partner” strategy for software-defined networking (SDN). The Cisco memo, published by Om Malik, claims that the networking industry hasn’t yet settled on a definition for SDN, let alone a value proposition:

Because SDN is still in its embryonic stage, a consensus has yet to be reached on its exact definition. Some equate SDN with OpenFlow or decoupling of control and data planes. Cisco’s view transcends this definition.

As Brad Casemore points out, here is Cisco’s opening salvo. It’s going to resist, or at least play down the value of, one of the core attributes of software-defined networking: the decoupling of the control and data planes. There is a little bit of cognitive dissonance with this statement. This decoupling of the control and data planes is an essential foundation of SDN. It enables centralized, flow-based networking. It enables programmability. It enables organizations to deploy third-party applications on a network through an SDN controller. But Cisco claims to transcend this idea. This vague dismissal should be troubling to SDN proponents.

The memo goes on to quote Cisco CTO Padmasree Warrior to support this notion:

“If you ask five customers what SDN means to them, you may get five different answers. Customer motivations and expectations are different based on their business problem or deployment scenario,” Warrior says.

It’s true that some people new to the subject initially perceived OpenFlow as an architecture, rather than just a protocol that enables SDN. Once they get educated on the subject, few networking pros express much confusion on the matter. However, is Cisco’s view really transcending the current SDN definition. This memo muddies the waters a bit by claiming that Cisco’s Nexus 1000v virtual switch is an example of SDN?

While SDN concepts like network virtualization may sound new, Cisco has played a leadership role in this market for many years leveraging its build, buy, partner strategy. For example, Cisco’s Nexus 1000V series switches—which provide sophisticated NX-OS networking capabilities in virtualized environment down to the virtual machine level—are built upon a controller/agent architecture, a fundamental building block of SDN solutions. With more than 5,000 customers today, Cisco has been shipping this technology for a long time.

Sure, the Nexus 1000v introduces a version of SDN to the extreme edge of a virtualized data center, but it doesn’t come close to achieving the network agility and programmability promised by software-defined networks enabled, or not enabled, by OpenFlow. What about the rest of the data center LAN, filled with physical switches that are so constrained that both the IETF and the IEEE are re-engineering Ethernet in order to eliminate a legacy protocol like spanning tree?

Proponents say that SDN has the potential to eliminate spanning tree by defining flow routes centrally in a  server-based controller, thus eliminating the risk of loops. Why upgrade to Shortest Path Bridging (SPB) or Transparent Interconnections of Lots of Links (TRILL), when an SDN network that can do it? If you want to use TRILL or SPB in your data center network today, you need to upgrade to the newest generation of your vendor’s switches, and you won’t be able to reverse course midway through. These vendors won’t play together. You can’t mix Brocade’s iteration of TRILL with Cisco’s. You can’t mix Avaya’s iteration of SPB with Cisco or Brocade. You probably wouldn’t want to mix vendors in your data center, but you also want investment protection with these new data center fabrics, don’t you? Five years from now when you need to refresh the server access layer, you’re locked into whatever vendor you’ve chosen.

You can ditch spanning tree in an OpenFlow-based SDN network using any combination of switches that support OpenFlow. Heck, Nicira Networks claims its product can get you there without even using OpenFlow switches. Just leave your legacy network in place. You know who is using OpenFlow? Google. You know who is using Nicira? eBay. Fidelity. Rackspace. NTT. Concerns about scalability with SDN may be justified, but some heavyweight companies have put it into production.

But never mind that for now. The Cisco memo expounds on the virtues of open, programmable networks (something that Arista Networks has offered for a couple years now). Toward the end, the memo lifts the veil off of Cisco’s SDN approach.

“Our strategy is to continue to offer choices to our customers so that they are not forced to go down a single path,” Warrior says. “We have a multipronged approach that goes beyond current perceptions of SDN, leveraging business-based use cases as building blocks so that we achieve architectural consistency and bring to bear the richness of all our capabilities.”

Warrior adds that Cisco already builds a lot of intelligence into its network silicon and software. Making them open and programmable will further unlock the value, while enabling further application awareness.

I will give Cisco credit here. the industry needs more “business-based use cases” for SDN. Midsized enterprises and even many large enterprises do not need SDN today. The networking pros at these smaller companies who ask me about SDN are interested in the technology, but mostly they just want to stay current with technology. They don’t need it. Today the emerging SDN market is focused on serving the needs of larger enterprises and web-scale companies. Broader business cases for the technology are years away. Many SDN start-ups are focusing on cloud providers and web giants rather than enterprises.

However, the mention of network silicon above (translation: ASICs) worries me. Here we have Cisco saying that it will make its ASICs and its software (IOS, NX-OS) open and programmable. Just how open and programmable will Cisco’s technology be? Look at this job posting for a software engineer at Cisco (It may not last long. It’s been scrubbed of certain details since I first reported its existence a couple weeks ago. This and another job posting (which disappeared from Cisco’s website a few days ago) made many references to a ConnectedApps team that is developing APIs for a software development kit (SDK) that will open up Cisco’s technology to third-party developers as part of a SDN initiative.

Just how open and programmable will an initiative based on APIs be? This doesn’t sound like an API for OpenFlow. It sounds like something else, given Cisco’s downplay of OpenFlow. APIs are a way to allow third party developers to hook their software to another vendor’s proprietary software. There’s nothing particularly open about it. SDN is about more than hooking third-party software to the edge of Cisco’s black box, whether that black box is in the form of software or an ASIC. SDN is what it is: Networks defined by software rather than hardware. How do you do that? By opening up the black box of networks and letting  engineers build their networks in new ways. There is a control plane and there is a data plane. SDN decouples them and opens up the network to a whole new world of possibilities. It’s as simple as that.

In a few years, more IT organizations will want an open, software-defined network. Cisco needs to find a way to be relevant in such a world. APIs won’t cut it.

Which narrative would you like to believe?

1. The networking industry is more competitive than ever with Cisco faltering and companies like Juniper and HP gaining market share.
2. Cisco owns the market and everyone else is fighting for scraps, hoping to make a graceful exit.

Can they both be true? In recent years we’ve seen companies build up their networking portfolios in an effort to compete head-on with Cisco, only to make a quick exit after those efforts made them into an attractive target for acquisition.

As Henny Youngman might have said: Take my company. Please!

Remember when 3Com established H3C as a joint venture with Huawei, built up an impressive product portfolio, and then bought out Huawei’s share? Just two years ago 3Com was promising to blitz North America with the H3C brand and challenge Cisco.  They were serious about the enterprise again, after abandoning their customers back in 2000. Six months later 3Com sold out to HP.  Goodbye 3Com.

Remember Foundry Networks? Brocade bought the networking vendor three years ago. Brocade wanted to transform itself from a Fibre Channel networking vendor to a data center networking vendor and Foundry had the engineering talent and a loyal customer list to draw upon.  Brocade has been aggressive since that acquisition, introducing its impressive new line of VDX data center switches.  But acquisition rumors have swirled around the company for more than a year. And now Bloomberg is reporting that Dell had considered buying Brocade before passing over it in favor of Force10 Networks this week. Bloomberg added:

“Brocade has been looking for potential buyers with the assistance of Frank Quattrone’s Qatalyst Partners for the past two years…”

Two years… Take my company. Please!

And now we have Alcatel-Lucent (ALU), a company that has struggled in countless ways since the 2006 merger of Alcatel and Lucent. Every year or so, ALU announces that it’s going to reinvigorate its enterprise business.  Every year, the effort falls flat.  ALU executives emphasized the company’s latest enterprise business unit reinvigoration drive back in April when it announced a new data center network architecture that was, frankly, impressive. Yet, at the same time that they were telling me that ALU wanted to renew its enterprise focus, the Wall Street Journal was reporting that ALU was looking to sell the division.  This week, ALU finally admitted that it is indeed weighing a sale.

Does anyone want to be in this business?

How are you, as a network engineer, supposed to navigate this environment? These companies work hard to earn your business. They develop good products, they invest heavily in sales and marketing, they prove themselves with technical support. They help you build your networks with their products, and then they sell out to the highest bidder leaving you with the uncertainty of dealing with a new vendor. Nortel customers found themselves transformed into Avaya customers. Foundry into Brocade. 3Com into HP. Force10 into Dell.

Most engineers play it safe. They stick with Cisco, which owns the market and isn’t going anywhere. HP Networking appears to be the safest alternative for longevity in the networking industry that we’ve seen in a long time. But things can change. CEOs turn over. Shareholders get restless.

Maybe things would be different if the global economy weren’t such a mess. But that’s the world we’re living in.  The Great Recession is still in full swing, but the world still needs networks. So here you are. There are a dozen vendors out there asking you to choose them over Cisco. A lot of them make great products. Some of them make Cisco nervous.  But some of them are eager to make an exit, and that’s a a risk you need to consider.

When a company exits the market, it usually argues, rightly or wrongly, that its customers will be better off with the new owner of the business. Force10 customers will benefit from the Dell deal, they say. Foundry customers have benefited from the Brocade deal, they insist. Avaya has done right by Nortel customers, they promise. All that could be true. But it’s not a guaranteed happy ending when your preferred network vendor sells out. If you were doing business with 3Com 12 years ago, you know how it feels when a company dumps you.

A vWife is actually the bored (yet very supportive) spouse of a VMworld or EMCworld conference attendee.

Using the website Spousetivities, vWives can sign up to join their vSisters at the spa while their husbands are “better focusing” on the conferences. Spousetivities bills itself as “the fun side of tech conferences,” which at first lead me to believe that at last, some gossip blogger would expose all of the extramarital activities that take place at tech conferences. Instead, Crystal Lowe, the wife of VMware genius Scott Lowe, uses the site to promote her side events with related prizes and discounts for tech spouses looking for a good time (but not that kind of good time).

I applaud Lowe for taking the initiative to start what appears to be a viable small business, but I pose this question to bored tech conference wives (or husbands) everywhere: Wouldn’t you rather save a village than tag along to a conference at which you’re not required to attend?

Before you get offended, it’s not like I’m suggesting you “stay home and get a life,” which is what one of our TechTarget Networking Group editors said (and frankly what I have thought when passing you wives laying by the pool while I traipse off to another interview). Instead I ask, why not raise money for virtualized data centers in, say, Haiti, where an entire nation’s school system can be made functional with two physical servers hosting a couple dozen virtual machines?

Far be it from we, the SearchNetworking editors, to demand that vWives or anyone else not have a good time. By all means, party down vSisters. I just wonder: could you be doing more?

The day after I wrote and filed this story, I had breakfast with Shashi Kiran, Cisco’s director of market management for data center and virtualization. I mentioned the fact that so few people at the session were actively pursuing FCoE in their data centers. Kiran said he wasn’t surprised. The network engineers at Interop are simply building and managing resilient networks. They aren’t necessarily deciding whether FCoE will run over them. He said that storage managers are the ones who are truly interested in FCoE. If someone were to ask for a similar show of hands during a session at EMC World, which took place simultaneously with Interop, you would see a lot more hands raised, Kiran said. It’s a fair point, so I thought I’d share it here.

Of the 100 attendees the analysts surveyed at the show 27% said they are already converging with NAS and iSCSI, 23% are planning to use NAS and iSCSI and 32% plan to  use FCoE in the next three years. No one reported using FCoE today.

In the conversations I’ve had with data center and networking pros, it sounds like the convergence path a company takes will mostly depend on the infrastructure they already have in place. Fibre Channel shops will want to use FCoE in order to get more out of their storage area network investments. iSCSI shops will see no reason to invest in FCoE. They’ll just upgrade to lossless 10 Gigabit Ethernet and converge iSCSI and production traffic onto the same wire.

This new architecture allows an access point to perform some of the high-level security, policy and RF management roles that have traditionally been centralized in a controller.

At first glance it appeared that Motorola was going the way of start-up Aerohive, which has had a controllerless approach to WLAN from its inception. However, Motorola isn’t dumping the controller appliance altogether. It still has a role, but Motorola admits that the role is evolving. In fact, from what Motorola says, it sounds like everything about the WLAN controller is evolving.

Manju Mahishi, Motorola’s director of product management, told me that WiNG 5 is meant to give enterprises flexibility in deployment and to avoid bottlenecks associated with backhauling high throughput 802.11n data through centralized controllers. But he said that controllers will not be disappearing from Motorola’s WLAN architecture.

“We believe very strongly that in the vast majority of cases, depending on the number of access points in a local site, you can get away without having controllers. Up to 24 access points can be deployed without any controller,” Mahishi said. “But there are scenarios where we still see certain enterprises customers will still want to pull data centrally. They want to do all data processing through a controller, whether on specific VLANs or on guest access. Even though we see the benefits of distributed intelligence and having the access points doing all the work, there are still scenarios where [enterprises] will want to pull certain data if not all data through controllers, whether they are doing packet inspection or applying some security policies.”

He said there are some scenarios where the access points will simply not have the processing power to match Motorola’s high-end controllers. For instance, a highly subnetted network will require a controller. If a company wants to extend certain VLAN from a central campus out to branch offices, they will also use controllers to pull data back through a WAN.

Beyond the role of the controller, Mahishi said the format of the controller is also set for an evolution. He said Motorola’s OEM partnerships with Brocade and Extreme Networks are pushing the concept of a controller in a new direction. He said the ability to virtualize a controller and run it on a third party switching platform from one of these OEM partners could offer new ways of scaling a wireless LAN while simultaneously integrating it into the wired infrastructure.

“We can easily virtualize [controller] functionality,” Mahishi said. “When we were demonstrating WiNG 5, we were running it on a laptop. Clearly the intent is to be able to take this capability and run it on a cloud-based controller or any server-based appliance that can scale. The WiNG 5 architecture helps us get there.”

Networking pros will doubtless follow Motorola’s evolution of the controller-access point architecture very closely. Controllers from most WLAN vendors are extremely expensive and vendors like Aerohive and Meraki have made hay with customers by offering WLAN infrastructure that is free of a costly physical appliance. Aerohive’s access points collaborate as a virtual controller while Meraki offers cloud-based, subscription controller functionality, which transfers the controller function from a big-ticket capital expense to a low-cost, but ongoing, operational expense.

VMware, Cisco and EMC formed the VCE (Virtual Computing Environment) coalition late last year, which introduced the vbBlock Infrastructure Package, a modular data center package that’s supposed to power cloud computing. It consists of fully integrated and validated bundles of software, servers, storage and network gear.  I guess Eschenbach thinks we, the media, are making too much out of the VCE coalition. But how can you avoid hyping a strategic relationship between the world’s biggest virtualization vendor, the world’s biggest storage vendor and the world’s biggest networking vendor?

And besides, VMware has more than a strategic relationship with these two companies. EMC owns 80% of VMware. In 2007, Cisco bought its own stake in the company. Yes, Cisco owns just 1.5% of VMware, but that’s probably about 100% more of an ownership stake than any VMware customer currently holds.

VMware has done a good job of staying vendor agnostic, which is important since enterprises want to be able to run a hypervisor on whatever hardware they have in their server racks. But tight relationships with partners (and part owners) will continue to be a fact of life. VMware faces some serious competition in the future from Citrix Xen and Microsoft’s Hyper V. At Interop last month, consultant Jim Metzler, of Ashton Metzler & Associates, surveyed attendees by show of hands during a panel session on virtualized application delivery appliances. First he asked attendees whether they were currently VMware shops. Nearly all of them raised their hands. Then he asked them if they expected VMware to be the only hypervisor vendor in their data center two or three years from now. No one raised a hand.

A future is coming where VMware won’t be the de facto hypervisor in data centers. How will VMware hold onto market share when Microsoft is giving away Hyper V? Advanced and innovative features and functionality is one answer. Another answer is continued strategic partnerships with key vendors, like EMC and Cisco.

This morning Netcordia, a highly rated network configuration and change management (NCCM) startup with about 330 customers, was acquired by Infoblox, a leading DDI (DHCP, DNS and IPAM) vendor.

Steve Nye, Infoblox’s executive VP of product strategy, said he sees the NCCM and DDI markets coming together as enterprises gravitate toward network infrastructure management automation. He said both companies have been trying to solve the same problem: Manual changes to the network are the leading cause of network failures. “We approach this from the IP address management point of view and Netcordia approaches it from a device configuration point of view.”

As a result, there has been plenty of M&A activity and consolidation in the NCCM space recently. In addition to the Netcordia-Infoblox deal,  IBM acquired NCCM vendor Intelliden couple of months ago. And last week EMC announced a deeper integration of its NCCM technology, Ionix Network Configuration Manager (formerly known as Voyence, a company EMC acquired in 2007) with its Ionix for IT Operations Intelligence. This integration essentially enables the product to alert and accelerate troubleshooting when network configuration changes affect network availability and performance.

Wall Street has been displeased with Brocade’s Foundry results so far. As Munjal Shah, analyst with Jefferies and Stifel Nicolaus told the Wall Street Journal:

Brocade is facing challenges in integrating the Ethernet [business] as the sales model is different and Ethernet [original equipment manufacturers sales] are slow to materialize. Brocade has solid position in data center and relative valuation is low, but we believe it will take some time to resolve the execution issues.

Brocade has responded by appointing John McHugh as its new chief marketing officer. McHugh is a veteran of HP, where he is credited with starting up the ProCurve division. More recently McHugh was the head of Nortel’s enterprise solutions business. No surprise that he’s jumping ship after the Avaya acquisition. Burnishing the Foundry business appears to be a nice challenge for him.

Marks says Brocade also got away from what made Foundry a modest success in a crowded networking market: good support from sales engineers. Brocade tried to monetize those resources by turning what used to be free support into professional services. This alienated existing customers, apparently. Now Marks says he’s hearing from internal sources that Brocade is going back to the old Foundry approach, which should help it win over some new customers and perhaps retain some existing ones.