Segment Routing 在大规模数据中的应用(上）

作者简介：史梦晨

在写《BGP在大规模数据中心中的应用》里当时就有了讨论Segment Routing(SR)的想法，因为当时我还在参与MPLS+SR的白皮书测试，得到了不少真实的反馈，也粗略阅读了这篇今天要介绍的RFC: BGP-Prefix Segment in large-scale data centers (draft-ietf-spring-segment-routing-msdc-11) ，虽说这篇RFC而且还处于草案，但还是分享一下里面的精华内容。拖了大半年的稿，draft更新了2版了。。。（本人只是RFC的搬运工，轻拍）

首先Segment Routing (SR)的介绍不必多说，具体介绍可以一些白皮书或者参考站内其他文章如：Segment Routing将助力SDN重塑新型网络, 但是目前大多数对于SR的讨论都是基于广域网的。大规模数据中心的五大需求以及CLOS架构也在之前的文章中介绍过了。那么我们就直接进入正题。本文没有一行行的翻译RFC，加入了一些我自己的理解和排序。

RFC作者：S. Previdi、Cisco Systems, Inc.、G. Dawra、LinkedIn、E. Aries、Juniper Networks、P. Lapukhov、Facebook、November 29, 2018

1.参考设计

本文讨论的拓扑是基于之前文章介绍的5级CLOS架构，为了简化理解使用以下拓扑：

• 4个Tier 1设备
• 从node1到node12是4条path，并且经过所有的Tier1 设备
• node1到node2是2条path,并且不经过tier-1
• 每个Tier-3都有自己的AS（4-byte AS或者复用2-byte AS)
• Tier-1的node 5,6,7,8在一个AS，Tier-2的node 3,4用一个AS,9,10用另一个
• 没有说明的情况下都用eBGP peer
• node x的loopback为192.0.2.x/32

2.在大规模数据中心里存在问题

在RFC7938提出的方案里，仍然有一些性能和可靠性的问题我们将在这篇RFC设计中去解决

• 问题1：ECMP通常是基于流的，这就意味着大象流（比较大的，时间长的流）将会影响到老鼠流（较小的存在时间短的流）的性能。换句话说就是基于流的ECMP在流的存活时间分布不均匀的时候效率比较低下。
• 问题2: 使用了ECMP的最短路径算法是无法感知到网络失衡的。如果网络的对称被打破，比如上节图中Node 5和Node 9之间的链路失效，节点1和节点2是无法感知，因为3还有其他tier 1 节点可以进行转发。1和2将会持续发送相等的流去3和4，造成网络热区（链路3-6）
• 问题3：网络中有多条等价平行路径的时候，识别和重现故障就成为一件不是很容易的事情。为了排障，我们往往需要重现故障（reproduction of a failure)。流量从host A到host B每次都会从不同的ECMP路径走的话，重现故障就会十分困难。 这种复杂性和ECMP path的数量是以线性关系增长的，当网络规模扩大以后尤其明显。

在后面的章节中会来演示如何用Segment Routing来处理这些问题。接下来我们来看如何在DC中应用基于MPLS的数据平面的SR。

3.在MPLS数据平面中应用Segment Routing

3.1 BGP Prefix Segment(BGP-Prefix-SID)

BGP Prefix Segment在这篇RFC中定义的，其实就是Gbobal SID。不用铺展开来介绍，在本文里的设计里，所有节点使用同样的SRGB(SR全局块，[1600，23999])。这里为了展示，在MPLS平面中，192.0.2.x/32的label-index就是X, BGP-Prefix-SID 就是16000+X。

3.2 eBGP Labeled Unicast(RFC8277)

• 图1和RFC7938的设计的不同之处在于引入了以下设计
• 每个节点都和邻居们使用BGP-LU扩展建立eBGP session
• Tier-2和Tier-1使用MPLS作为转发平面
• Tier-3要么使用IP2MPLS（如果host发送IP流量或者MPLS2MPLS（host发送MPLS封装流量）

在图2中我们专注于从Server A到Server Z的一个Path，1-4-7-10-11，为接下来的章节做准备:

3.2.1 控制平面

1.Node11 宣告192.0.2.11/32 prefix并使用index11生成一个BGP-Prefix-SID，然后发送一个eBGP8277的update给Node10:
. IP Prefix: 192.0.2.11/32
. Label: Implicit-Null
. Next-hop: Node11’s interface address on the link to Node10
. AS Path: {11}
. BGP-Prefix-SID: Label-Index 11

2.Node 10收到更新以后，由于开启了SR,所以会使用他的SRGB加上收到的Label-index分配一个标签(16000+11 = 16011)放到NLRI里。Implicit-Null的标签让他知道他是倒数第二跳，在转发流量给11之前需要弹出标签。

3.Node 10发送以下的更新给Node7:
. IP Prefix: 192.0.2.11/32
. Label: 16011
. Next-hop: Node10’s interface address on the link to Node7
. AS Path: {10, 11}
. BGP-Prefix-SID: Label-Index 11

4.Node 7 收到更新以后，生成本地标签16011到NLRI并使用这个标签作为出口标签。
5.Node 7 发送以下更新给Node 4:

. IP Prefix: 192.0.2.11/32
. Label: 16011
. Next-hop: Node7’s interface address on the link to Node4
. AS Path: {7, 10, 11}
. BGP-Prefix-SID: Label-Index 11

6.Node 4 重复4，5步骤
. IP Prefix: 192.0.2.11/32
. Label: 16011
. Next-hop: Node4’s interface address on the link to Node1
. AS Path: {4, 7, 10, 11}
. BGP-Prefix-SID: Label-Index 11

7.Node 1 重复步骤4
到这里，控制平面对于192.0.2.11/32的标签就建立完成。

3.2.2 数据平面

根据上面控制平面， 我们在每个节点上建立了IP/MPLS转发表：

看到这里帅气的读者可能已经在脑海中形成了一副经典的报文转发图，所以我就不画了。
同时还有些特别帅气的读者发现了这些规律：

• Segment ID是重用了MPLS Label
• SR不需要使用LDP等标签分发协议
• 这里标签在中间节点的时候没有SWAP的动作?

各位帅气的读者，这里只有第3点是不对的。不要紧！已经很好了。因为在SR里，还是需要SWAP的，但是换成了一个一样的标签而已，而这个动作在SR里面叫做CONTINUE（rfc8402）。顺带一提，MPLS里的POP，SR里叫NEXT。

这里关于如何建立SR转发和各节点如何转发就已经说完了。后续的章节将讨论的一些不同的部署方案，以及除了解决了在第2章提到的问题以外，在大规模数据中心中部署SR带来的额外好处。