我认为SDN的定义还是很模糊，我也不是完全肯定到底什么是重要的，这是一个有意思的现象，而更好地了解SDN有助于教育进程。

原则和协议阵营不同看待SDN

当大部分人在谈论什么是SDN时，他们大概可分为两种阵营：原则和协议，你会经常听到有人把SDN描述为控制和转发层的分离，你或许听到人们说SDN需要“开放”，这些人属于原则阵营，他们不太关注技术的实例化，更关心的是如何定义SDN。

另一个阵营则旨在探讨专用协议和技术，他们无疑是以OpenFlow为旗帜，但是他们或许还包括BGP-TE, PCE，ALTO和I2RS技术。他们视SDN为一种带有专门创建模块的架构，而这种创建模块的出现决定了一个方案是否能被称作是SDN。

我认为这两种定位都不正确。

上周争论过GMPLS是否是SDN,它确实是侧重控制层和转发层的分离,是一种开放的标准,它也绝对是用软件部署的,似乎它满足SDN的大部分架构标准,但GMPLS是否是SDN的讨论还不如其周围的讨论要精彩。

是以软件来定义SDN吗?如果只因为部署的时候依靠软件部署，就称某个东西为软件定义，或许也太糊弄人了。事实上，传统网络的主体特性都是用软件部署的,而主流厂商也把80%的研发投入在软件相关的工作上,如果仅以此来定义，那么一切都可谓之软件定义。

人们谈论软件部署的时候，真正用来区分的是看产品功能是寄居在联网设备上，还是在网络之上的其他地方。但是我们应该对此非常明了,不论无论某些应用是不是在机箱上运行，这都是封装的细节，而不是核心属性,网络设备都具备一些转发ASIC和通用的处理器,无论你是编写什么东西，还是在金属薄片中或服务器上本地运行，这些都不相关,如果厂商决定在他们的机箱里放入单独的中央处理卡，你会把这种方案标榜为软件定义吗?

控制和转发的分离是有意义的决定性因素吗?

网络设备行为都是状态驱动的,无论状态是由持久的配置来决定还是通过协议来学习,如果你通过一个CLI技术或控制器设置状态，这会让方案偏向SDN一点还是偏离一点呢?

大多数人谈论控制和转发的时候，其实是谈论管理层,基于控制器的方案肯定要分离管理层,但策略服务器，OSS/BSS方案和其他编写较好的Perl脚本也是如此，它们把从内容版本化的系统把信息作为设备管理的一部分推入。

开放就意味着SDN吗?没有人会说只要开放，就能成为SDN,真正的问题在于，是否有什么可以被称作SDN且不开放呢?答案很大程度上取决于人们如何定义SDN。你能创建一个由软件部署，基于控制器，且使用专属协议的方案吗?当然可以,如果这种方案的寿命是八年，而且IETF批准了用于基础协议的标准，那么你部署的方案有没有从非SDN转向SDN呢?

讨论落脚点在哪里呢?

我并非认为在为产品贴上SDN标签前，不需要考虑一些重要的原则,我只是认为它跟环境的相关性大过和技术的相关性,对我而言，我相信有技术可兼容SDN和非SDN架构的,协议的使用方式决定了你的产品是否是SDN。例子不胜枚举，但是我会从BGP，XMPP，NETCONF，YANG甚至是GMPLS开始,同理，我认为也存在非SDN的基于控制器的方案，就好像可能存在不基于控制器的SDN方案一样。

这意味着，我们的讨论要避开技术搭建模块，而要更侧重环境。这里举三个例子：

授权——OSS/BSS系统已经处理了不同厂商的不同设备所搭建网络的内部管理问题。方案就不能只是简单地部署主控翻译器，把配置告诉其他设备吗?对我而言，SDN似乎是用来减轻单个要素的管理难度的。这只在授权的时候才发生。只有中心控制器通过单个要素的要求，而不是从细节对它们进行管理时，才能发挥大作用。想象一下，如果你的CEO告诉每个员工该怎么做事，你的公司怎么可能高效呢?

提取——授权取决于提取。如果SDN的目标是让工作流更具可控性，提升网络性能，那么我们就需要降低其复杂度。我们跟设备指定型的指令要少打交道，应更侧重主要意图。IT基础设施的不同部件能协作的唯一方式是使用通用语言，而这就需要提取。要让运算，存储或应用依据VLAN和ACL不比把网络管理员变为存储或运算怪杰来得实际。

全球化——集中式控制说的并不是软件在何处运行;它指的是软件可以从事的事情。基于控制器的方案，其前提条件是对可用资源有全盘了解，这样才能做出明智决定。如果你的网络，有没有OpenFlow都没啥区别，那么你叫不叫它SDN又有啥关系?我们需要是要把事情做好，而不是仅仅与人有差别。这样的目标就需要我们有全球化的视角。

我认为是完全有可能创建开放的，以控制器为基础的系统，不过这种系统可能不能实现SDN的承诺，就好像有可能用新的方式再次利用原有技术一样。最终，是环境——而不是性能决定了SDN能兑现什么。