SDN的核心本质到底是什么？

发送命令(不清楚是NetConf还是直接的命令行)来控制交换机，交换机上仍然运行了传统的二三层协议，控制跟转发并没有分离，分离的是管理和控制。刚看到这个方案的时候，我马上就问自己，这算不算SDN?我反复思考了这个问题，他们为什么要这么做，而不是使用更彻底的控制跟转发分离?我个人理解是他们网络中已经有了大量传统的交换机，他们不可能把这些交换机都替换掉，但是又想通过软件自动化来代替手动操作，所以就采取了这样一种折衷的做法。这种做法有没有价值?肯定是有，否则他们不会这么干。那算不算SDN?我一时陷入了迷茫。几经思考之后，我认为，其实SDN并没有确切的定义，只要能实现网络自动化，能够满足特定场景的需求，哪怕这种做法对别的用户没有意义，它也应该算SDN。只是从通用的角度来看，这种SDN灵活性比不上控制与转发分离的那种架构，但是不可否认的是，它能解决特定客户特定场景的需求。认识到这一点之后，我在对外宣讲的PPT中，将SDN定义归为三类，第一类是狭义SDN(等同于Openflow)，第二类是广义SDN(控制与转发分离)，第三类是超广义SDN(管理与控制分离)。而且我认为，第二类定义中的SDN，是最通用，最有价值的一种。

　　第四阶段。在跟中国电信研究院的专家们一次交流中，我讲了我对SDN的看法之后，研究院的王老师向我提出了一个问题：从SDN的字面意思来看，根本看不出控制与转发分离的意思，你怎么看这个问题?虽然我当时噼里啪啦讲了一堆，回答了这个问题。但是回来之后，我又深入的思考了一下王老师的这个问题，很惭愧，这么一个明显的问题，我之前居然都没去思考过。思考的过程中，我突然有种醍醐灌顶的感觉，就像佛语经常说的那样：看山是山->看山不是山->看山还是山。无论是控制与转发分离，还是管理与控制分离其实都不是SDN的本质定义，SDN的本质定义就是软件定义网络，也就是说希望应用软件可以参与对网络的控制管理，满足上层业务需求，通过自动化业务部署简化网络运维，这是SDN的核心诉求，控制与转发分离不是。但为了满足这种核心诉求，不分离控制与转发，比较难以做到，至少是不灵活。换句话说，控制与转发分离只是为了满足SDN的核心诉求的一种手段，如果某些场景中有别的手段可以满足，那也可以，比如管理与控制分离。