Hey Brad! I wasn't going to deign to comment on one vendors slanted perspective, but since you picked it up I'll give it a whirl. :)

A few comments-

On quality and 4.0 versioning-- We built NX-OS on top of SAN-OS as we've stated several times, I am sure that in researching the fine print the Nortel product manager found that SAN-OS is on major version 3.x It started with 1.x coincidentally and in the past 6 years has moved from 1.x to 3.x. We felt that since the entire core SW architecture was based on SAN-OS 3.x that adding modular and multi-threaded L2 and L3 code would probably warrant the next number iteration. And since the SAN SW components are consistent with 3.x didn't want to run into version numbering overlap. I hope this is rather intuitive.

On capacity-
Each payload slot is 230Gb in and 230Gb Out. I am pretty certain every other company would call that 460Gb, but I've always personally stuck with the real number for per-slot bandwidth. Each supervisor slot, coincidentally has 115Gb too, just FYI. The 18-slot chassis, coming in a couple of quarters is also 230Gb/slot. But more importantly than that the system architecture has already been tested to far more than 230Gb/slot and we know this system has significant headroom. Most other vendors churn their infrastructure 4-5x faster than we do, or offer little to no innovation to the networking space. We just wanted to build a system that could last and do it well.

On the energy efficiency claims- please check the math, I mean seriously... Also be sure to look at actual draw versus provisioned power. This is important, and there is a good lesson here for folks, because you need to provision more power to a device so you can handle PDU/Grid and Power Supply failures. Although the actual draw and heat generated will be markedly less. Someone also show me the math, I only got up to algebra mind ya, that gets a 300% power savings... hmmm... if I took 10w and multiplied it by the savings of 300% I would get.... darn this is hard.

4-5 seconds to recover from network failures?
Not sure where this number came from. An OSPF failure on the box is detected and corrected in less than a second in many cases not dropping a 'Hello' packet. A administrator initiated system shutdown will PRECONVERGE the network rather than forcing RECONVERGENCE (Another Cisco innovation). The Supervisor can fail and may take a couple of seconds to get everything live on the second supervisor but since the Supervisor has no uplinks, no forwarding engine, and no switch fabric there is zero-packet loss when this occurs.

This poses an interesting question- if a supervisor fails and no packets are lost do end users care?

We are taking a different approach to Multi-Chassis EtherChannel with the Nexus family that supports even more x-sectional bandwidth than VSS does.

On services modules I thought we were quite clear- its hard to build a fast enough fully capable firewall in a power budget of 600-800w to utilize enough of the backplane capacity to make it worth the physical integration and common equipment cost-points. So we continue our investment in the Catalyst 6500. Also, I appreciate the validation of our services module strategy from companies that don't have one... thanks!

The Nexus 7000 will support FibreChannel over Ethernet and has the architectural capability to support FC as well although we have not made a decision to do that yet, we instead wanted to preserve our investment in the MDS 9500 SAN Directors, especially given the Intelligent Fabric Applications running there. Amazing this comment would come from Nortel- I searched all over for their SAN director...

Certainly companies that have consistently failed to innovate and deliver in the networking segment, that have married their own R&D capabilities so tightly to the merchant silicon vendors that they have no capability for competitive differentiation and have milked one business after another to prop-up flagging businesses or to build me-too offers have a right to be heard. I would offer that rather than trying to use our creation of a new category of data center infrastructure as an opportunity to try to deposition the Catalyst 6500s position as the preeminent switching platform, especially in the campus, data center access, data center services, metro, and branch please focus inwards- meet with your customers and listen to THEIR problems, and build something innovative. Ship it. Deliver. Then draw a comparison.

dg

btw- I just wanted to invite everyone who is interested in learning more about this, having these questions answered by the key engineers who helped deliver the platform, including folks like Dino Farinacci (lead SW architect for NX-OS and Cisco Fellow) and Venu Venugopal (who led the L3 SW engineering team and also was one of they key SW leaders at Procket). Please come by NANOG's Beer and Gear Monday night 5:30 - 7:45pm at the San Jose Fairmont.

We will have a Nexus 7000 Data Center Switching system there, the key engineering team, some good beer, and great t-shirts and would be happy to answer any questions anyone would have. Fact-based, fun, and informative...

While not an expert in 'Green' math, I would have thought there was more to it than Watts per Port. If I had a 100mb port, 1Gb port and a 1Tb port, do I calculate it on Watts per port even though each port is doing successively more work?

After all, 1Gb is doing 10 times more work than a 100Mb port and 1Tb is doing 1,000 times more work than a 1Gb port and 10,000 times more work than a 100Mb port. One box may be replacing many boxes and so overall, lower power consumption

Therefore another calculation that should be considered would be Watts per Mb or Gb.

Point is, clearly this is a little more complex than Tony is making out, but of course, that would kill Tony's argument.

Finally, on that last note, Tony seems to spend an inordinate amount of time negatively commenting on competitors on blogs - often caustically. Just as with elections, this is a sign that the candidate is losing.

Whatever the right calculation