摘要

  • 2026 年 8 月 25 日，IESG 批准 draft-ietf-idr-sr-policy-seglist-id-14 作为 Proposed Standard。证据冻结时，它仍是处于 RFC Editor 队列中的有效 Internet-Draft，IANA 的 19 号值仍显示为临时分配。
  • 32 位 Segment List ID 只在单个 Candidate Path 内唯一，也不会锁定 SID 的有序内容。同一个 ID 可以在内容变更后继续存在。可靠的运营结论必须把作用域、版本、BGP 接收、SRPM 校验、实际下发和流量结果连成一条证据链。

绿色状态掩盖了一次路径变化

设想一次维护窗口：控制器把三条有序指令记作段列表 42，NETCONF 配置、遥测时序和保障面板都用 42 关联。变更时，控制器替换了 SID 序列，却没有更换 ID。面板仍是绿色，曲线也没有断点。

编号连续，不代表路径连续。这个场景用于检验控制逻辑，并非某家运营商的已报道事故。它指出新标准最容易被误读之处：Segment List ID 是一种带作用域的引用，不是内容哈希，也不是“这条路径从未改变”的证明。

如果数据库只以 42 为键，它已经丢掉 Candidate Path。如果数据库保存了 Candidate Path，却没有保存当时的有序 SID、时间或修订，它仍会把两个不同状态合并为一个对象。

标准获批，出版流程尚未走完

IESG 公告显示，Inter-Domain Routing 工作组提交的第 14 版文稿于 8 月 25 日获准进入 Proposed Standard。到 8 月 28 日证据冻结时，Datatracker 仍将它列为 Active Internet-Draft，状态为 RFC Ed Queue；RFC Editor 正等待引用检查和格式处理，版本变化后的 IANA 动作仍在进行。

文稿日期为 8 月 24 日，Datatracker 在 26 日更新，当前到期日是 2027 年 2 月 25 日。IANA 的 BGP Tunnel Encapsulation 注册表则仍把 SR Policy Segment List Sub-TLV 的 19 号值列为临时分配：2025 年 12 月 19 日登记，2026 年 12 月 19 日到期，并指向较早版本。

因此，IESG 批准、RFC 编号、IANA 永久登记和生产部署是四件不同的事。第一件已经发生，其余不能从公告中推断。

它解决的是昂贵的匹配问题

一条 SR Policy 可以有多个 Candidate Path，每个 Candidate Path 又可以包含多个段列表。RFC 9830 规定 BGP 如何把这些候选路径送到 headend，由 headend 把段指令写入数据包。

没有短 ID 时，按列表上报统计的节点可能必须重复整套 SID，控制器再逐项比较才能确认是哪条列表。文稿还讨论了 YANG/NETCONF 配置引用 BGP 学到的段列表。一个整数能减少传输和匹配成本，也能让人更容易排查问题。

编码很克制：可选的 Segment List ID sub-TLV 位于类型 128 的 Segment List sub-TLV 内，而后者属于类型 15 的 SR Policy Tunnel Type。新 sub-TLV 类型为 19，长度固定为 6 个八位组，其中 4 个八位组承载无符号整数，标志和保留位发送为零。1 到 0xffffffff 可作为 ID；0 表示没有分配 ID，等同于不携带该 sub-TLV。

这些线格式只定义怎样引用，没有定义一个全球对象。

Candidate Path 是键的一部分

非零 ID 只需在同一个 Candidate Path 的段列表之间唯一。另一个 Candidate Path、另一条 SR Policy 或另一个 headend 可以合法复用相同数值，而且不表示相同指令。因此，外部引用必须同时携带 Candidate Path。

即便“Candidate Path 加 ID”也不是历史身份。规范明确允许 SID 序列变化时保留 ID。更准确的理解是：它像一个可变槽位，而不是内容地址。

审计记录至少应保留 SR Policy NLRI 的 Distinguisher、Color 和 Endpoint，Candidate Path 身份、Segment List ID、有序 SID，以及该映射生效的时间、修订号或内容指纹。否则，控制器和遥测平台可能都说自己看到了 42，却在谈论不同版本。

RFC 9857 已在 BGP-LS 报告中携带段列表标识符，新扩展又涉及 YANG/NETCONF 引用。相似含义不等于共享命名空间。每一次跨协议关联都必须保留作用域、类型、来源和新鲜度。

三类错误会产生三种后果

若 sub-TLV 长度不是 6，相关 BGP SR Policy NLRI 被视为格式错误，并按 RFC 7606 执行 treat-as-withdraw。控制面撤回不等于流量已经安全切换。

若一个段列表中出现多个该 sub-TLV，接收方使用第一个并忽略其余实例。若同一 Candidate Path 中多个段列表复用同一个非零 ID，则是交给 SRPM 处理的语义错误；接收方可以把这些列表全部当作没有 ID 关联。

混合版本部署还有一层边界。按 RFC 9830 的默认行为，无法识别某个 sub-TLV 的 headend 不会把携带它的 Candidate Path 视为可用。因此，“可选”ID 可能让旧节点上的候选路径失效。文稿建议只向支持它的节点选择性通告。

运营清单必须分别回答：软件是否支持、是否按邻居通告、BGP 是否接收、SRPM 怎样解释、Candidate Path 是否可用、最终是否被选择。一个总括的“已支持”无法覆盖这些状态。

BGP 负责携带，数据包给出判决

BGP 传递 Candidate Path 描述，并不验证隧道。SRPM 完成策略校验；之后还要经历可用性判定、主动路径选择、headend 下发以及真实流量。

一条可审计链路应包含：文稿或 RFC 与 IANA 状态；控制器和 headend 版本；按邻居划分的能力和通告；收到的 NLRI 与属性；Candidate Path、ID 和 SID 内容的绑定；解析器与 SRPM 结果；主动选择；转发面下发；同一内容修订下的计数器；实际流量结果。第五步的编号不能替第十步作证。

文稿还提醒，ID 可能暴露关键任务或商业敏感关系，应只在可信 SR 域的路由器和控制应用之间传播。多控制器分配、冲突避免、复用周期、版本、留存和回滚均不在标准范围内，必须由运营方另行确定。

H3C 与 ZTE 的实现声明基于较早的第 3 版，最后更新于 2025 年 2 月，而且属于自报信息。文稿明确说这不是 IETF 背书，也未独立验证。它能说明实现兴趣，不能证明当前互通性或部署规模。

来源