發送命令(不清楚是NetConf還是直接的命令行)來控制交換機，交換機上仍然運行了傳統的二三層協議，控制跟轉發并沒有分離，分離的是管理和控制。剛看到這個方案的時候，我馬上就問自己，這算不算SDN?我反復思考了這個問題，他們為什么要這么做，而不是使用更徹底的控制跟轉發分離?我個人理解是他們網絡中已經有了大量傳統的交換機，他們不可能把這些交換機都替換掉，但是又想通過軟件自動化來代替手動操作，所以就采取了這樣一種折衷的做法。這種做法有沒有價值?肯定是有，否則他們不會這么干。那算不算SDN?我一時陷入了迷茫。幾經思考之后，我認為，其實SDN并沒有確切的定義，只要能實現網絡自動化，能夠滿足特定場景的需求，哪怕這種做法對別的用戶沒有意義，它也應該算SDN。只是從通用的角度來看，這種SDN靈活性比不上控制與轉發分離的那種架構，但是不可否認的是，它能解決特定客戶特定場景的需求。認識到這一點之后，我在對外宣講的PPT中，將SDN定義歸為三類，第一類是狹義SDN(等同于Openflow)，第二類是廣義SDN(控制與轉發分離)，第三類是超廣義SDN(管理與控制分離)。而且我認為，第二類定義中的SDN，是最通用，最有價值的一種。

　　第四階段。在跟中國電信研究院的專家們一次交流中，我講了我對SDN的看法之后，研究院的王老師向我提出了一個問題：從SDN的字面意思來看，根本看不出控制與轉發分離的意思，你怎么看這個問題?雖然我當時噼里啪啦講了一堆，回答了這個問題。但是回來之后，我又深入的思考了一下王老師的這個問題，很慚愧，這么一個明顯的問題，我之前居然都沒去思考過。思考的過程中，我突然有種醍醐灌頂的感覺，就像佛語經常說的那樣：看山是山->看山不是山->看山還是山。無論是控制與轉發分離，還是管理與控制分離其實都不是SDN的本質定義，SDN的本質定義就是軟件定義網絡，也就是說希望應用軟件可以參與對網絡的控制管理，滿足上層業務需求，通過自動化業務部署簡化網絡運維，這是SDN的核心訴求，控制與轉發分離不是。但為了滿足這種核心訴求，不分離控制與轉發，比較難以做到，至少是不靈活。換句話說，控制與轉發分離只是為了滿足SDN的核心訴求的一種手段，如果某些場景中有別的手段可以滿足，那也可以，比如管理與控制分離。