《云数据中心网络与SDN：技术架构与实现》——1.15.3　SDN 2.0?

1.15.3　SDN 2.0?

1.与OpenFlow / OVSDB的对比

上述就是SR的核心技术框架。前面提到过，有的厂商将SR称为SDN 2.0。下面不妨就来比较一下SR和OpenFlow/OVSDB。OpenFlow/OVSDB的特点在于“全面”，ID分配、拓扑发现、路由计算、FIB分发、隧道拆建、流量引导、流量调度以及带宽预留，这些事情它都可以做到。而SR是一个专才，只负责根据SID生成LFIB，然后转发源路由的流量，如果要用SR做SDN，就必须要搭伙其他的协议——发现拓扑要靠IGP/BGP-LS，流量引导要靠PBR/BGP-Flowspec/NETCONT，流量调度要靠PCEP，预留带宽要靠RSVP-TE。那么，相比于OpenFlow/OVSDB，SR的优势在哪里呢？从架构上来说，OpenFlow/OVSDB是纯集中式的，要打通一条路径，需要逐台设备进行控制，而SR在分布式和集中式之间找了一个平衡，先通过分布式的协议把拓扑和路由算好，然后找一个代表同步给控制器，控制器只要计算出目标路径发给Ingress Router，因此SR的可扩展性要强于OpenFlow/OVSDB，可以适用于运营商规模的网络。另外，SR的流量转发并不严格依赖于控制器，且能够实现50ms级别的故障恢复，因此具备更高的可用性。当然，SR相比于OpenFlow/OVSDB最大的优势还是来自于技术的向前兼容性，出于对商用风险的考量以及技术取向的惯性，运营商自然会更加倾向于SR。

2.“端到端”的理想

在大网这块站住脚之后，SR最近又开始做起了数据中心。借着“云网协同”的概念，一些厂商提出了将VM/Container、Host、Leaf、Spine、DC Edge、DC Uplink全部分配上SID，以实现DC-Metro-Core-Metro-Enterprise“端到端SR”的宏伟目标。图1-55是端到端SR的设想。

图1-55　端到端SR的设想

要做进数据中心，首先要搞定服务器端，那么对vRouter进行升级就是必不可少的，另外更彻底的是直接扎入到协议栈中，目前Linux 4.1.0已经开始提供对SR的支持。从服务器出来之后，就进入了DC的Underlay Fabric，鉴于Google、Facebook等大型OTT在近几年将BGP应用于超大规模数据中心的推动，SR拾起了长期以来一直不温不火的BGP-LU（BGP Labeled Unicast，RFC3107）来宣告SID与Label的关系，以拉通Underlay上的传输。到了DC的Edge Router这里，SR设计了BGP-EPE（BGP Egress Peer Engineering，draft-ietf-spring-segment-routing-central-epe-07）的机制，用于优化DC多出口的BGP选路。

如果实现了“端到端SR”，再结合SDN控制器开放出来的北向接口，应用即可主动地规划路径，一些厂商也为此描绘出了“应用驱动网络”的美好愿景。

SR向数据中心的推动，实际上是Underlay对于Overlay的反击。不过，数据中心的网络结构非常规整，网络半径通常都小于7跳，带宽的资源也相对充裕，因此SR做路径规划的优势并不明显。如果是为了调度Elephant Flow，将SR引入物理网络未免有些小题大做，如果是为了做服务链，明显也是在边缘用OpenFlow更适合一些。而TI-LFA所提供的保护能力，也不是特别符合Leaf-Spine“设备热插拔，多路ECMP”的设计哲学。“应用驱动网络”倒是个不错的概念，但是实际上与圈子里一直在提的“Intent Based Networking”也并没有什么本质的区别。

而且，数据中心仍然处于向VxLAN演进的前期阶段，SR想渗透进数据中心，目前来看并不是一个很好的时间点。随着SDWAN的流行，企业入云的场景也开始更多地开始使用VxLAN来做Internet OTT。“端到端SR”还远，“端到端VxLAN”倒是已经近在眼前了。