How does Cisco’s Application Centric Infrastructure relate to SDN?
What is ACI?
Cisco has a number of SDN initiatives in progress. The company is one of the main contributors to Open Daylight, an open-source SDN controller that's based on OpenFlow. Another initiative is the Application Centric Infrastructure (ACI). ACI is an SDN implementation that is not based on OpenFlow and takes a different path..
The ACI documentation says that it treats the network as a system instead of a collection of individual devices, which is something I've been advocating for many years now. A critical question that remains is whether ACI will monitor the network as a system. Monitoring is a bit of a challenge because some components are device-specific, like fans, power supplies, and memory utilization. Other things are system-wide, such as the extent of a Layer 2 forwarding domain.
What is APIC?
ACI relies on an SDN controller that Cisco is calling the Application Policy Infrastructure Controller, or APIC. It is logically centralized, which means that it has a single view of the entire ACI/SDN network and implements a single set of policies across the infrastructure. Multiple physical controllers may be used to provide resilience in the case of failure of a single control element. The APIC provides the single place where policies are implemented for defining how the network should function. Another way to think of it is that ACI defines how we want the network to function while APIC is the implementation mechanism.
One of the challenges with a centralized control system is ensuring ease of configuration and re-configuration. When a new controller is added to an existing control cluster, how does the new controller discover the existing cluster? Cisco's documentation says that the controllers use LLDP (Link Layer Discovery Protocol) and a private address range to auto-discover cluster members. I've not configured one of these yet, so it is too early for me to say if there is much configuration required. The documentation says "zero touch," but I like to understand the mechanisms and what kind of failures can occur. Very little in the complex world of networking is truly that simple.
APIC is where the control policies are defined. These policies include rules that define which inter-switch links should be active (leaf-to-spine connections) and those that should not be active (spine-to-spine or leaf-to-leaf). If an improper connection is discovered, the link is marked down and an alert is generated. Good policy definitions are going to be very important to a good SDN implementation, and this is one example of a policy rule. I expect to see network staff members becoming more adept at producing good network policies than producing detailed line-by-line network device configurations. Policies will be applied to multiple devices across the network, as you would want when controlling the network as a system instead of as a collection of devices.
What About OpenFlow?
Why not use OpenFlow? I briefly talked with Cisco's technical lead on the project, and he said that they looked at OpenFlow but that it was challenging to get it to do what they wanted. I don't yet have any information about the specific deficiencies they encountered. If I were speculating, I would say that they had problems getting their legacy hardware (Cat 6500s?) to run with acceptable performance or scalability when using OpenFlow. The new Nexus 9000 series is supposed to eliminate this problem.
Supporting legacy hardware is a common complaint from vendors. The result is a rip-and-replace (also called a forklift upgrade) implementation in which the legacy hardware is replaced with new hardware that includes the necessary functionality. The need for a forklift upgrade results in slower implementation by customers and the possibility that a customer might switch vendors in the process.
ACI in Action
I was able to see some implementation examples of ACI at Cisco Live and was impressed with what Cisco has done with it. One of the examples is similar to the QoS and SDN implementation that I recently described in previous blogs (see QoS in an SDN and Handling Video in an SDN World).
The demonstration showed a simple network of switches and two endpoints. (See Figure 1. ACI Demo Network.) There was not specific QoS defined on the switches for handling voice or video traffic. When one endpoint opened a new connection to the other endpoint, the APIC was informed of the connection by the UC controller. The APIC then pushed a QoS policy into the switches that were between the two endpoints. The demonstration was able to show that a new QoS policy had been implemented in the switches. It is as good a demonstration of the capability as has been shown by vendors other than Cisco (specifically, HP and Microsoft) that I referenced in the above blogs.
Figure 1. ACI Demo Network
There is a caveat here: I've not examined what happens under the covers. It is going to be useful to understand what kind of effort is required to implement the systems that provide this functionality and flexibility. We should also be looking at more use-cases and making sure that there are no serious hurdles in an implementation that an enterprise would need to construct.
However, most organizations are interested in the results. Even a bad implementation can often be turned into a good or even an excellent implementation by re-factoring the underlying software and providing a better user interface. Another approach is to provide an additional layer of abstraction on top of a too-complex API.
Beware the Chicken and Egg Problem
With any SDN implementation, there will be the push to virtualize everything possible in order to reduce costs and increase flexibility. But I foresee that some IT organizations will push this a little too far and virtualize parts of the control infrastructure. Let's say that there's a power outage that affects a data center in which SDN is running. Let's also say that this organization has virtualized the VM controller system and the SDN controller system. How does the network connectivity get created that allows the SDN controller to be created and connected to the network? Some basic network connectivity must exist for the SDN controller to begin to interact with the other critical components of the network and VM control system.
Summary
Cisco is betting on multiple SDN initiatives. They have the Open Daylight initiative to cover the OpenFlow part of the market. They have also bet on the ACI work as a "new and improved" form of SDN. This seems like a smart move. Some of the results of the ACI work may find their way into the Open Daylight initiative. Over time, I would expect to see the two programs move closer together as they share innovations.
