我認為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能兌現什么。
京公網安備 11010502049343號