SR Policy

SR Policy解析

本文是基于Segment Routing详解（第二卷） 流量工程中的第二章 SR Policy所做的学习向记录性文章，如有不对，请多指正。

关键词：三要素（头端，颜色，端点）；候选路径（动态路径、显式路径）；BSID（Binding-SID）

2.1 简介

Segment Routing使头端节点可以通过在业务流的数据包上压入有序的Segment列表，引导业务流量沿着网络中的任意路径进行转发。数据包在Segment列表中已经携带了每条流的状态，中间节点无需再对每条流进行状态相关操作。

简单来说：头端节点编排好了流的路径，减轻了后续中间节点的工作。

SR-TE解决方案的核心概念是“SR Policy”。SR Policy负责流量工程解决方案的两个基本操作：

• 表示网络中的特定路径，这通常不同于IGP计算的最短路径；
• 将流量引导至特定路径。

需要注意的是SR Policy不是“隧道”，以下是设计者不想Segment Routing继承的几个问题：

一、在头端预先配置去往特定节点的路径（具有特定SLA或者是经由特定的路径）；

二、引流造成性能下降；

三、把隧道作为接口处理导致的可扩展性限制；

四、把自动路由（Autoroute）作为单一的引流机制。

以下通过四个示例去介绍SR Policy的一些关键特性：

• 第一个示例说明显式路径的概念；
• 第二个示例介绍显示路径的验证和选择的概念；
• 第三个示例介绍具有最小累积度量的动态路径的概念；
• 第四个示例通过为动态路径加上约束条件，对动态路径的概念进行扩展。

2.1.1 SR Policy的显式候选路径

​ 假设操作员想把节点1去往节点4的部分流量引导至路径1→7→6→8→5→4，那它可以将这条路径表示为<16008,24085,16004>：去往节点8的最短路径（节点8的Prefix-SID），从节点8到节点5的邻接（Adj-SID），去往节点4的最短路径（节点4的Prefix-SID）。

​ 如何定义“显式”，由操作员来表示的Segment列表就称之为”显式“的，头端路由器被显式地告知需要使用的原路由路径，它只需要简单地接收并使用Segment列表。

​ 类比一下路由，这就是操作员写下的静态路由，头端不知道其中的意图，只知道匹配+转发。

节点1可以配置如下SR Policy：

我们可以看到，SR Policy由三元组标识：生成SR Policy的 头端、颜色和端点 （后续在2.2会详细介绍）。这里我们着重看看颜色，在现阶段，我们可以比较容易地看出颜色是用来区分多条SR Policy的方式。节点1需要把业务流1引导到“蓝色”SR Policy，而需要把业务流2引导到“橙色”SR Policy。事实上，除了区分作用，它还承担着引流的关键作用，具体来说就是通过对业务路由进行着色处理，把流量自动引导至适当的SR Policy（也就是目的地为节点4且着色为“橙色”的流量将会被引导至去往节点4的“橙色”SR Policy）。（自动引流是SR-TE解决方案的一个基本组件，后续会有更详细的解释~~（但不是在这一章节）~~）。

其实对于显式路径，最简单的介绍也就是以上这些了，但我们需要注意的是颜色（Color）这个属性其实并不是实实在在的单词，而是数字。例如我们提到的“蓝色”，对应的属性可能就是 Color：10。

从这个基本的特性，我们已经可以看出SR Policy相比于RSVP-TE的好处：RSVP-TE需要在整个网络中为每条业务流创建状态，而SR Policy唯一的状态在头端已经处理。

在第一个示例当中，我们只有一条显式候选路径，每条显式候选路径由一个显式Segment列表予以指定。

在下面的示例中，我们将扩展SR Policy的概念：首先为每条SR Policy引入多条候选路径，然后引入动态候选路径的概念。

2.1.2 路径验证与选择

还是上面提到的两条路径<16008,24085,16004>和<16003,24034>，如果我们优选第一条候选路径，那我们可以分别给两条路设置偏好值，更高的偏好值代表更优选的路径，如下图所示：

在更高偏好值的候选路径能正常通信的时候，其他候选路径都是不活动的，而活动的候选路径也被称为“活动路径”（(⊙o⊙)…）。多条有效候选路径具有相同的偏好值时，则根据16章介绍的仲裁规则来选择一条路径（这里我避免自己日后拖更，拖到不知道什么时候，先简单写一下吧：

仲裁规则以如下顺序进行评估：

1. 优选高的协议起源值（协议起源：标识发起候选路径或者发出候选路径信令的组件或协议的数值——建议值：PCEP（10）；BGP SR-TE（20）；配置（30））；
2. 优选现有的已安装路径；
3. 优选低的发起节点值（发起者：二元组<自治域号，节点地址>）；
4. 优选高的区分符值。（区分符：用于区分具有相同协议起源和发起节点的多条候选路径的数值）。

每当头端①学到SR Policy新的候选路径②活动路径被删除③现有候选路径被更改或者有效性发生变化时，都会重新执行活动路径的选择过程。

某个时刻，网络发生故障，例如节点8和节点5之间的链路失效，如图2-4所示，首先TI-LFA可以确保经由此链路的业务流快速地恢复（详情见第八章…这个没办法提前更，说起来小复杂）。接下来头端节点会验证Segment列表的有效性，把含有失效的SID的路径先ban掉，然后重新选择有效候选路径。

故障链路后，偏好值为100的候选路径再次变为有效。头端节点就会再次进行活动路径的选路工作，恢复到原来的优选路径上。

2.1.3 低延迟动态候选路径

​ 操作员通常倾向于简单地表达意图，并希望头端将某个意图转换成Segment列表，这被称之为“动态”候选路径。头端通过动态地将意图转换成Segment列表，按需更新列表的方式可以动态地响应任意的网络变化，持续的满足操作员所设下的意图。

​ 怎么定义 意图 ？意图就是：

1. ​ 可加性度量（IGP度量，TE度量或链路延迟）的最小化；
2. ​ 一组约束条件（例如避免/包含特定IP地址、SRLG、TE亲和属性等）。

​ 每个节点都利用链路状态IGP或者BGP-LS分发本地信息，给头端完成意图提供了相关的参数。除了众所周知的拓扑信息，链路状态通告还可以包含SR元素（SRGB、SID等）和其他链路属性（延迟、丢包、SRLG、亲和属性）。

​ 头部节点接受所有的信息，将其保存在本地SR-TE数据库，此SR-TE数据库包含本地IGP区域的完整拓扑试图，其中也包括SR-TE信息，即包含了头端节点用于计算满足意图的网络路径所需的全部信息。

​ 这里需要提到的是头端使用“SR原生”算法将动态路径的“意图”转换成Segment列表。术语“SR原生”强调的是该算法已经针对SR进行了优化，它最大限度的利用了ECMP，并最小化Segment列表的长度。

下图就是按照链路延迟测量值所得的链路，节点1到节点4，走1→2→3→4的路径，累积延迟12+11+7=30。

假设操作员使用“绿色”来表示低延迟，则上面分析的SR Policy可以总结如下：

2.1.4 避免特定链路的动态候选路径

​ 现在假设操作员需要从节点1去往节点4的“紫色”SR Policy，这条SR Policy最小化累积IGP度量，并且避免使用具有亲和颜色“红色”的链路。

​ 链路亲和颜色是一组可以分配给链路的属性。网络中的每条链路可以没有颜色，也可以有一种或者多种颜色。这些亲和颜色随链路在IGP（和BGP-LS）中进行通告。跟之前我们提到的颜色一样，这里的亲和颜色也不是“颜色”，而是位图（bitmap）中的一个位。如果链路具有给定的亲和颜色，则位图中与此颜色对应的位被置位。

如上图所示，节点7到节点6的链路被标记为红色，按照SR Policy的要求，节点1会从SR-TE数据库的拓扑模型中剪除不满足“避免”红色“链路”约束条件的链路，基于修剪后的拓扑计算去往节点4的IGP的最短路径。由此得到的路径是1→2→3→6→5→4。节点1将路径编码为最优的Segment列表<16003,16004>。

此条SR Policy总结如下：

• SR Policy（节点1，“紫色”，节点4）

  -候选路径：

  1. 动态：最小化IGP度量并且排除“红色”链路

     →Segment列表<16003,16004>

2.2 SR Policy模型

SR Policy由3个元素的三元组唯一标识：

• 头端：SR Policy生成/实现的地方（节点）；
• 颜色：颜色是任意的32位数值，用于区分同一头端和端点对之间的多条SR Policy。颜色表示意图，对自动引流功能很关键；
• 端点：SR的目的地，由IPv4或者IPv6地址予以指定。

在给定的头端节点上，SR Policy则由颜色和端点二元组完全标识。而唯一标识也意味着，每条SR Policy三元组是唯一存在的。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-hp2OLAcJ-1661736978642)(https://blog-1301271205.cos.ap-guangzhou.myqcloud.com/微信图片_20220825143246.jpg)]

简单起见，这里的候选路径与Segment列表都是一一对应的，事实上每条候选路径可以具有多个Segment列表，此路径的流量会根据每个Segment列表的权重比例进行对应的负载均衡。

2.2.1 Segment列表

​ 本小节内容不多，总结起来就是：Segment可以通过两种方式指定：①准确地给出具体的标签值；②提供Segment描述符（例如IP地址1.1.1.4），由头部节点将其转换成对应的标签值。

​ 需要注意的是，表示为MPLS标签值的Segment只有在位于Segment列表首个位置时才会被检查，以用于得到接口和下一跳。（我们一般将显式Segment表示为MPLS标签值，原因是：①显式Segment已经代表了我们操作者的意图，我们不希望头端再一次对其介入；②显式Segment属于远端域，头部无法验证Segment，所以我们需要使用MPLS标签值来避免有效性检查。

混合使用标签值和描述符在应用上是非常美妙的，用标签值引导流量度过最拥堵的路段，在栈底用节点Segment表明目的地，达到真正的引导+自动算路的结合的过程。

2.2.2 候选路径

​ SR Policy的候选路径，也是总结性的话语提一下就行了：

​ 如图所示，分为动态路径和显式路径。需要提到的是，每条候选路径都可以通过不同的方式学到：配置，NETCONF，PCEP和BGP-TE，最可能的应用场景是：SR Policy的所有候选路径都通过相同的机制（例如配置）学到。作一个小分享，很多互联网大厂都直接写显式路径来编排业务流量，几乎不用动态路径。

2.3 BSID

BSID（Binding-SID，绑定SID）对SR-TE而言非常重要。

BSID与SR Policy绑定，BSID提供所绑定SR Policy的关键字。在给定的头端上，任意时刻一个BSID都会绑定到唯一一条的SR Policy。BSID所代表的指令是：将带标签的数据包引导至与他相关联的SR Policy。

简单来说，任何到达头端且顶层标签是BSID的数据包被引导至与BSID相关联的SR Policy，头部弹出BSID标签，在数据包报头上压入与SR Policy相关的标签栈，并根据Segment列表的第一个标签转发数据包。详情看下图及解析。

看图基本把整个流程介绍的比较完整了，所以也没什么多需要交代的了。

2.4 SR Policy配置

如果大家有做过配置的话，大概可以自行通过我们上述讲过的知识点来看懂配置相关内容，这里就不再赘述，上图。

SR Policy的显式候选路径

路径验证和选择（显式路径带Preference）

低延迟动态候选路径

动态候选路径（带亲和属性）

小小吐槽一句，亲和属性不亲和。

2.5小结

模型、路径、BSID引流、配置，大致如上内容，至此第二章完结。