在定位OpFlex政策协议思科营销官员一再强调，它是OpenFlow、OVSDB和业界许多其他公司(包括VMware - sans OpenFlow)首选的命令式网络可编程模型(命令式网络可编程模型)的最佳南向协议替代品。但思科工程师对我们的描述感到不快OpFlex甚至对其作为OpenFlow/OVSDB替代方案的解释持保守态度。
郑重声明，我们说过OpFlex是一个OpenFlowSDN杀手级的意思是基于OpenFlow命定的、分解的、解耦的控制/转发架构的SDNs，我们认为这与思科的整体定位是一致的以应用程序为中心的基础设施在更大的SDN环境中:作为对SDN强制采用和扩散的阻碍、抑制或威慑的最佳替代。我们是不唯一与此理解。
除此之外，思科工程师们还需要让别人听到他们的说法。凯尔有如夜有一个很棒的博客在这里关于OpFlex策略程序员如何利用OpenFlow和OVSDB(网络程序员)将策略灌输到网络基础设施中:
OpFlex可以通过策略代理嵌入到设备或主机中。这可以是一个虚拟交换机，比如Open vSwitch，一个白盒交换机，一个负载均衡器，一个防火墙，或者任何其他可以强制执行策略的元素…
OpFlex的关键部分是策略授权和策略代理。策略代理异步解析策略权限中定义的策略。然后，策略在特定于系统的实现中呈现为设备或系统提供的可编程功能。可编程功能的例子可以是Open vSwitch支持的OpenFlow和OVSDB协议、Arista的EOS提供的api、Cisco设备上支持的onePK api，甚至是防火墙设备的CLI接口。OpFlex不会取代系统提供的可编程机制，它与这些机制协同工作以执行策略。这是许多人忽略的关键部分……
OpFlex并不是要取代Open vSwitch，也不是要取代任何其他的主机或系统可编程层。开放vSwitch是一个伟大的开源项目，思科是贡献者。我们计划继续与开放vSwitch社区以及OpenCompute、OpenDaylight和ONF等项目密切合作。
所有的好。然而，与此同时，思科批评了OVSDB和强制性的SDNs，以及由合作伙伴转变为竞争对手的VMware的战略本白皮书描述OpFlex的作用和存在的理由:
当今的许多SDN解决方案通过分离虚拟域和物理域而增加了复杂性，同时在两者之间提供很少或根本不提供可见性。由于使用集中式控制平面而不是分布式控制平面，许多解决方案都受到可伸缩性和性能限制的困扰。此外,他们倾向于使用固定、僵化的模式为交互设备,有效地减少了网络最小公分母特性。例如,一个协议(如Open vSwitch数据库(OVSDB)管理协议只允许配置的基本原语如港口、桥梁和不容易适应暴露供应商创新……
声明式控制系统，如Cisco ACI，比命令式系统，如VMware的NSX提供了许多优势。
最后，声明式系统(允许以抽象术语指定策略)具有很强的互操作性特征。多个供应商可以使用和执行相同的策略，而不需要相同的硬件配置或软件版本。事实上，供应商可以继续在他们的平台上创新并公开新特性，只要他们尊重抽象策略的语义。因此，这种方法消除了当今基于软件的覆盖解决方案所建立的最小公分母限制。
这一切都在意料之中。思科不愿背书VMware的策略就像VMware想要支持思科ACI一样。
因此，将OpFlex标签为OpenFlow是一种延伸SDN杀手在OVSDB命令式模型和VMware战略的背景下?也许。它显然是一种替代，也是一种补充，就像ACI是解耦/分解的SDN的替代一样。OpFlex更准确的目标是OVSDB。一个愤怒的OpenDaylight贡献者和开发者告诉我们，Cisco本可以轻松地扩展OVSDB来做OpFlex所做的事情，但是他们选择编写一个全新的协议。这就是思科做事的方式。
虽然它可以在一个OpenFlow/OVSDB的SDN中工作，但思科希望你购买OpFlex和ACI，而不是购买OpenFlow/OVSDB和VMware的NSX和comingOpenStack国会政策模型。任何相反的做法都将与思科非常不同，都承认其“开放”的定位和姿态。
说到由VMware驱动的OpenStack大会，它的声明式策略模型打算是南向协议不可知的——它将支持OpFlex、OVSDB或客户选择的任何其他策略管理协议。
“没关系，”他说蒂姆Hinrichs他是VMware公司的软件工程师，也是国会的一名开发者。“为沟通策略选择任何合理的协议，我们都很高兴。我们将支持他们所有人。”
Hinrichs说，OpenStack大会和OpenDaylight小组的政策模型开发者正在就连接两者进行对话，这样更广泛的大会云政策框架就可以与以网络为中心的OpenDaylight政策引擎共享信息。
更多来自思科子网:
遵守所有 Twitter上的思科子网博客 。 Jim Duffy在推特上说遵循