APIC如何来控制ACI中的设备呢？它所采用的协议就是OpFlex（当然，不清楚思科是否把ACI所用到的所有细则都写到OpFlex标准中去了）。那接下来我们就分析一下OpFlex，看它如何应用于ACI。

OpFlex协议中有AD(administrative Domain)、PR(Policy Repository）、PE(Policy Element)、EP(Endpoint)和 EPR(Endpoint Registry)这几个概念。它提到AD就是一个所有支持OpFlex的设备组成的管理域（该draft举例说，比如一个数据中心的物理Fabric网络就是一个AD）；PR是在一个全局集中的地方，负责存放Policy；EPR也是在一个全局集中的地方，负责管理Endpoint的注册，PE则位于ACI中每一台需要管理的设备上（是一个逻辑功能组件），它负责向上通告Endpoint的注册、变更，并应用来自APIC的Policy。而EP就是接入到该管理域的用户设备。显而易见，PR和EPR都（逻辑的或物理的）位于APIC上。

上面这段文字可能比较抽象，我们换个更直白的说法，它的工作原理大概是这样的：用户在APIC上配置了一堆的Policy，比如“如果某个用户设备的Mac是位于某地址段，就把它们划分到Compute Node EPG，统一应用策略A”；“如果某用户设备发出来的报文Vlan是10，就把它划分到Tenant1，统一应用策略B”等等。当ACI中的边界节点检测到某台用户设备接入的时候（具体检测方式并没有提到，估计是用户自定义，由APIC通过策略告知所有的边界设备），就把这个EP的信息主动上报，注意它并不是直接报给APIC，而是先报给上一级设备（Spine节点），如此层层上报，最终到达APIC。之所以要层层上报而不是直接报给APIC，是因为中间的设备也需要了解这些信息。举个例子说，如果检测到Vlan 10接入了，那就需要通知上联设备把相应的端口上使能Vlan 10。报给APIC之后，APIC分析接入的设备信息，决定它属于哪个策略组（EPG），然后把该EPG所对应的Policy下发给所有的相关设备，这些设备就在本地应用这些Policy。当然，也可能是APIC预先把这些Policy下发给这些设备了，这取决于应用场景。

ACI带来的好处就是业务的自动化部署，设备即插即用。你可以想象成你买了一个USB的设备，插到电脑上之后自动安装驱动和应用程序。当然ACI要做到这一点并不是那么容易，以上都是理论分析，实际网络要复杂得多，未必都能做到。

OpFlex详细定义了各种消息格式（都是基于JSON），以及每种消息的通信主体。它试图把OpFlex尽量定义得更通用，不仅仅局限于数据中心云计算网络，而是任何适合需要自动化网络业务部署的场所。

ACI和OpFlex技术本身的分析到此结束了，下面我们来分析一下思科的SDN思路。

首先，ACI和OpFlex算不算是SDN？绝对算。当然我知道有人不同意，说明明他们的设备上都运行了传统协议，怎么能算SDN呢？但是你要明白，交换机上不运行路由协议，只是OpenFlow的要求（甚至就算是OpenFlow，都定义了output to normal这种动作，也就是说走完OpenFlow流程后再走传统转发流程），不是SDN的要求，SDN只是说软件参与到网络控制中。在ACI的这个架构中，最上层的应用和各种工具通过开放的Restful API来控制Controller，Controller则通过开放的OpFlex API来控制转发设备，用户通过Policy几乎可以控制一切。有人说，ACI设备之间的数据报文通信，还是要靠路由协议，用户无法直接控制。但问题是，用户为什么需要控制这个？能带来什么价值？SDN并不意味着用户需要控制一切，而是让用户可以控制他需要控制的东西。所以，尽管我不是思科的粉丝，但是我这个SDN的坚定支持者也必须承认ACI是SDN。

其次，思科为什么要将OpFlex标准化？很显然，这是它整个战略中重要的一步。我不清楚他们是不是开始的时候就已经想好了这一步，但是很显然，ACI被很多人批评的一点就是它是一个完全私有、完全封闭的东西，不仅跟其他厂商设备不兼容，连跟自己之前的设备都不兼容，这是它最大的一个弊端。现在它希望通过开放并标准化它的控制协议来规避这个问题。虽然OpFlex这个draft上列了好几个公司的作者，但是明眼人很容易看出来，那几个公司的作者都是打酱油的，都属于思科的战友，来帮思科撑场子的，表示这个协议不是思科一家支持。