博主想借这篇文章瞎子摸象，聊聊white box，目的是抛砖引玉。回顾2014年SDN领域的重大事件，Juniper的OCX应该排得进前三，它非常强烈的向市场传递出一个信号：white box的大潮真的来了。如何让这个大潮来得更猛烈，如何让我们这些押注SDN+white box的赌徒们分得一杯羹，是一个十分让人兴奋的话题。
首先明确一下这篇文章里所说的white box是指bare metal switch + ONIE，不预装其他任何软件。用户可以选择在交换机上安装怎样的操作系统。用服务器做类比就是裸机+BIOS，上面可以跑windows也可以跑linux。这里还请大家不要纠缠于定义的细节。另外，本文也不会讨论virtual switch，只讨论physical switch。
按照SDN宏伟蓝图最初的构想，在SDN+white box的产业链上本来应该有这样四个关键的环节：交换芯片，交换机硬件软件，控制器，应用开发。但SDN发展这么多年，根本没有发展成这个样子。博主观察到的现有企业大概是这样几类：1) 交换芯片，2) 交换机硬件 and/or 交换机软件, 3) 交换机软件 + 控制器，4) 控制器。博主在这里斗胆预测：单纯的控制器厂商会越来越无足轻重，第3类厂商会从第1、2类厂商那里获得越来越多的话语权，并逐步成为整个产业链的核心。至于为什么不会有真正意义上做SDN应用的厂商存活下来，博主在之前的文章中已经有所涉及(当然，系统集成商会永远存在)。那些钱多任性的大鳄当然什么都做啦。
博主做出以上预测的理由从本质上来说只有两点，第一：在现阶段，掌握交换机硬件比掌握控制器有更大的话语权。第二：只有将控制器和交换机软件进行整体设计和施工才能让SDN真正落地。
第一点不难理解。交换芯片和交换机是硬件，控制器是软件。不管控制器多么复杂，它的研发成本和周期比起交换芯片和交换机来说都不在一个数量级上。单就这一点而言，新一代开源控制器的出现对整个行业的影响力远远不及新一代转发芯片的出现。
更重要的是，不管哪家客户胆大到乐意去尝试SDN，他们在货比三家时一定会在三个问题内问道：你家的SDN方案有哪些硬件交换机支持?这些硬件交换机用的什么芯片和CPU?靠谱不?对SDN控制平面的关心反倒在次要的位置上。这也是为什么所有SDN解决方案提供商都会在最显眼的地方把“Hardware Compatibility List”列出来，并且这个list里面每增加一款硬件设备，都会请媒体做一次报道。于是这个市场里面就产生了这样四个阵营：
1)那些主流的交换机大厂。他们根本不屑于与任何SDN控制器厂商合作出方案，而是索性自己把控制器和解决方案都做了，不过这个控制器只能控制他们自家的交换机。只是他们会砸钱在多种渠道上打造开放的公关形象。
2)控制器厂商和第二梯队的交换机厂商合作推出完整的SDN解决方案。之所以强调完整，是因为如果你的解决方案中有一个环节还需要客户自己想办法的话，这个生意八成会黄掉。这个阵营是推动是SDN发展的中坚力量，其中的交换机厂商是这样pitch客户的：我们的交换机支持张三李四等控制器厂商的datacenter/WAN/TAP解决方案。如果你不用那些解决方案，也没问题，因为我们采用的是最主流的交换芯片+ONIE，上面可以装载任何厂家的操作系统和南向API agent。控制平面可以用SDN控制器也可以跑传统的2/3层协议。控制器厂商会这样pitch客户：我们有完善的datacenter/WAN/TAP解决方案，可以和王五赵六等数家厂商的交换机兼容，有开放南向接口和行业通用的北向接口。这样的合作至少给20年不变的网络界带来两个东西：开放和竞争。博主真心认为这种模式是SDN继续发展壮大的正途。
3)第二梯队的交换机厂商。这些交换机厂商硬件研发流程成熟，往往会根据重复出现的应用案例定制自己的交换机软件甚至是交换芯片，并且能够取得一定的市场份额。这类企业目前面临的最大问题恐怕是没有完整的解决方案，需要客户在他们的交换机基础之上，进行控制器的深度定制开发。但实际情况是绝大多数SDN控制器厂商都在努力完善与datacenter/WAN/TAP相关的解决方案。与控制器厂商合作转型到第二个阵营，会让这个阵营的交换机厂商获得快速的壮大。
4)单纯的控制器提供方。他们的客户绝大多数是科研机构和学校。大多数需求是控制mininet或者由openflow交换机搭成的小规模testbed。对于这个阵营的企业，如果不和交换机厂家联合推出完整的SDN解决方案并转型进入第二个阵营，要有大作为会十分困难。
接下来，博主会简要讨论一下为什么SDN控制器和交换机软件一定要整体设计和施工才会让SDN落地。具体的分析会细分成不同的话题在之后的文章中陆续讨论。SDN中心控制的思路确实极大的简化了网络管理的复杂程度，不过博主愚钝，曾经天真的以为可以将所有的网络控制逻辑都放在控制器里面，交换机只负责转发和packet-in就好了。但这种极端的想法让博主四处碰壁，很久之后才幡然悔悟：要根据具体的问题来决定究竟将控制逻辑放在控制器里还是offload到交换机上。比如之前博主讲到的ARP，将2层的ARP控制逻辑放在控制器上(主要是“种树”)，而将3层的ARP控制逻辑offload到交换机上(主要是default gateway)，目前看来就是一个不错的选择。需要认真作出取舍的设计决定还有很多: ICMP, DHCP, LLDP, LACP, NAT，动态路由协议等等。现在面对每一个控制平面甚至是数据平面的feature，博主都会问自己：究竟该把这个feature放在控制器上还是offload到交换机上会带来更多的repeatable use cases?这个思维训练让博主受益匪浅。
总结一下博主的观点：控制器厂商和交换机厂商合作推出完整的SDN解决方案是white box革命的关键;交换机软件和控制器整体设计和施工是SDN落地的关键。
