书籍来源：《SRv6：可编程网络技术原理与实践》
2022年刚出的书，业界的众多大佬合力，将SRv6最前沿的技术分享了出来。一边学习一边整理读书笔记，并与大家分享，侵权即删，谢谢支持！
附上汇总贴：SRv6网络编程自学系列之二 | 汇总_COCOgsta的博客-CSDN博客
流量工程是在路由协议基础上为满足特定目标实现的网络局部优化。IGP路由协议的设计准则是“路径优先”，通常以SPF算法确定路由，不考虑带宽利用率、时延等因素。TE技术在特定目标（或指定约束）条件下的网络优化可分为以下两个维度。
- 面向流量（Traffic-Oriented）：其优化目标在于提升数据流的服务质量（QoS），通常包括丢包最小化（Minimization of Packet Loss）、时延最小化（Minimization of Delay）、通量最大化（Maximization of Throughput）、SLA提升等。
- 面向资源（Resource-Oriented）：其优化目标在于网络资源的有效使用，特别是带宽资源的有效管理。
为满足特定目标而使流量选择指定路径是TE的基本手段。策略路由（Policy Based Routing，PBR）、MPLS TE等都是常见的TE手段。MPLS TE基于叠加（Overlay）模型在物理网络拓扑上建立虚拟路径，可较好地实现上述面向流量与面向资源的优化目标：
- 通过MPLS TE，网络管理员可以较为精准地控制流量路径，避开拥塞路径，实现网络带宽资源的有效管理；
- 建立LSP过程中，MPLS TE可以预留资源，保证数据流的QoS；
- MPLS TE还可实现路径备份（Path Backup）与FRR，在链路故障时即时切换，从而保障SLA。
如第1.2.1节所分析，MPLS TE采用RSVP-TE/CR-LDP作为信令，导致路径状态N²等问题，其扩展性受到极大挑战。作为SR技术的一种重要应用，SR-TE则较好地解决了MPLS TE的相应问题。SR-TE技术基于SR源路由机制，通过在报头中携带有序指令列表的方式构成显式流量路径。这些指令并非面向数据流，而是面向节点与链路，因而网络设备只需维护有限的节点与链路状态，不会出现MPLS TE的扩展性问题。
SRv6-TE是基于SRv6的SR-TE。基于SRv6灵活编程特性，SRv6-TE可实现更加灵活的路径选择和业务提供能力。
6.1.1 SRv6-TE简介
如第2章介绍，典型的SR架构是一种集中式控制与分布式优化结合的网络架构，通常采用混合式控制平面。一种以混合式控制平面为基础的SR-TE功能架构如图6-1所示。
SR-TE功能架构主要包含控制器、网络设备（网络节点）等。控制器包含集中算路组件（Component）、信息采集组件以及信令组件等，网络设备则包含信令组件、信息发布组件、信息上报组件、IGP组件以及报文转发组件等。
- SR-TE控制器集中算路组件
集中算路组件是SR-TE控制器的核心组件，通常情况下，该组件响应网络设备的路径计算请求，基于全局TEDB，通过CSPF算法计算满足指定约束条件的路径。采用控制器集中算路的方式，一方面可避免分布式TE场景下网络设备的算力局限，另一方面可以实现端到端跨域算路（从而实现跨域TE）。
集中算路组件基于全局TEDB进行路径计算。TEDB包含一个/多个AS的IGP拓扑信息（节点、链路、IGP度量等）、AS域间信息、TE链路属性（TE度量、链路时延度量、SRLG、链路属性、亲和属性等）、SR信息（Prefix-SID、Adj-SID等）以及SR Policy信息（Headend、Endpoint、Color、SID列表等）等。
CSPF算法是一种改进的SPF算法。该算法在计算某流量的TE路径时，需将指定的约束条件纳入其中。CSPF算法的输入包括TEDB信息以及用户自定义信息（如带宽需求、最大跳转数、管理策略需求等），输出则是相应路径。CSPF算法首先根据约束条件（如带宽、亲和属性、SRLG和管理策略需求等）对网络拓扑进行“裁剪”，然后对“裁剪”后的网络拓扑基于SPF算法进行TE路径计算。理论上，网络管理员可以自行开发/选择其他算法，但CSPF算法作为一种在线计算方法，可在网络拓扑变化情况下及时响应并提供相应TE路径，仍然是目前大多数控制器采用的主要算法。
- SR-TE控制器信息采集组件
TEDB中的信息独立于协议。SR-TE控制器为建立全局TEDB，通过信息采集组件将网络拓扑、TE以及SR信息等从网络设备中收集并注入TEDB。信息采集组件主要通过BGP-LS等协议与网络设备交互。
- 信令组件
信令组件分为SR-TE控制器的信令组件和网络设备的信令组件，二者基于PCEP或BGP SR Policy协议交互，完成SR-TE路径计算请求与结果下发的过程。
步骤1 网络设备信令组件向SR-TE控制器发送TE路径计算请求。
步骤2 SR-TE控制器信令组件接收来自网络设备的路径计算请求，并将请求发送给集中算路组件。
步骤3 集中算路组件响应相应请求，计算TE路径，并将路径计算结果返回给SR-TE控制器信令组件。
步骤4 SR-TE控制器信令组件将路径计算结果发送给网络设备。
- 网络设备信息上报组件
信息上报组件与SR-TE控制器信息采集组件相互配合，完成SR-TE控制器全局TEDB的构建与信息更新。该组件通过BGP-LS等协议上报网络拓扑、TE以及SR信息等。
- 网络设备信息发布组件
网络设备信息发布组件主要用于获取/通告网络拓扑信息、TE信息以及SR等信息，并形成本地TEDB。相关信息的通告主要通过IS-IS/OSPF等协议扩展实现。
- IGP组件
IGP组件主要通过网络设备之间的IS-IS/OSPF协议交互完成网络拓扑、TE以及SR等信息的通告。
- 网络设备报文转发组件
报文转发组件基于SR的源路由机制对报文进行转发。在SR-TE中，由于头端节点已经在报文中显式指定了报文转发路径，网络设备的报文转发组件按照报文所携带路径信息与指令来处理/转发报文。
- 网络设备算路组件
在混合控制平面/分布式控制平面场景下，网络设备上也会存在算路组件（未在图6-1中画出）。这种组件可以根据本SR域的TEDB计算域内的SR-TE路径。其机理与SR-TE控制器集中算路组件一致，此处不再赘述。
SR-TE概念引入之前，以RSVP-TE为代表的“TE隧道”概念深入人心，然而，RSVP-TE技术一直未得到广泛的应用。除了众所周知的路径状态N²、跨域实现困难等问题外，RSVP-TE还存在以下问题：
- RSVP-TE本身不支持ECMP，必须在源和目的之间通过建立多条隧道的方式实现流量负载分担，配置复杂且影响其扩展性；
- 将隧道作为虚拟接口，不仅占用设备资源导致扩展性问题，而且实现方式较为复杂；
- 对新功能支持能力弱，如不支持灵活算法（Flex-Algo）、性能测量（Performance Measurement，PM）等新功能。
针对传统隧道技术的不足，思科公司于2017年提出了一套全新的SR-TE体系--SR Policy。SR Policy没有隧道接口的概念，本质上是Segment列表。SR Policy将用户/业务的需求转换为Segment列表，将Segment列表编程到网络边缘设备上，引导流量至Segment列表所对应的路径上，从而实现流量工程。为了满足网络自动运营/智能运营等需求，SR Policy还集成了性能测量、OAM、计数器和遥测等功能。
细心的读者会发现，本节标题为“SRv6-TE简介”，却一直在讲述与SR-TE相关问题。事实上，SR-MPLS与SRv6的主要区别在于数据平面，SRv6-TE作为SR-TE的一种形态，功能架构与SR-TE是一致的。下节所讲的SRv6 Policy模型同样适用于SR Policy。
6.1.2 SRv6 Policy模型
SRv6 Policy是实现SRv6网络编程的主要机制，它将BGP路由置于解决方案的核心，在隧道生成、流量引导等方面具有鲜明的特色。
一个典型的SRv6 Policy模型包含SRv6 Policy标识、候选路径（Candidate Path）及Segment列表等主要组成要素。SRv6 Policy模型示例如图6-2所示。
- SRv6 Policy标识
SRv6 Policy由<Headend, Color, Endpoint>三元组唯一标识，该标识全局有效。
- Headend：用来标识SRv6 Policy的头端节点，以IPv4或IPv6地址表示。Headend节点生成SRv6 Policy，还可以将流量导入SRv6 Policy。
- Color：用来在<Headend, Endpoint>二元组相同情况下标识不同的SRv6 Policy，可表示为32bit数值。Color是SRv6 Policy的重要属性，作为业务与隧道的锚点，通常与业务需求关联，可与低时延、大带宽等业务属性对应，也可代表SRv6 Policy的业务SLA。此外，Color还提供了一种将业务与SRv6 Policy相关的灵活机制，可以通过对业务路由着色（即在BGP扩展团体属性中携带Color）的方式自动生成SRv6 Policy并向SRv6 Policy自动引流。
- Endpoint：用来标识SRv6 Policy的目的地址，以IPv4地址或IPv6地址表示。
对于给定的Headend节点，该节点生成的所有SRv6 Policy的Headend节点均相同，可将此Headend节点上的所有SRv6 Policy通过<Color, Endpoint>标识，并可以通过<Color, Endpoint>来引导流量进入相应的SRv6 Policy。
为便于读写、简化配置，可以为SRv6 Policy定义别名（Symbolic Name）。SRv6 Policy的别名由可显示的（Printable）美国信息交换标准代码（American Standard Code for Information Interchange，ASCII）字符构成，用于指代SRv6 Policy。
- Candidate Path
Candidate Path代表将流量从相应SRv6 Policy的Headend节点传送到Endpoint的一种可能的路径。不同信令协议会下发不同的Candidate Path。从SR-TE控制器角度看，Candidate Path是基于BGP SRv6 Policy/PCEP等协议向Headend节点发送SRv6 Policy的基本单元。
一个SRv6 Policy可以关联多条Candidate Path，但必须有一个主路径（Active Path）。每个Candidate Path都有一个偏好值（Preference），用来标识Candidate Path的优先级，偏好值越高，则优先级越高。SRv6 Policy总是在多条Candidate Path中选择Preference最高的那条作为Active Path。
SRv6 Policy内部通过<Protocol-origin, Originator, Discriminator>唯一标识一条Candidate Path。
（1）Protocol-origin
Protocol-origin是一个8bit的数值，用来标识生成/下发Candidate Path的组件或信令协议。现阶段，在Headend节点生成Candidate Path的途径有“基于配置（Via Configuration）”“PCEP下发”和“BGP SRv6 Policy下发”3种。这3种方式对应的优先级（Priority）分别为30、20和10。在Candidate Path Preference相同的情况下，Protocol-origin可用来选择主路径（优选Protocol-origin中Priority最高的Candidate Path）。PCEP和BGP SRv6 Policy通常是SR-TE控制器下发Dynamic Candidate Path的方式。
（2）Originator
Originator与Protocol-origin方式相对应，用来标识生成Candidate Path的节点。Originator共160bit，标识为ASN:node-address。其中ASN为4byte的AS号，node-address表示128bit的IPv6地址（如果是IPv4地址，则被编码在低32bit）。Originator一般是Headend节点或控制器。根据Protocol-origin，Originator可标识不同的节点。
- 若Protocol-origin是“Via Configuration”，则Originator要么是Headend节点的ASN/node-address，要么是控制器的ASN/node-address。这种情况下，ASN与node-address缺省均为0.
- 若Protocol-origin是“PCEP"，则node-address就是PCEP控制器的IPv4/IPv6地址，ASN通常缺省设置为0。
- 若Protocol-origin是“BGP SRv6 Policy”，则Originator由Headend节点的BGP提供。
如果Candidate Path的Preference与Protocol Origin均相同，Originator则用于选择主路径（优选Originator值最低的Candidate Path）。
（3）Discriminator
Discriminator用于区分同一<Protocol-origin, Originator>下不同的Candidate Path。例如，如果SR-TE控制器通过PCEP发布属于同一SRv6 Policy的多个Candidate Path，则这些Candidate Path通过Discriminator来区分。
- 分段列表
分段列表（Segment List）是对SRv6 Policy转发路径编码的分段序列。一个Candidate Path可以关联多个Segment List。每个Segment List都有一个权重（Weight）属性，用来标识流量在该SID列表的负载比例。通过Weight控制流量在多个Segment List路径中的负载比例，从而实现非等价多路径（Unequal-Cost Multi-Path，UCMP）功能。
SRv6 Policy的多Segment List设计可以实现网络资源的动态弹性扩展，满足业务实时变化的需求。例如，某类业务需要将带宽从10Gbit/s增加到15Gbit/s，SRv6Poy可以在原有路径基础上再增加一条5Gbit/s带宽的路径。此外，基于权重的UCMP可以更方便地实现对网络资源的优化。如果某条Segment List路径的流量出现了过载，可以调整Segment List的权重以降低该路径的负载。
SRv6 Policy中还有一个重要概念：Binding SID（BSID）。如第2.3节所述，作为SR的基础指令、BSID可以起到减少SR报文封装的SID层数、隔离域内扰动/震荡等作用。具体到SRv6 Policy，BSID作为一个与SRv6 Policy绑定的本地SID，可标识一条Candidate Path，并提供隧道连接、流量引导等功能。SRv6 Policy的BSID对应Active Path，报文如果携带SRv6 Policy对应的BSID，则会被引导到对应的SRv6 Policy。从网络编程的角度，SRv6 Policy可以看作一个网络服务，BSID则可看作访问这个服务的接口。SRv6 Policy的这种“网络服务化”的设计理念使得网络可以通过BSID为业务提供服务接口，任何业务都可以调用该接口，而不需要关注系统内部实现的细节。
6.1.3 SRv6 Policy候选路径
一个SRv6 Policy至少关联一条Candidate Path，且必须有一个主路径。根据生成方式，SRv6 Policy的Candidate Path可分为显式候选路径（Explicit Candidate Path）和动态候选路径（Dynamic Candidate Path）两类。这两类路径可以安装在同一个SRv6 Policy中。
- 显式候选路径
Explicit Candidate Path的Protocol-origin对应“Via Configuration”。Explicit Candidate Path可以由网络管理员在Headend节点上通过CLI方式进行本地配置，Headend节点配置显式候选路径示例如图6-3所示，也可以由控制器通过NETCONF又一代模型（Yet Another Next Generation Model，YANG）等方式将配置下发给Headend节点生成（控制器下发显式候选路径示例如图6-4所示）。
配置SRv6 Policy Explicit Candidate Path时，需要配置Endpoint、Color以及Candidate Path的Preference和Segment List等参数。以图6-3为例，根据路径规划，需在Headend节点B1上基于Explicit Candidate Path配置一条SRv6 Policy。该Candidate Path必须经过节点B2到节点B5的链路、节点B5到节点B6的链路，并到达Endpoint节点B3。图6-3中，Endpoint节点B3的IPv6地址为B3::200，其End SID为节点B3::1；节点B2到节点B5的链路对应的End.X SID为B2::10；节点B5到节点B6的链路对应的End.X SID为B5::10。基于SRv6 Policy模型，配置流程描述如下。
（1）配置SRv6 Policy：Policy1
这个环节通常为SRv6 Policy配置别名、Color与Endpoint参数。此处，这条SRv6 Policy的别名为Policy1，Color配置为100，Endpoint配置为B3::200。由此，<100, B3::200>即可唯一标识这条SRv6 Policy。
（2）为Policy1配置Candidate Path
这个环节通常为Candidate Path配置Preference、BSID等参数。此处，由于只为Policy1配置了一条Candidate Path，Preference采用缺省值（100）。BSID配置为B1::100。配置的这条唯一的Candidate Path即Active Path。
（3）为Candidate Path配置Segment List
这个环节通常配置Segment List及其Weight。由于该条Candidate Path必须经过节点B2到节点B5的链路、节点B5到节点B6的链路，并到达Endpoint节点B3。因而此处的Segment List配置为<B2::10, B5::10, B3::1>。其中，B2::10为节点B2到节点B5的链路对应的End.X SID，B5::10为节点B5到节点B6的链路对应的End.X SID，B3::1为Endpoint节点B3的End.X SID。根据SRv6 Policy规定，Candidate Path的Segment List的最后一个Segment（Last Segment）必须是与Endpoint节点相关的SID。图6-3中，与Endpoint节点B3相关的SID，一个是节点B3的End SID（B3::1），一个是节点B6到节点B3链路对应的End.X SID（B6::10），比例中，选择B3::1作为Segment List的Last Segment。
每个Segment List都有对应的权重，以便在Candidate Path所关联的Segment List之间进行负载均衡。Weight缺省值为1，此处配置为100。
对于基于控制器配置Explicit Candidate Path的场景，首先需要控制器根据路径规划配置SRv6 Policy的YANG模型，然后由控制器通过NETCONF协议下发到Headend节点B1；节点B1则根据YANG模型生成SRv6 Policy及其对应的Candidate Path等。在节点B1上所达到的效果与在节点B1上通过CLI直接配置完全一致。
Explicit Candidate Path无法自动响应网络拓扑的变化，当Active Path中的链路或节点发生故障时，SRv6 Policy无法重路由，会导致流量中断。为保证网络可靠性，通常在实际部署中规划和配置两条不相交路径（Disjoint Path），并结合连通性检测等机制，实现路径故障时的主备路径切换。
- 动态候选路径
Dynamic Candidate Path可由Headend节点或SR-TE控制器根据TEDB及约束条件动态计算生成，生成方式有Headend节点计算生成、SR-TE控制器计算生成和ODN（On-Demand Next-Hop，按需下一跳）等。Dynamic Candidate Path在网络条件变化时会自动重算以适应网络变化。
（1）Headend节点计算生成Dynamic Candidate Path
这种方式通常用于IGP域内的Candidate Path计算。如第7.1节所述，Headend节点在本地有TEDB，可以基于相应算法（通常为CSPF算法），结合约束条件计算型生成Candidate Path。为了计算生成Dynamic Candidate Path，需在Headend节点进行相应配置。
以图6-5为例，在Headend的节点B1上需针对Endpoint节点B3生成一条最低时延的SRv6 Policy Dynamic Candidate Path。为此，在Headend所做配置具体如下。
- 配置SRv6 Policy：配置SRv6 Policy的Color（值为100）、Endpoint（节点B3地址，B3::200）和别名（Policy1）。<100, B3::200>可唯一标识Policy1。
- 为Policy1配置Dynamic Candidate Pah参数：配置Candidate Path Preference（值为100）、Candidate Path动态计算参数（如Dynamic path metric type latency，以时延为度量值基于CSPF算法生成Candidate Path）、BSID（此例中由Headend自动生成，不做配置）等。
Headend的节点B1通过CSPF算法，基于本地TEDB与约束条件生成如图6-5所示的一条Dynamic Candidate Path，其Segment List表示为<B2::10, B5::10, B3::1>。
Headend节点计算生成Dynamic Candidate Path的方式，在SR架构中属于分布式控制方式，具有非常高的扩展性。然而，Headend节点只有IGP域内的拓扑信息，无法获取跨域拓扑信息，无法支持跨域路径计算。此外，这种方式下，Headend节点无法获取中间节点的资源占用情况，不具备带宽预留等资源预留类路径计算能力。
（2）SR-TE控制器计算生成Dynamic Candidate Path
SR-TE控制器主要通过BGP-LS等协议收集网络拓扑、TE以及SRv6等信息，形成全局TEDB。
通常，SR-TE控制器计算生成Dynamic Candidate Path的动作由Headend节点触发。当Headend基于相应参数向SR-TE控制器提出算路请求后，SR-TE控制器将基于全局TEDB与约束条件，采用CSPF算法计算Candidate Path。SR-TE控制器通过PCEP/BGP SR Policy协议向Headend节点下发Dynamic Candidate Path。此种方式下生成的Dynamic Candidate Path，其Protocol-origin对应“PCEP”或“BGP SR Policy”。
为了由SR-TE控制器计算生成Dynimic Candidate Path，需在Headend节点进行相应配置。SR-TE控制器计算生成动态候选路径示例如图6-6所示。以图6-6为例，Headend节点B1上需由SR-TE控制器生成一条到达Endpoint节点B3的最低时延的SRv6 Policy Dynamic Candidate Path。为此，在Headend所做配置如下。
- 与SRv6 Policy相关参数：SRv6 Policy的Color（值为100）、Endpoint（节点B3地址，B3::200）和别名（Policy1）。<100, B3::200>可唯一标识Policy1。
- Policy1的Dynamic Candidate Path参数：Candidate Path Preference（值为100）、Candidate Path动态计算参数（如Dynamic path metric type latency，以时延为度量值基于CSPF算法生成Candidate Path）等。
SR-TE控制器响应节点B1的请求，计算生成了一条Dynamic Candidate Path，其Segment List表示为<B2::10, B5::10, B3::1>。
相对于Headend计算生成Dynamic Candidate Path的方式，SR-TE控制器可通过BGP-LS等协议获取全局的拓扑和TE等信息，从而可实现全局调优、资源预留和端到端跨域的SRv6 Policy路径计算。
（3）ODN方式生成Candidate Path
基于附带颜色（Color）属性的业务路由动态生成SR Policy的方式称为ODN。此处，Next-hop既是BGP业务路由中的Next-hop，也是SR Policy的Endpoint。基于ODN方式成的Candidate Path称为按需候选路径（On-Demand Candidate Path）。
ODN方案的核心是Color。BGP的Color属性是一个32it的数值，属于可传递（Transitive）、不透明（Opaque）等扩展属性，可附加在BGP路由上，影响路由决策。BGP通常对通告的业务路由进行着色（Coloring），以区分每条业务路由所代表的SLA。
该方案通过ODN模板（Path Template）中SR Policy的Color属性（可对应业务SLA）与BGP业务路由中颜色扩展属性（Color Extended Community）相匹配的方式，动态计算Candidate Path。
为了在Headend上通过ODN方式生成Candidate Path，需要在Headend节点进行相应配置。ODN方式生成候选路径示例如图6-7所示。以图6-7为例，Headend节点B1上需通过ODN方式生成一条到Endpoint节点B3的最低时延的SRv6 Policy Dynamic Candidate Path。为此，需在Headend配置ODN模板。
与ODN模板相关参数包括SRv6 Policy的Color（值为100）和Dynamic Candidate Path参数：Candidate Path Preference（值为100）、Candidate Path动态计算参数（如Dynamic Path Meric Type Latency，以时延为度量值基于CSPF算法生成Candidate Path）等。
节点B3发布附带Color属性（值为100）的业务路由2001:100::/64，其Next-hop为B3::200。Headend节点B1上收到该业务路由后，发现其Color与本地ODN模板中的Color相匹配，则根据ODN模板参数发起SRv6 Policy流程，形成标识为<100, B3::200>的SRv6 Policy，计算生成了一条Dynamic Candidate Path，其Segment List表示为<B2::10, B5::10, B3::1>。
需要说明的是，ODN方式不一定在Headend上新建SRv6 Policy。在某些情况下，如果Headend中已经存在对应的SRv6 Policy（如通过本地配置方式生成SRv6 Policy），则ODN方式仅生成Candidate Path加入候选路径列表中；如果SRv6 Policy不存在，则创建一个SRv6 Policy。
ODN方式可以按需生成或拆除Candidate Path，大大简化了SRv6 Policy配置的复杂性。ODN方式生成的Candidate Path适用于单AS域与跨AS域场景（图6-7就属于单域场景）：单域场景下，不需要引入SR-TE控制器，可由Headend节点完成；多域场景下，由于Headend节点无法获取全局TEDB，需通过SR-TE控制器完成路径计算。
6.1.4 SRv6 Policy引流
SRv6 Policy引流是指将流量导入SRv6 Policy的过程。SRv6 Policy引流主要有BSID引流、Color引流、DSCP引流以及静态路由引流等多种方式。不同的引流方式适用于不同的业务场景。本节主要介绍BSID引流与Color引流。
- BSID引流
BSID引流是通过BSID将流量引入其绑定的SRv6 Policy，常用于业务源节点和SRv6 Policy Headend节点不是同一个节点的场景。BSID引流示例如图6-8所示。
以图6-8为例介绍BSID引流过程。Headend节点B1通过前述介绍的方式创建SRv6 Policy，该SRv6 Policy的Binding SID为B1::100，Segment List为<B2::10, B5::10, B3::1>。节点A获知节点C发布的业务信息（如End SID C::1）以及节点B1发布的路径信息（如BSID B1::100）。为将报文发送至节点C，节点A封装SRv6报文（目的地址为B1::100），并转发至节点B1。
当接收一个目的地址为B1::100的SRv6报文后，节点B1开始SRv6 Policy引流过程，具体如下。
步骤1 查询本地SID表，发现目的地址B1::100是本地SRv6 Policy的BSID，遂将原SRv6报头SRH的SL值减1，指向下一个SID（C::1）。
步骤2 为原始SRv6报文封装一个新的IPv6报头，源地址为Headend地址，目的地址为SRv6 Policy的第一个SID B2::10。
步骤3 为新的IPv6报头封装SRH，携带该BSID对应的SRv6 Policy的Segment List<B2::10, B5::10, B3::1>。
步骤4 更新IPv6报头其他字段，并根据SID指令转发报文。
SRv6 Policy成功引流后，后续节点根据相应指令对SRv6进行处理与转发。
此外，BSID引流方式还经常用在隧道拼接、跨域路径拼接等场景，以有效减小SRv6 SID栈深，并降低不同网络的耦合（避免某个网络内转发路径的变化影响其他网络）。
- Color引流
并非所有引流过程都需要BSID，Color引流就可以不使用BSID。
Color引流又称为自动引流（Automated Steering，AS）。该方式下，如果Headend节点所收到业务路由（目前主要是BGP类型的业务路由）的Color和Next-hop与本地有效SRv6 Policy的Color和Endpoint相匹配，则会自动将该业务路由安装在FIB中，并将转发表条目指向该SRv6 Policy。这样，当Headend节点收到目的地址为该业务路由的流量时，就会将这些流量导入该SRv6 Policy。由于Color属性可附加到具体的BGP业务路由上，Color引流方式可以实现逐条路由的控制粒度。
Color引流示例如图6-9所示。Headend节点B1通过前述介绍的方式创建SRv6 Policy<100, B3::200>，其Segment List为<B2::10, B5::10, B3::1>。节点B3发布业务路由2001:100::/64（Color为100，Nexthop为B3::200）。Headend节点B1收到节点B3发布的业务路由2001:100::/64后，进行路由迭代具体如下。
- 验证BGP业务路由的Next-hop（B3::200）是否匹配SRv6 Policy的Endpoint地址（B3::200），验证BGP业务路由的Color属性（100）是否匹配SRv6 Policy的Color（100）。匹配成功后，即认为节点B3发布的BGP业务路由2001:100::/64与SRv6 Policy<100, B3::200>匹配。
- 将业务路由2001:100::/64及其关联的SRv6 Policy安装到FIB表中。此时，业务路由2001:100::/64的FIB表项中，Next-hop为B3::200，出接口为SRv6 Policy<100, B3::200>。
当节点B1收到去往目的地址2001:100::1的流量时，查询FIB表，得到出接口为SRv6 Policy<100, B3::200>，即执行相应动作，进行SRv6报文封装并转发，实现到SRv6 Policy的自动引流。
通过以上过程分析可以看出，Color引流方式并不会对转发性能产生影响。
由于Color引流与ODN方案都涉及Color匹配过程，容易产生混淆，此处进行比较并说明，具体如下。
- 定位不同：Color引流方案侧重于路由迭代（其前提是Headend本地存在有效的SRv6 Policy），将业务路由的出接口迭代为相应SRv6 Policy，从而实现流量向SRv6 Policy的导入；ODN方案侧重于生成相应SRv6 Policy/Candidate Path。
- 过程不同：Color引流方案在业务路由的Color/Next-hop与SRv6 Policy的Color/Endpoint匹配后，将业务路由的出接口迭代为对应的SRv6 Policy；ODN方案讲ODN模板中的Color与业务路由的Color匹配，随即将业务路由的Next-hop作为SRv6 Policy的Endpoint，计算生成SRv6 Policy/Candidate Path。