SDN和OpenFlow是两件事。SDN(Software Defined Network，软件定义网络)具备灵活的集中控制和云化的应用感知能力，是靠谱的下一代IP网络管理架构设计思路;而Openflow因管理颗粒度不完整和架构缺乏网管网设计，算得上是一种不靠谱的协议。
SDN是下一代IP网络管理架构设计的代表，这种思路强调拆分控制层面与转发层面，用“流交换”替换 “包转换”，用“集中管理”取代单独配置。OpenFlow则是实现这种思路时，用网络集中管理平台的流表(Flow Table，更通用的词是NIB，即Network Information Base)取代网络设备路由表(RIB，Routing Information Base)的协议。
学术界当初因OpenFlow提出了SDN，基于可以理解的动机，这两个概念被有意地模糊。但事实上，从理论体系的完善性和具体实践看，这两者有着巨大的区别。
为什么说SDN靠谱呢?
我们先看网络的现状。信息如同资金，要有流动性才能发挥价值。于是，随着IT的重要性提升和体量增长，网络作为信息流动的平台，其规模越来越大。伴随着规模的扩张，用户发现了两个现象。一是，其平均端口建设成本和管理成本不但没有按规模递减，反而更贵了;二是，不同应用对网络的要求很不一样，既有IP网络根本无法实现针对性的管理。
第一个现象产生了集中控制的需求;第二个现象则是要求网络能够实现应用感知。SDN初始的架构设计，以及经谷歌、Facebook等公司的实践改进，恰好能够实现灵活的集中控制和云化的应用感知。SDN的灵活性体现在，它提供了集中控制的NIB表、将 NIB打包成服务的API，再将API网管策略逻辑化的控制引擎。建表的目前主要还是OpenFlow，打包API的包括Onix，控制引擎包括 Ethane和Google使用FML(Flow-based Management Language)自建的安全平台等。这几种技术和软件配合，可完整实现以“流”的方式管理流量。而SDN云化的应用感知不仅体现在NIB表可以做到 4～7层，更重要的是，可以在控制引擎中直接输入应用状态控制策略。例如，当应用在不同数据中心漂移时，其包括IP地址在内的网络属性也可以跟着移动。
下面，谈谈为何Openflow不靠谱。
管理颗粒度不完整是OpenFlow面临的第一大问题。OpenFlow形成流表的源数据来源只是 TCAM(Ternary Content Addressable Memory，即三态内容可寻址存储器)。而为实现管理目标，既有网络设备还有大量其他技术方式。例如，对MAC地址的过滤是通过端口ASIC芯片直接完成的;SNMP Community管理是通过CPU实现的;线速交换控制是通过FPGA(Field Programmable Gate Array，即现场可编程门阵列)实现的。管理不完整还意味着不同管理机制间无法协调，这实际让Openflow完全不可用。而基于TCAM所导致的另一问题是网络规模不可能太大。因为，毕竟厂商提供TCAM的初衷只是针对一台设备，而非整个网络。
第二个问题是架构缺陷，即缺乏网管网的设计。所谓网管网，就是网络管理平台为了完成与网络设备通讯自身需要建设一张管理网。这张网管网，如何跟业务网(也就是跑其他应用的网络)分开，是带外还是带内，是静态协议还是动态协议，OpenFlow的架构中没有设计。没有网管网的架构设计，OpenFlow各种上行和下行管理报文在规模化部署的场景下，一定会出现问题。集中控制本身就意味把鸡蛋放在一个篮子里。如果无法保证篮子的可靠性，任何设计都是“对策比问题更糟糕”。
因此，这就不难解释互联网界对这两者的态度了。比如，谷歌在ONF 2012(Open Networking Foundation，开放网络基金会)上，热情洋溢地将提高自身广域网100%利用率的功劳归于SDN，而对OpenFlow谨慎地使用了 “Infancy”(婴儿期)的词汇。同时，谷歌还在公开场合将OpenFlow形容为“Improvise”(凑合)。
相比谷歌这样的互联网大佬，厂商界则有更强劲的理由追捧SDN和抨击Openflow。比如，思科目前的官方态度是“看好SDN，但不表示看好OpenFlow”。SDN是由学术界发起的，大势已成，厂商们只能跟牌;同时，顺势而为还能省下大笔教育客户的成本。而前文分析到OpenFlow的管理颗粒度不完整这一缺陷，厂商实际可以从根本上解决。解决方法也很简单，就是直接修改网络操作系统，让 Openflow的管理数据来源从TCAM延伸到ASIC、CPU、FPGA。甚至于说，厂商可以将原操作系统 API化，让集中控制引擎直接调用操作系统，实现更为精细的控制。
近十几年来，除端口速率、每端口成本、每设备端口密度等偏向制造能力驱动的创新外，IP网络业已沉静太久，而SDN是最佳搅局者。这次，会真的不同。
