Cisco CCIE emeritus star Greg Ferro SLAMS Cisco's SDN platform: Application Centric Infrastructure (ACI)
"The ACI platform has many moving parts including software and hardware, and will take years to achieve momentum. It took Cisco 90 minutes to explain the entire product and technical strategy to me. Cisco has a checkered history of developing software; consistently failing to develop or maintain products during the last decade. A long line of failed software products from acquisitions or internal development suggests a systemic business problem. Customers remember abandoned strategies like Application Oriented Networking and products like CS-MARS and CiscoWorks. Some will question whether Cisco can do software, as well as its commitment to all of its products."
"We conclude that, within our coverage universe, the long-term implications are most negative for Cisco...Cisco appears unlikely to win AT&T Data Center opportunity; Trends in Service Provider routing may not work in its favor.
"We do not think AT&T will be particularly receptive to Cisco's recently announced Application Center Infrastructure (ACI) architecture, including Nexus 9000 switches, because it still seems too complex and proprietary compared to more white box-oriented architectures."
You just knew Cisco CCIE emeritus Greg Ferro had become a "networking star" when Cisco's next CEO Rob Lloyd quoted Ferro's statements on the 3rd slide of Lloyd's PowerPoint Presentation to Wall Street earlier this month:
We all know earlier this month Cisco Senior Vice President of Marketing, Soni Jiandani, dazzled Wall Street analysts with her command of Cisco's technical prowess and her superb ability to "talk over the head" of any analyst who dared question whether a Cisco product was meeting success:
"For customers who are considering SDN for their data centers, the Cisco ACI strategy will be arriving sometime in late 2014. That's just about enough time to get planning and budgeting -- if you hurry."
Well, what a difference a month makes according to Ferro's December 12th Network Computing article (the same day as the Cisco FAC 2013 webcast event):
"The ACI platform has many moving parts including software and hardware, and will take years to achieve momentum. It took Cisco 90 minutes to explain the entire product and technical strategy to me.
"Cisco has a checkered history of developing software; consistently failing to develop or maintain products during the last decade. A long line of failed software products from acquisitions or internal development suggests a systemic business problem.
"Customers remember abandoned strategies like Application Oriented Networking and products like CS-MARS and CiscoWorks. Some will question whether Cisco can do software, as well as its commitment to all of its products."
Cisco CCIE #9961 R&S and Dell Force10 SDN technical marketing manager, Art Fewell, replied to Ferro:
"Where I really fault Cisco both with UCS and ACI is, they really want to convince the market that we all need them to do this for us because certainly none other than the great Cisco could solve networking problems. And that is just so full of FUD its crazy. Why is it that enterprises want to do elastic cloud networking and self service ... is it because Cisco was pushing this? NO! This model was driven by cloud providers and now enterprise IT is clamoring for it because their execs have seen it working in the public cloud.
"And even after the public cloud was already delivering elastic cloud networking for distributed computing, Cisco comes out with UCS and regardless of what you may say about it, it was built for the opposite traffic pattern of distributed computing. So nice try to build a closed converged management model, but built on FEX's? Could there be anything more myopic? And it was all completely unnecessary as both self-service and elastic networking were already working in production over more open technologies and architectures."
Then last week Ferro delivered another Network Computing bombshell:
"With so many products in the mix, it's reasonable to question Cisco's commitment to support any or all of them over the long term. In the decade from 1998 to 2008, Cisco had only one data center switch: the venerable Catalyst 6500. Today, Cisco has five product families in the data center with significant feature and function overlaps. With the addition of ACI, it's a confusing morass of products that customers and resellers will struggle to make clear decisions about, add delays to the purchasing cycle. More delays may occur while customers pause on network upgrades while deciding which strategy to follow."
"There are more than 30 current Ethernet switch models in the Nexus lineup that share 90% of their features and capabilities. Specifically, the Nexus 9000 overlaps enormously with many of Cisco's other data center products. The Nexus 6000 would seem to be at serious risk as a Layer 3 ECMP scale-out switching platform at price multiples of the Nexus 9000. Customers using Nexus 7000 products for data center core also may be questioning its longevity. The Nexus 7700 was recently refreshed, and it remains a kitchen sink for features including MPLS, OTV, and LISP, but lacks orchestration or automation for SDN applications."
"Customers who are hoping to see Cisco ACI come to the Nexus 7000 family in the form of NX-OS Plus software should be cautious. NX-OS has a long history of late delivery with poor code quality and complex upgrades. Even if NX-OS Plus ships in years ahead, it's reasonable to expect to purchase new line cards to get ACI integration based on past experience."
Cisco's technical marketing and solutions engineering guru Frank D'Agostino replied to Ferro:
"There are multiple Cisco products that leverage Broadcom or other merchant ASIC's. Merchant Plus strategy allows us a better hardware TTM, better costs and ability to compete cost effectively and profitably against the emerging white box merchant silicon (do your homework and read the Deutsche Bank study). Additionally, Merchant technology only has limits in features, performance, functions, and cost. The Plus part helps us improve."
Here's a list of other possible Cisco ACI questions:
Are the ACI API's and NSH chaining protocol and VxLAN protocols proprietary to Cisco in how they are implemented?
If the Nexus 9000 doesn't have the features of the Nexus 7000, do customers have to choose between features and density?
If ACI is another fabric what does that say about the life of FabricPath and DFA?
Cisco uses OTV for data center interconnect on the Nexus 7000. Is it supported on the Nexus 9000 and do other vendors use it? Will the Nexus 9000 support LISP and MPLS?
How will ACI integrate with customers' existing management tools from BMC, VMware or OpenStack?
What is the migration path for customers who have invested in current Cisco fabric architectures?
To realize the full benefits of Cisco ACI will customers have to upgrade their networks with all new switching hardware from Cisco?
Will the Cisco ACI platform manage existing Cisco equipment as well as 3rd party equipment?
Which modular product line will Cisco invest in the future, the Nexus 7000 or Nexus 9000?
As in past, will Cisco force customers to transition to new products?
Does the Nexus 9500 offer investment protection and upgrade paths from the the Nexus 7000 and 7700 product lines?
How will Cisco handle fabrics across Data Centers?
Is Cisco ACI an all eggs in one basket solution? I mean, will customers have an entire stack roadmap dependency on Cisco?
The ACI fabric does not inherently support DCI protocols so will Cisco position additional devices (Nexus 7000 or ASR) for DCI and advance features?
Management software has never been a Cisco strength and now Cisco wants to extend its offering to application and system administrators who already use other tools. Where is Cisco's credibility when in the past this has been a Cisco weakness?
Will Cisco's ACI Service chaining add additional overhead to the regular Ethernet frames and will this add additional overhead of MTU adjustments and tuning across networks?
ACI Fabric implementation itself is not optimal as it uses VXLAN multicast and flooding, will this lead to configuration complexity, additional network traffic and dependence on an IP Multicast enabled physical network?
