书籍来源：《SRv6网络编程：开启IP网络新时代》
这本书已经出了很多年了，但多年之后因为工作需要再来读一遍，除了温习之外，发现自己学到了更多的知识。一边学习一边整理读书笔记，并与大家分享，侵权即删，谢谢支持！
附上汇总贴：SRv6网络编程自学系列 | 汇总_COCOgsta的博客-CSDN博客
SRv6 Policy利用Segment Routing的源路由机制，通过在头节点封装一个有序的指令列表来指导报文穿越网络。
通过在SRH中封装一系列的SRv6 Segment ID，可以显式地指导报文按照规划的路径转发，实现对转发路径端到端的细粒度控制。
为了实现SR-TE，业界引入了SR Policy的框架。SR Policy支持描述SR-MPLS和SRv6的业务路径策略。
4.4.1 SRv6 Policy模型
如图4-21所示，SRv6 Policy模型包含如下要素。
Key值：SRv6 Policy使用以下三元组作为Key，全局唯一标识一个SRv6 Policy。
- Headend（头节点）：标识SRv6 Policy的头节点。
- Color（颜色）：标识指定头节点和目的节点的不同SRv6 Policy，可与一系列业务属性相关联。
- Endpoint（目的节点）：标识SRv6 Policy的目的地址。
在头节点上可以通过<Color,Endpoint>来引导流量进入SRv6 Policy。
存在多个Candidate Path时， SRv6Policy选择优先级最高的Candidate Path作为主路径。Candidate Path是通过BGP SRv6 Policy/PCEP等协议向头节点发送SRv6 Policy可选路径的基础单元。
<Protocol-origin,Originator,Discriminator>是在SRv6 Policy内部唯一标识一条Candidate Path的标识。
Segment List标识通过SRv6 Policy向Endpoint发送流量的源路由路径。一个Candidate Path可以关联多个Segment List，通过Segment List附带的Weight（权重）属性来控制流量在多个SR路径中的负载比例。
图4-21 SRv6 Policy模型
Binding SID也是Segment Routing的基础指令，它用于标识整个Candidate Path，提供隧道连接、流量引导等功能。
4.4.2 SRv6 Policy算路
SRv6 Policy可以通过多种方式生成Candidate Path，主要包括静态指定路径、头节点算路和控制器算路。不同方式生成的Candidate Path可以通过Protocol-origin和Originator字段来区分。
- 静态指定路径
静态指定路径是指通过CLI/NETCONF等方式人工规划，手动配置SRv6 Policy。如图4-22所示，静态配置显式路径（A4::45,A7::1,A6::1），并在SRv6 Policy中引用该显式路径。
图4-22 静态指定路径
静态配置路径的方式无法自动响应网络拓扑的变化，当指定的链路或节点发生故障的时候，无法触发SRv6 Policy重路由，那会导致流量持续中断。
- 头节点算路
如图4-23所示，首先头节点利用IGP携带的TE信息和IGP链路状态信息组成TEDB，然后基于CSPF算法，按照带宽、时延、SRLG和不相交路径等约束计算满足条件的路径，并安装相应的SRv6 Policy指导转发。
图4-23 头节点算路
头节点算路有以下限制：只能计算单个IGP域的路径，无法支持跨域的路径计算；不支持预留带宽算路。
- 控制器算路
如图4-24所示，控制器通过BGP-LS等收集网络拓扑、TE信息以及SRv6信息，并根据业务需求集中计算路径，然后通过BGP/PCEP等协议将SRv6 Policy下发到头节点。
图4-24 控制器算路
4.4.3 SRv6 Policy引流
将SRv6 Policy部署在头节点之后，还需要完成引流工作，将流量引导到SRv6 Policy中。目前有Binding SID和Color匹配这两大类引流方式。
- Binding SID引流
如图4-25所示，上游节点向节点A发送了一个报文，报文目的地址为B1::100。节点A收到该报文，发现报文的目的地址是本地SRv6 Policy的Binding SID。节点A处理Binding SID，具体流程如下。
① 将原始报文的SRH的SL值减1，指向下一个SID。
② 为报文封装一个新的IPv6报文头，目的地址为对应SRv6 Policy的第一个SID B3::4，源地址为本地的一个接口地址。
③ 然后封装SRH，携带该Binding SID对应的SRv6 Policy的Segment List。
④ 更新对应的其他字段，然后查表转发报文。
通过使用Binding SID可以引入SRv6 Policy的流量，这种方式一般常用在隧道拼接、跨域路径拼接等场景，可以很好地减小SRv6 SID栈深。
图4-25 Binding SID引流
- Color引流
Color是SRv6 Policy非常重要的属性，它是业务和隧道的锚点。通过匹配业务和SRv6 Policy的Color，就能实现自动引流。
如图4-27所示，通过Color进行引流的具体流程介绍如下。
① 控制器通过BGP或其他方式下发SRv6 Policy。
② 节点E通过路由策略设置路由的Color扩展团体属性值为123，并在发布路由时携带该属性。
③ 节点A收到路由以后，会进行路由迭代。使用BGP路由的原始下一跳匹配SRv6Policy的Endpoint，使用BGP路由的Color属性匹配SRv6 Policy的Color，这样一条BGP路由就能通过SRv6 Policy的Key值<Color, Endpoint>匹配到一个SRv6Policy。
图4-27 Color引流
通过以上方法，当流量到达节点A时，根据目的地址查询路由，得到隧道的出接口为SRv6 Policy的隧道接口，然后封装SRv6报文并转发，实现Color自动引流到SRv6 Policy。
这种引流模式一般可以通过路由策略控制BGP路由携带的Color值，这叫作着色。着色策略十分灵活，可以根据需求修改尾节点、头节点甚至RR反射器的Color的值。
- DSCP引流
除了Binding SID引流和Color引流，还可以通过IP报文头中封装的DSCP值来引流，这种方式可以对命中同一个路由但不同来源的业务进一步细分。例如，可以在头节点将多个SRv6 Policy组成一个Group（组），并在Group内指定每个SRv6 Policy和DSCP值的映射关系，然后将业务绑定到指定的Group。
在一些场景下希望结合以上两种引流方式，可以为Group引入Color，将Group的标识也定义为<Color,Endpoint>。通过引流策略指定，一条业务路由根据下一跳和Color属性不再去匹配一个SRv6 Policy，而是匹配一个Group。
4.4.4 SRv6 Policy数据转发
下面以L3VPNv4为例，介绍SRv6 Policy的数据转发过程。具体如图4-28所示。
① 控制器向头节点PE1下发SRv6 Policy,Color为123,Endpoint为PE2的地址2001:db8::1，只有一个Candidate Path，且Candidate Path也只包含一个Segment List <2::1,3::1,4::1>。
② 尾节点PE2向PE1发布BGP VPNv4路由10.2.2.2/32,BGP路由的下一跳是PE2的地址2001:db8::1/128,Color为123。
③ PE1在接收到BGP路由以后，利用路由的Color和下一跳迭代到SRv6 Policy。
④ PE1接收到CE1发送的普通单播报文后，查找VPN实例路由表，该路由迭代到了一个SRv6 Policy。PE1为报文插入SRH信息，封装SRv6 Policy的Segment List，同时封装IPv6报文头信息，并查表转发。
⑤ P1和P2节点根据SRH信息逐跳转发。
⑥ 报文到达PE2之后，PE2使用报文的IPv6目的地址4::1查找本地SID表，命中了End SID，所以PE2将报文的SL值减1，将IPv6 DA更新为VPN SID 4::100。
⑦ PE2使用VPN SID 4::100查找本地SID表，命中了End.DT4 SID, PE2执行End.DT4 SID的指令，解封装报文，去掉SRH信息和IPv6报文头，使用内层报文的目的地址查找VPN SID 4::100对应的VPN实例路由表，然后将报文转发给CE2。
图4-28 SRv6 Policy的数据转发
4.4.5 SRv6 Policy故障检测
下面介绍在发生故障时SRv6Policy的故障检测机制。
- SBFD for SRv6 Policy
SRv6 Policy故障检测需要依靠其他手段，例如通过SBFD快速检测故障并切换到备份路径。
SBFD for SRv6 Policy的检测过程如图4-29所示。
图4-29 SBFD for SRv6 Policy的检测过程
① 头节点PE1使能SBFD检测SRv6 Policy，并配置SBFD的目的地址和描述符。
② PE1对外发送SBFD报文，SBFD报文封装SRv6 Policy对应的SID栈。
③ 尾节点PE2收到SBFD报文后，通过IPv6链路，按照最短路径发送SBFD应答报文。
④ PE1如果收到SBFD应答报文，则认为SRv6 Policy的Segment List正常，否则会认为Segment List发生故障。如果一个候选路径下所有Segment List都发生故障，则SBFD触发切换候选路径。
- 头节点故障感知
通过此功能，头节点能够在Segment List的路径发生故障时，触发设备将Segment List置为Down状态，进而触发SRv6 Policy内部切换路径或触发业务切换。
头节点故障感知功能的主要实现原理是要求头节点能够收集网络的拓扑信息，然后根据Segment List中的SRv6 SID在拓扑中是否存在及路由是否可达，来校验Segment List是否有效。
只要Segment List中有一个SRv6 SID在拓扑中不存在或者路由不可达，设备就将Segment List的状态置为Down，并删除Segment List表项。
当Segment List发生故障时，设备根据SRv6 Policy及Candidate Path的情况进行如下处理。
- 如果SRv6 Policy优选的Candidate Path有多个Segment List进行负载分担，其中一个Segment List发生故障，将发生故障的Segment List从负载分担列表中删除，将流量分担到其他的Segment List。
- 如果SRv6 Policy优选的Candidate Path中所有的Segment List都发生故障，SRv6 Policy有备Candidate Path，则将流量切换到备Candidate Path。
- 如果SRv6 Policy下主备Candidate Path都发生故障，则通告SRv6 Policy状态为Down，触发业务切换。
在部署了Binding SID的场景中不能配置头节点故障感知功能。
4.4.6 SRv6 Policy路径切换
当 SRv6 Policy 的所有 Candidate Path 和Segment List都发生故障时，需要进行SRv6 Policy的保护倒换。
目前在VPN双归场景下，如果一个VPN节点发生故障，所有到达该节点的SRv6Policy都会发生故障，此时需要切换到指向另一个VPN节点的SRv6 Policy。
如图4-30和图4-31所示，SRv6 Policy1的Headend是PE1,Endpoint是 PE2。另外SRv6 Policy2的 Headend 是 PE1,Endpoint 是 PE3。SRv6 Policy1和SRv6Policy2可以形成VPN FRR，即PE2和PE3分别互为VPN备份节点。
SRv6 Policy1的主路径和备份路径之间部署了HSB保护。Segment List1指定的路径包含P1、P2、PE2的End SID，并且节点上部署了TI-LFA等保护机制。
图4-30 SRv6 Policy路径切换
图4-31 SRv6 Policy SID栈信息
在图4-30中，相关故障切换过程如下。
① 当P1和P2之间的链路发生故障时，P1、P2上的TI-LFA局部保护生效。SBFD联动将Segment List1置为Down状态，节点切换到SRv6 Policy1的负载分担路径Segment List2。
② 当P2发生故障且局部保护未生效时，PE1通过SBFD感知到P2发生故障，将Segment List1置为Down状态，SRv6 Policy1切换到备份路径Segment List2。
③ 当PE2发生故障时，通过SBFD可以探测到SRv6 Policy1的所有Candidate Path都不可用，将SRv6 Policy1置为Down状态，同时触发VPN FRR切换到SRv6 Policy2。