如今，虛擬化以及雲計算給現有的數據中心的網絡帶來前所未有的壓力， 新的東西向的網絡模式（east-west traffic ， 指的是數據中心內部網絡）, 極致的應用負載，以及對於靈活，聚合的巨大需求等都對數據中心提出了巨大的挑戰。於是， 各路諸侯紛紛提出他們具有應付這些問題最好的方案。 對於每個廠商而言， 他們的方案都宣稱其方案是0-擁塞， 任意網絡節點間端到端的傳輸， 但是其方案無疑是複雜而且極其昂貴的。正在他們廝殺的濃煙滾滾之際，SDN（軟件定義網絡）殺出一條血路並撼動整個中原。
SDN的支持者們宣稱SDN方案會將網絡的控制面解耦， 並且採用集中化的管理。 如此一來， 構建一個擁有巨量網絡實體的網絡成爲現實，並且這個網絡還能細微到控制每一條流， 可謂能上天，亦能入地。該方案可以根據需求用來快速的部署虛擬的網絡實體並且將計算，存儲和網絡都認爲是可以靈活配置的資源。 擁有可管理性，靈活性於一身的大殺器，頗具有宇宙之大，捨我其誰的味道。擁有如此大殺器，我們還需要傳統網絡架構麼？我們還需要數據中心的網絡架構麼？
實際上，無論數據中心的網絡架構還是身懷絕技的SDN都沒有被充分的驗證，對於使用者而言，我們應該怎樣選擇呢？
觀點
擁有SDN， 我們再也不需要各種數據中心網絡架構了
一旦SDN接管數據中心網絡，可能還是需要一些以太網的架構，但是這些只是基礎， 存在的價值只是爲了服務於SDN的各種抽象層----Brad Casemore
首先，爲了論戰， 我們假設SDN實現了其宏偉宣言，並且不僅可以應用於與服務提供商的數據中，也可以應用於那些巨型的企業集團，那麼我們還需要思科，Brocade，Juniper 或者其他廠家的以太網架構麼？
當然，市場中仍有傳統架構的一席之地，但這種存在顯然已經不是當今廠家的定位的那樣了。
在某些關鍵方面，SDN與fabric有着較大的共性。他們兩者都作爲潛在的網絡方案來解決現在肆虐的數據中心虛擬化以及雲就是那帶來的數據中心東西向的網絡模式，以及應用帶來的負載。
但是， 有時共性往往說明其存在差異， 而且這種差異往往是革命性的。領先的網絡廠商們所提供的fabric, 以標準的或是非標準的方式來解決以太網的multipathing（以太網多路徑）爲例，在網絡的演進中，代表了一個線性的，循序漸進的發展。網絡正在被向各個方向平面擴展，STP（生成樹協議，一種用於交換機去環的協議）正在被去除。但是， 這些業務對於廠商以及用戶而言仍然是具有很重要的意義。廠商們仍然賣給他們的客戶海量的傳統的網絡設備， 包括集中式的交換機，各種標準變種的協議，技術等等。（值得是cisco的Fabric？ Juniper 的Q fabric:)）
SDN採用了一種完全不同的策略。SDN的本質目的是網絡的虛擬化， 是通過分離控制面以及數據轉發面， 提供網絡的可編程性。在SDN中，通過將控制，智慧從網絡設備中上移到基於服務器的軟件之中(這是一個新的產生知識產權的領域)， 這樣網絡會變得更加快速，穩定，廉價以及相對默默無聞（應該是網絡設備）。如此一來，採用並且實現了SDN的數據中心並不需要大廠家提供的Fabric網絡，這些網絡在結構上，原理上跟ONF的虛擬化構架存在衝突。
但是有趣的的是，他們仍然需要Fabric。根據SDN的本質，這些新興的fabric會變得異常簡潔， 就像物理網絡一樣，實現一個互聯即可。451group的 Eric Hanselman形容Network Fabric是一種把機框擴展到在多個物理網絡中的技術（整個數據中心是一個大的機框）。與之輝映的是Nicira的CTO Martin Casado 在其博客中提到： Fabric 是一個物理網絡，這個網絡並沒有任何的配置約束... 就像機框中背板的功能一樣。這兩個定義對於SDN的需求的描述敲到好處。從長遠來說，一個基本的網絡Fabric將會出現來服務於高層的SDN的抽象， 如今的私有的fabric並不適合。
現在的問題是，誰來提供這個fabric。 在整個產業鏈中， 從物理網絡到基於服務器的控制器， 以及在上面運行的應用程序，考慮到這裏面的價值以及利潤，大的網絡廠商根本不想做一個水管工， 他們已經習慣於豐厚的利潤以及對於其自身命運的掌握。如果他們最終要接受命運， 那麼也只能是逐步的實現。
與此同時我們看到其他廠商開始提供相對廉價的硬件來迎合SDN的需求。ONF已經說服芯片提供商（Broadcom, Marvell, Intel’s Fulcrum）在其芯片中支持OpenFlow。同時ODM同時開始給雲服務商以及其他主要數據中心供應“裸”交換機。這種模式跟傳統的服務器的製造商類似，只是提供服務器的廉價而且功能強大的硬件。
也許會花點時間， 但是那些提供複雜的fabric的私有廠家不可能勝出....
COUNTERPOINT 的觀點
數據中心的fabric VS SDN， 兩個都不行
無疑數據中心需要革命，網絡虛擬化較之複雜的fabric以及SDN更具有優勢 -- Ivan Pepelnjak
像以往的技術革命一樣，Openflow跟SDN的追隨者們鼓吹他們的技術能夠解決世界上所有的問題。不可否認，有非常適合Openflow以及SDN的用例，但是對於數據中心的Fabric而言，其被定義爲在數據中心的環境下提供端到端的網絡傳輸， 顯然不適合他們中任何一個。
首先我們需要對SDN 的定義給予肯定，Openflow定義的非常優秀，相對於Openflow， SDN 本身不是一個新鮮物。IBM在1972年推出3705通訊控制器的時候已經使用軟件來定義網絡。事實上是，網絡從來都是有軟件控制， 大型網絡也總是被部分監視，並且由額外的網絡進行配置。但是爲了討論，我們使用ONF的SDN定義， 一種將網絡控制從數據轉發中分離出來的架構。
一些類似架構已經在數據中心網絡中被廣泛的使用，但是他們並不是特別成功。Cisco的VSS（Virtual Switch System）Juniper的Virtual Chassis 以及 Qfabric 網絡節點，以及HP的IRF，他們都是用集中式的控制面軟件來編程分佈在巨量交換機中的轉發表。所有這些架構有一個共同的缺點-他們不具備可擴展性。這些廠家的大多數一個控制面只能控制10個TOR（top-of-rack）交換機或者是8個核心交換機。NEC的流可編程的控制器可能做得稍微好點。同時，如果你研究一下Google的不太有名的G-scale網絡-- 我們所見過的最出名的產品級的Openflow的例子， 也可以得出相同的結論。 Goolge 只是使用Openflow來控制位於Controller周圍的少量的設備。試圖使用一個集中地控制點去管理一個擁有非常快的反饋環的， 並且具有極高的變化速率的網絡一般不會奏效。
請別錯誤的理解我的意思，我並不是說今天的數據中心網絡非常完美。 實際上，他們面對着海量的可擴展性挑戰：這些挑戰大多數源自Hypervisor廠家只是簡單的使用VLAN來作爲虛擬網絡的實現。 將複雜性扔給Hypervisor沒有解決問題問題的根本，網絡界一直以來都在努力尋求解決方案， SDN/OF 只是他們中的一種。 最終，他們也許會創造出一隻會飛的豬（收你額外的充氣揹包的錢），其複雜性可以跟傳統的語音網絡具有可比性，當我們停止使用語音交換的時候， 只是簡單的去使用大量的， 廉價的語音， 比如遷移到像Skype這樣端到端的VOIP的方案。（）
結果呢
試想一個場景（比如Amazon或者Rackspace使用的那樣），在這個場景中，虛擬網絡的實現使用一種Mac-Over-IP的實現方式（可能是VXLAN， NVGRE，STT）或者是一種IP -OVer-IP的方案， 存儲工程師可能會使用一個基於IP的方案（iscsi， NFS， SMB3.0）。 In this case, 所有的複雜性都交給Hypervisor。 這種方式是使用Openflow控制此類環境的最好的方式， 在這種環境下，控制器面對的是一羣獨立的，沒有耦合的設備。這就是現在Nicira的網絡虛擬平臺做的事情。 數據中心的網絡只需要提供兩種服務， 端到端的IP傳輸，以及對於特定流的零丟包傳輸。
在一個定義良好的只是提供純的IP傳輸的數據中心網絡中，當需要增加新的虛擬機或者是新的server的時候，你沒有必要再去改變交換機的配置。你唯一需要改變網絡配置的時間是當你需要增加新的容量， 即使是這樣，一些交換機廠商提供的現有的工具也可以讓你自動完成這個過程。
總而言之， 一旦我們戰勝了愚蠢的VLAN， 使我們的虛擬網絡的問題迴歸到其本來的位置-hypovisor, 我們再也不會需要那些複雜的數據中心的Fabric以及那些複雜的工具來管理他們。 現行的大規模的IP網絡工作的非常好，同樣也沒有使用像SDN一樣的集中控制面。另一方面，擁有爲大規模IP網絡選配一個優秀的Privision工具將會帶來非常大的益處。我們不要SDN,我們要的只是一個像Puppet/Chef的工具， 使得我們可以快速的創建以及部署。