APIC declarative approach to network and policy allows it to interact with different data plane implementations. APIC does not need to have low-level information of the data plane specifics, since each data plane will be programmed in its own particular way via a local OpFlex agent. This approach has advantages scaling, but in addition, it allows us to adapt to changing environments and potentially work with third party data plane elements. As an example, APIC can program L2, L3 and stateful security policies to Open vSwitch instances. We use that approach as part of our OpenStack KVM integration as well as on the APIC CNI-plugin integration with Kubernetes.
A consequence of this architectural advantage of APIC is that it does not depend 100% on the virtual switch. In other vendor SDN implementations, you have to install (and license) the vendor’s virtual switch and in absence of it, you get nothing. Not the case with APIC.
For instance, in the case of the VMware native VDS we can’t program policies on it, but we can program it using open northbound APIs with simple features in order steer all traffic to the ACI leaf, where we can apply policies. In a way, we program the VDS to act like a FEX: all traffic goes to the leaf where we can do more intelligent things. So sometimes we apply policy on an ACI leaf, sometimes we apply policy on a virtual switch, and sometimes we will do it in other data planes.