如今，虚拟化以及云计算给现有的数据中心的网络带来前所未有的压力， 新的东西向的网络模式（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的工具， 使得我们可以快速的创建以及部署。