Musings from the Cold Aisle
cchai , Regular Visitor
Musings from the Cold Aisle
5 Questions Cisco Doesn’t Want You to Ask About ACI
Jan 13, 2014

Last week, Cisco launched their Application Centric Infrastructure (ACI). Much of the discussion centered on business transitions, technology evolution, and how to capitalize on the next big trend, which they call the “Internet of Things.” And while it may sound good at face value, it’s important to look under the hood and evaluate if ACI can actually deliver on the promises that Cisco has outlined.

 

As you’re taking a closer look at the details surrounding this new infrastructure, here are five questions to ask about Cisco ACI: 

 

1.  Is Cisco’s open the same as your idea of open?

Openness must translate to conforming to industry standards, and supporting broadly used protocols to ensure interoperability, so that customers avoid getting locked-in by a specific vendor. In the past Cisco has implemented proprietary protocols well in advance of industry ratification and, at first glance, ACI looks notoriously headed in the same direction. open.png During the launch, Cisco stated that ACI would provide open APIs, and work with a host of partners in the data center ecosystem, but what they didn’t mention was interoperability. For instance, Cisco’s proposed technology to interconnect data center/cloud locations is based on proprietary protocols like OTV and LISP on the Nexus 7k switches. Furthermore, Cisco uses a proprietary NSH header for their specific implementation of service stitching. They also use proprietary optics on their devices like the QSFP-40G-SR-BD optic that only works in their new Nexus 9000 switches but not any other switch in the industry, including Cisco’s currently shipping Nexus switches. Make sure to ask Cisco how ACI will interoperate with other vendors’ equipment. You should be wary of “open-washing,” and instead focus on the key attributes of interoperability (Will what I buy work with my current or future technology from other vendors?), multi-vendor support, and flexibility (Can I continue to evolve my network solution to adapt to future open standards without another change?) so that you can build your networks to solve your problems. 

 

2.  How will ACI work with my current data center management systems? 

Your organization is probably not starting from scratch. You have some infrastructure in place, including servers, storage and networking devices. More than likely, you have data center management systems in place for provisioning, configuration, monitoring, health management and troubleshooting. Cisco didn’t announce support for vCenter for VMware environments, so with Cisco, you will still need vCenter and also APIC. What you really need is a single pane of glass across platforms and not a swivel chair method that’s prone to errors. Although they showed some other vendors’ logos on their slides, Cisco didn’t say whether ACI would work with existing versions of their management tools or if you will need a new version. So ask Cisco how ACI will integrate with management/orchestration systems that you already have in place that were supported by Cisco in the past. The last thing your organization needs is to implement a brand new management system that does not integrate well with your existing management systems, which requires additional cycles for training and increases the potential for mis-configuration.

 

3.  How long will Cisco support ACI fabric?

Cisco hopped on the fabric bandwagon a bit late, and over the past three years, they have come out with a number of solutions they call fabrics: Fabric Extender (FEX), FabricPath and Dynamic Fabric Automation (DFA), to serve different parts of their portfolio. With this announcement, there’s yet another fabric to add to the list and it’s not compatible with the others. The ACI fabric is based on a new approach using a VXLAN-based foundation. The obvious question is: What does this mean for FEX, FabricPath, DFA? Does Cisco expect your company to support multiple fabric architectures? Cisco has not stated if there is any migration path for those customers who have invested in current fabric architectures or if the switches used on those architectures will work in an ACI fabric and vice versa.  Even if the benefits of ACI sound compelling, it’s worth asking about the longevity of the fabric architecture (both the one you already purchased and the one you are considering to buy), since it’s such a large investment in equipment, deployment and administration that you are making.

 

4.  Will I have to rip and replace?

Cisco supported the Catalyst 6500 for over 15 years, but the Nexus 7000 is being made redundant by the Nexus 9000 after just a few years. As before, the new device does not have the same feature set as the one it is replacing. It seems that Cisco expects you to choose between features on the 7000 and density on the 9000, or that they expect you to buy two switches to do the job of one. What about their SDN architecture? You can’t use just one. You will have to run two SDN systems. The APIC controller works with the Nexus 9000s but the onePK toolkit works with the Nexus 7000s. Ask Cisco when the features promised by their SDN controller will be available and if (ever) there will be feature parity between OnePK and APIC. The announcement said it will be mid-2014 before the APIC is released. In the meantime, the Nexus 9000 is a middling stand alone switch as it depends on the APIC for the advanced features. The last thing you need is to get stuck at the mercy of a vendor and their product portfolio transitions, only to find yourself locked-in.

 

5.  How easily can I swap a component in or out of the ACI architecture?

At first glance, the value of the all-in-one data center stack seems attractive, like an all-in-one home theater system. For a single price, you can get everything you need to enjoy surround sound, play movies on DVD, and enjoy games. But what happens when you want to integrate the latest Blu-ray player? The point is that you need to maintain flexibility, so that when you need a new service which requires a new component, you can add it without being forced to go through a painful process of replacing the entire system. Similarly, in the data center, there are many components from various vendors. Some are networking devices and some are management, automation and orchestration tools. As the technology evolves around the network, you will need to add and remove components. Cisco has not said if you will be able to add components (other SDN controllers, other switches for their SDN controller) into their ACI service model seamlessly. Cisco needs to let you know if you can use common interfaces and cabling and not have to replace everything at once. Ask them if they will interoperate with other components, such as network management tools, and services appliances, in the ACI architecture without issues.

 

These are just a few questions we had after examining Cisco ACI, but I’m sure there are more out there – feel free to share any you may have in the comments below.

 

Update on 11/21: updated to correct the QSFP-40G-SR-BD optics to standards-based and interoperable with other Cisco platforms  

0 Kudos
Nov 21, 2013
Joe Onisick

Calvin,

 

**Disclaimer: I work for Insieme Networks (ACI/Nexus 9000)**

 

1) While we drive additional value from the Cisco APIC controller and Nexus 9000 platofrm our model for policy based application deployment will be based on open APIs and open source contributions.  This allows us to provide additional feature and functionality through Cisco innovations while leaving customers free to add on, integrate, or move off onto an open platform.  This is being worked on by several vendors.

 

2) As announced at launch ACI is partnered with a wide variety of current management tools and products, as well as emerging leaders.  This includes Cisco tools, and otherwise.  Additionally all functionality is exposed through an open RESTful read/write API allowing any system to integrate management with or without Cisco engineering resources.

 

3)  While none of the products mentioned are going EOL due to ACI/Nexus 9000, ACI's own longevity is a safe bet.  The executive team bringing ACI to market brought Catalyst, MDS, Nexus 5000/2000 and CiscoUCS to market.  Each of these are amazingly succesful and still being sold and used.

 

4)  Nexus 7000 and 9000 are not redundant although within a portfolio as robust as Cisco's you'll always have overlap.  Nexus 9000 is targetted at modern leaf/spine designs for east/west application traffic at the access/aggregation layer. It's also targetted at 40/100G speeds that exceed anything offered on the market. The feature set of products like the Nexus 7000 bring robust WAN/DCI capabilities that are not required at this layer (access/aggregation in the DC.)  They will work very well in tandem day 1 through standards based interfaces, and integrate more and more over time from a policy deployment standpoint.

 

5) ACI provides the API described above with full read/write northbound access for integration into any management/orchestration, etc. tool.  Additionally the southbound integration with L4/7 services from Cisco and several other partner vendors will also be open and extensible allowing customers to choose the devices and integrate them into the system at the depth that makes sense to them.

 

Hopefully this helps answer the question, the Cisco and Insieme teams are more than happy to answer these questions in more depth for any of your customers looking for more information on ACI.

 

Joe

Nov 22, 2013
cchai

Joe, thanks for your response. 

 

While I appreciate your diligence in providing an explanation, it was obvious from listening to the Cisco ACI launch broadcast that not everything is in place yet (such as the APIC, the ASIC, the APIs and the ecosystem integration) and that customers will need to do a fair amount of DIY customizing to get things their way. They'll also need to be careful with their platform choices, given the possibility of future feature discrepancies. For these reasons, potential customers need to be cautious and to ask questions. While the intentions might be there, we all know that things don't always come to fruition

 

I've read your comments on Twitter where you call our blog "FUD" and unresearched. I can assure you that we make every effort to present accurate information to help our customers better understand what this all means to them. When it's clear that we've presented inaccurate information, we take corrective action to set the record straight, as we've done in the above post. The fact is, we are not the only ones who have questions and doubts. Here are a couple of articles that raise similar questions:

As for your comments regarding QFabric, we are seeing greater interest than ever and are happy to share our success stories, such as this one with Yahoo! Japan: http://newsroom.juniper.net/press-releases/yahoo-japan-deploys-juniper-networks-qfabric-syst-nyse-jn...

 

In addition, during our recent MetaFabric launch, we announced more options for QFabric as well as other architecture choices to support customers’ needs: 

http://www.eweek.com/networking/juniper-launches-metafabric-network-architecture-switches.html

 

My colleague, Michael Leonard, also wrote in more detail about the launch in his post entitled, "Sorting Out the News and Making the Right Choices":

http://forums.juniper.net/t5/Data-Center-Directions/Sorting-Out-the-News-and-Making-the-Right-Choice...

 

We welcome your comments anytime and I'm sorry that you had difficulties with the platform. In the end, we are confident that customers will do their due diligence and we feel that having a broad array of options from Juniper will enable them to make the choices that are right for them.

Nov 26, 2013
Cesar Obediente

Calvin,

**Disclaimer: I work for Cisco ***

 

Couple of correction on your blog...

 

You mentioned: 

 

"For instance, Cisco’s proposed technology to interconnect data center/cloud locations is based on proprietary protocols like OTV and LISP on the Nexus 7k switches. Furthermore, Cisco uses a proprietary NSH header for their specific implementation of service stitching"

 

RFC6830 check for LISP.  

 

Regarding NSH, here is the draft which it is being backed by Rackspace, Citrix, and others in the industry.

 

http://tools.ietf.org/html/draft-quinn-nsh-00

 

Thanks

 

Cesar

 

 

 

 

Dec 8, 2013
Juniper Employee

Cesar, 

 

I think your arguement is invalid.

 

Regarding LISP, just because it is an RFC, does not make it a standard.  If you have a look at RFC6830, you will see that it is in the "Experimental" state.  Hardly a standard.

 

Regarding NSH, I think you just contradicted yourself.  Again, a draft doesn't constitute a standard.  Whilst it is true that many draft proposals have been implemented by various vendors, it still creates lock-in to those handful of vendors that choose to implement it.

 

Casual Observer.

Jan 13, 2014
CraigW

Is there any other LISP-like standard out there? Cisco has bent over backwards to remove all barriers to multi-vendor adoption. It's not their fault that Juniper is obstinate.

 

Forget the Internet. Say an enterprise has DC's in California and New York, and a branch office in Kansas City must forward traffic efficiently to an IP that can move between the two DC's. How does Juniper propose we solve that today? Bigger FIB's in the branch? Total dependence on a single WAN provider?

 

May 24, 2018
810-440 Dumps

Want to Pass 810-440 exam in first attempt? Pass your Cisco - Adopting The Cisco Business Architecture Approach Cisco Business Architecture Analyst certification exam with Cisco 810-440 dumps questions answers of Braindumps4IT. Your Cisco - Adopting The Cisco Business Architecture Approach success is guaranteed with our 100% money back guarantee. We have updated 810-440 exam questions and providing with Cisco Business Architecture Analyst exam passing assurance.

May 25, 2018
Joshua Gilmet

Thanks for the response CraigW Smiley Happy Came to this article late, but still informative.