摘要

  • RFC 9830 为 BGP 定义了 SR Policy SAFI 与候选路径编码，但真正消费候选信息、完成语义校验和选出主动路径的是头端 SRPM。
  • Distinguisher 只让同一 Color–Endpoint 下的多条通告保持可区分，规范明确说它没有语义价值，不能代表版本、优先级或授权。
  • 接收通告、BGP 最佳路径、目标头端导入、SRPM 合格、主动候选、Binding SID、FIB 安装和实际流量必须留下各自的回执。

“发布成功”只回答了发送问题

开篇是一个测试场景，不指向任何真实控制器、厂商或网络。控制器完成一次 BGP UPDATE 的发送，可以证明本地进程把字节交给了会话。对端收到并保留路由，又能证明 BGP 层接受了该通告。两项事实都重要，但它们仍未回答“哪条 SR Policy 正在转发流量”。

RFC 9830 把职责写得很清楚。BGP 负责产生、传播和选择 SR Policy NLRI。头端的 BGP 表得到候选信息后，把它交给 SR Policy Module，也就是 SRPM。SRPM 同时可能掌握来自 CLI、NETCONF、PCEP 和本地配置的其他候选路径。它按照 RFC 9256 的模型校验、比较，选出主动候选，为其处理 Binding SID，并把选中的状态装入转发面。

这里存在两个不同的“最佳”。BGP 针对一枚具体 NLRI 做自己的最佳路径选择。SRPM 针对一个 Color–Endpoint 所标识的策略，在多个来源的候选路径之间做主动选择。前者决定哪份 BGP 通告有资格被递交；后者决定本机愿意把哪份候选变成运行状态。

因此，“BGP best”不能直接写成“policy active”。更不能从“policy active”继续推导“FIB 已安装”或“流量已按预期经过”。RFC 9830 甚至明确指出，BGP 本身不会把 SR Policy Candidate Path 安装进数据平面。把这句话留在监控模型里，比多加一个绿色图标更重要。

Distinguisher 能分开记录，不能解释记录

SR Policy NLRI 由 Distinguisher、Color 和 Endpoint 构成。Color 与 Endpoint 共同标识策略。Distinguisher 让发起者能够为同一策略发布多条候选路径，或为不同头端发布相同 Color–Endpoint 的通告，而不让这些通告在 BGP 中被错误地压成同一条竞争记录。

规范随后加了一道非常必要的限制：Distinguisher 没有语义价值。它不是序号，不是成本，不是版本，也不是可信级别。数值更大不代表更新，长期不变也不代表意图未变。它的权力到“区分”即止。

这正是现实层次最容易被压扁的地方。运营系统常把一个便于索引的字段升级成事实主体。可一枚 Distinguisher 只标识 BGP NLRI；Color–Endpoint 标识策略；Protocol-Origin 与 Discriminator 标识 SRPM 候选；originator 信息标识协议来源；变更单才说明哪个人或组织批准了目标。五种身份不能互相代替。

originator 的恢复规则也有边界。接收端可以依次从 Route Origin Community、ORIGINATOR_ID 或直接邻居的 Router-ID 得到来源信息。这有助于在路由反射之后追溯最初的 BGP 发起者，却不是法律身份认证，更不是业务授权。邻居是传递者，originator 是协议来源，批准者是责任主体。

显示名称更不可靠。SR Policy Name 与 Candidate Path Name 是可选的符号名称，长名称还可能在通告时被截短。它们适合人读，不适合作为唯一关联键。一次改名不应制造一条“新策略”，同名也不能把两条策略合成一条。

BGP 检查信封，SRPM 检查内容

BGP 并非不做校验。RFC 9830 定义 SAFI 73，限定 IPv4 或 IPv6 AFI，规定 NLRI 长度，并要求使用 Tunnel Type 15 的 SR Policy Tunnel Encapsulation Attribute。错误的 Tunnel Type、重复的 SR Policy TLV 或无法使用的结构会触发 treat-as-withdraw。

这项错误隔离机制保护了会话。坏掉的一条路由可以被当作撤回处理，而不是让整个 BGP 邻接关系崩溃。但通过这些结构检查，只能说明信封满足 BGP 的交付规则。

字段的语义属于另一个裁判。RFC 9830 要求 BGP 不得对各个 SR Policy 字段做语义验证，也不得仅因这种语义判断把更新认定为不可用。段是否适合本头端、SID 是否可验证、Binding SID 是否冲突、SRv6 行为是否可实例化，都应由 SRPM 按相应规则处理。

所以，故障码必须保留发生位置。“BGP 结构错误并视为撤回”“未知字段被忽略”“Route Target 未导入”“SRPM 语义拒绝”“合格但未当选”“已当选但未装入 FIB”是六种事实。把它们统一显示为“策略无效”，会同时抹掉责任人、恢复办法和对流量的影响。

可扩展性还会让各跳看到的信息集合不同。保留位在发送时置零、接收时忽略；不适用于 SR Policy SAFI 的某些 sub-TLV 可以被忽略并移除；对只允许出现一次的字段，后续重复项可能被忽略。控制器发出的内容、反射器转发的内容与 SRPM 实际收到的内容，都应保留独立指纹。

Preference 不参加 BGP 的投票

RFC 中有多个看似熟悉的排序词，但它们属于不同阶段。Candidate Path 的 Preference 由 SRPM 用来选择候选，不影响 BGP best path。Priority 决定拓扑变化后多条 SR Policy 的重算先后，不是某条候选的优先级。Segment List 的 Weight 则在选中候选内部，为多条有效列表提供流量分配权重。

如果监控把三者都缩成“优先级”，一次变化就无法解释。Preference 改变可能在 BGP 表完全不动时切换主动候选。Priority 改变可能只改变重算顺序。Weight 改变可能只改变多路径份额。三个字段的主语与结果都不同。

Binding SID 也不是“通告即执行”。发送方可以携带 BSID 信息和相关标志，头端仍需依据数据平面类型、本地资源与策略完成验证、分配、接受或拒绝。某些 SRv6 行为可以被标为 opaque，明确留给头端选择。

连 TC、TTL 与 Explicit NULL 也保留接收方决定权。发起者可以提供建议值，接收方能够按本地策略覆盖。ENLP 缺失时，是否推送 Explicit NULL 由本地配置决定；即使携带了 ENLP，运营者仍可根据部署需要覆盖行为。

共同格式由此实现互操作，却没有夺走承担后果者的选择权。这符合最小初始规范的逻辑：规定大家必须共同理解的字段，把未来和本地决策留在执行位置。

Route Target 是观众名单，不是执行命令

小规模部署可以让控制器与每个头端建立直接 BGP 会话。规模增大后，通告可能经过路由反射器，甚至在一个受信任 SR 域内穿越多个 AS。此时 Route Target 用来标明预期头端。

导入 Route Target 只说明本机愿意把通告交给相应角色。候选仍要经过 SRPM 校验和选择。因此，“对端收到”“头端导入”“SRPM 合格”“成为主动路径”必须分栏记录。只看 Adj-RIB-In 的自动化，无法知道导入之后发生了什么。

观众名单也是信息安全边界。SR Policy 通告可能暴露端点、节点地址、SID 以及具有商业敏感性的路径设计。BGP 会话需要配置，并不意味着该会话上的每个地址族都获得了同等披露许可。受信任 SR 域、对等体角色、AFI/SAFI、Route Target 与出口策略应被单独审批。

路由反射进一步增加了来源错认风险。头端的直接邻居可能只是反射器，真正的候选由控制器或出口路由器产生。只记录邻居，会把传递行为错写成发起意图；只记录 originator，又会漏掉中间传播策略。两者都要保留，再与业务批准者关联。

撤回一条候选，不等于撤回正在运行的路径

当一条 BGP SR Policy 路由撤回时，BGP 删除的是一个来源贡献。SRPM 可能仍有另一枚 Distinguisher 对应的 BGP 候选，也可能有 PCEP、NETCONF 或本地配置候选。主动路径可能不变、切换、失效或消失。仅凭撤回消息无法预言结果。

反方向同样成立。BGP 新最佳路径被交给 SRPM，并不保证主动候选改变。它可能因 Preference 落败，可能因段校验失败，可能请求无法接受的 BSID，也可能被本地政策拒绝。UPDATE 数量与 FIB 变化数量不是同一指标。

完整证据链至少包括：收到的原始 UPDATE 及哈希；BGP 结构校验；该 NLRI 的最佳路径；Route Target 导入；originator 恢复；SRPM 语义结果；同一时刻的候选集合；主动选择及原因；Binding SID 状态；段列表与权重；RIB/FIB 回读；实际报文与服务结果。每一跳都需要时间、设备、版本与可关联的决定编号。

缺少这条链，事故复盘只能看到控制面符号，无法证明谁让路径生效。更危险的是，系统可能依据错误的“发布成功”自动关单，把最关键的执行回执永久丢掉。

标准的力量来自克制

RFC 9830 完成了重要的公共协调：它统一地址族、NLRI、隧道属性、候选字段、传播和错误处理。不同实现因此可以互相传递候选路径。标准没有必要接管头端全部选择，才能证明其价值。

Heng Lu 的 Running-Code Primacy 要求把最终证据放回运行系统。RFC、控制器意图和 BGP 表是输入；SRPM、FIB 与报文才说明本机实际做了什么。Minimum Initial Specification 解释了为何共同层应保持最小。Reality Layers 则提醒我们：可读的名字、可传播的通告、主动控制状态与真实流量不能合并成一个“策略已生效”。

最能检验监控系统的实验，是为同一 Color–Endpoint 发送两条不同 Distinguisher 的 BGP 候选，再通过 PCEP 加入 Preference 更高的第三条候选。分别观察 BGP best、SRPM 候选集、主动选择、BSID 与 FIB，然后逐个撤回来源。若系统只能报告“BGP 策略变了”，它就没有保存 RFC 9830 特意留下的权力边界。

来源