摘要

  • RFC 9800 允许 SR 源节点把多个压缩 SID 放入更少的 128 位容器，但压缩后的列表必须表达与原始列表完全相同的段序列。
  • Clarence Filsfils 是五位署名作者之一。这个机制节省了重复的定位块与填充位，同时把更大责任交给结构公告、地址分配、源端校验、端点能力与边界配置。

被反复携带的共同部分

一条严格的 SRv6 路径可能依次调用多个拓扑段或服务段。每个 SID 都以完整 IPv6 地址出现时，相邻指令常常重复同一个 Locator-Block，低位还可能带着只为补齐 128 位而存在的零。短路径上，这种浪费不醒目；路径越长，封装成本越明显。

2025 年 6 月发布的 RFC 9800 没有把段列表当成任意字节串来压缩。它先给共同结构命名：CSID 保留原 SID 的 Locator-Node 与 Function；一个 128 位 CSID 容器可以承载一个或多个 CSID，并在需要时保留最后一个 CSID 的 Argument。

真正的约束是语义等价。源节点写入报文的压缩列表，必须仍然表达原先那组有序段。少一次邻接、换一张转发表或者提前执行一项服务，都意味着路由程序已经改变。此时即使头部更短，也不能称为压缩成功。

这条约束把“节省字节”变成了“证明共同部分”的问题。源端必须知道哪些高位确实共享，节点与功能各占多长，Argument 还剩多少空间，以及端点究竟实例化了哪一种 behavior flavor。被删除的比特越多，留下来的结构记录越不能含糊。

两种前进方式

NEXT-CSID 与 REPLACE-CSID 都利用 SID 的 Argument 来寻找下一条指令，但装载方式不同。

NEXT-CSID 的活动容器本身就是完整 SRv6 SID。第一个 CSID 位于正常位置，后续 CSID 顺序装入 Argument。端点完成当前行为后，把下一段压缩值移到目的地址的活动位置，清零不再使用的低位，递减 Hop Limit，再做一次 IPv6 FIB 查询。一个地址大小的容器因此可以连续释放多条指令。

REPLACE-CSID 只让序列第一项以完整 SID 出现。后续 CSID 按固定位置装入 SRH 的 128 位 Segment List 条目。活动 SID 的 Argument 保存索引：索引还有位置时就在当前容器内移动；容器用尽时再递减 Segments Left，读取下一条 packed container，并重建有效的 IPv6 目的地址。

两种 flavor 都没有发明新的段语义。End.X 仍然是邻接行为，End.T 仍然选择指定表。RFC 的安全章节明确指出，改变的是下一 SID 的编码和恢复方式，不是当前或下一段的含义。

规范允许两种方式共存，甚至出现在同一列表中；但它也建议通常不要在同一路由域或 Locator-Block 内混用。线上的兼容性不等于运维上的低成本。不同长度建议、codepoint、解析路径和错误状态都会扩大测试矩阵。

源节点的第一项能力是拒绝压缩

原始段列表可能来自本地配置、本地计算，也可能由控制器通过 BGP 或 PCEP 等方式提供。来源不同，校验义务相同。RFC 9800 要求源节点在压缩前检查每个相关 SID 的结构。

规则是可计算的：Locator-Block 长度 LBL 不能为零；Locator-Node 与 Function 的合计长度 LNFL 不能为零；Argument 长度 AL 必须等于 128-LBL-LNL-FL。结构无法满足这些条件时，源节点把它视为未知，不得压缩。

“不得压缩”不等于“必须放弃整个策略”。压缩列表可以同时包含 CSID 序列与完整 SID。无法证明结构的一项保留原样，其他项目仍可压缩。这是安全的局部降级：未知信息不会被猜测，单项问题也不必演变成全路径中断。

规范还把路径选择留在范围之外。使用何种指标、避开哪条链路、满足什么业务目标、是否建立快速重路由，都是压缩之前的决定。压缩器只能忠实编码结果，不能借优化之名重新解释策略。

控制面保存的是结构证据

RFC 9800 要求这些新 SID 公告 SRv6 SID Structure。发起公告的端点必须使 LBL、LNL、FL、AL 与本地实例一致，并把公告中的 Argument 位设为零。IS-IS、OSPFv3、BGP、BGP-LS 以及配合 PCEP 的控制链可以分发这些信息。

结构公告能够证明“按这些字段计算时可以压缩”，却不能证明转发已经成功。端点升级后可能改变实例，旧公告没有及时撤销；控制器可能留着旧副本；源节点也可能按另一个软件版本理解 codepoint。确定性算法并不会自动修复陈旧事实。

因此故障排查不应只问“路由是否存在”。至少要对齐四份记录：端点真实实例、控制面公告、控制器库存和源端实际接受的结构。只有 behavior、flavor、LBL、LNL、FL 与 AL 同时一致，短列表才有可信基础。

域边界可以换块，但不能凭空获得权威

一段 CSID 序列通常共享 Locator-Block。跨入另一个路由域时，共享高位可能改变。End.LBS 在边界位于端点本身时更换定位块；End.XLBS 在更换的同时，把报文送入指定的三层邻接。

目标 Locator-Block 是该 SID 的本地属性。RFC 没有规定源节点必须如何得知它，只举出配置或控制器信令。这不是让实现自行猜测，而是明确划出组织接口：边界所有者需要负责目标块的发布、版本、验证与撤销。

这类安排保留了本地决定。标准规定如何正确执行换块，端点决定本地属性，源端依据可审计记录使用它。无需全球机构批准每个跨域安排，但参与方必须能复现同一转换。

地址空间也是压缩预算

CSID 越短，一个容器可装的指令越多，但可分配标识越少；CSID 越长，命名空间更宽，压缩密度越低。RFC 9800 没有给出全球唯一长度，而是建议同一路由域内保持 Locator-Block 与 CSID 长度一致。

GIB 是同一块下多个端点共享的全局标识池，LIB 则由每个节点独享。规范建议把稀缺的共享空间优先留给节点等真正全局的段，把服务、邻接和 cross-connect 放在本地空间。若大量本地功能占用 GIB，域级空间会更快耗尽；若为了极致压缩把字段定得太短，未来增长也会被提前锁死。

这说明压缩率不是独立指标。它与地址规划寿命、硬件能力和组织扩张使用同一套约束。

准确地书写 Filsfils 的位置

RFC Editor 条目列出的作者是 Weiqiang Cheng、Clarence Filsfils、Zhenbin Li、Bruno Decraene 与 Francois Clad。文档来自 IETF SPRING 工作组，更新 RFC 8754，相关 endpoint behavior 也进入 IANA 注册表。

Cisco 官方作者页把 Filsfils 标为 Cisco Fellow，并描述他在 Segment Routing 方面的长期工作。这是有日期的公司资料，不足以证明个人独占发明、控制实现或取得某个生产网络的量化结果。

更准确的意义在于连续性：Filsfils 的公开标准记录从 SR 架构、SRH、SRv6 行为延伸到 RFC 9800，后者处理的是宏大架构落地后一个细小而关键的问题——如何让多条指令共用更少空间，却不改变它们。

答案不是把复杂性藏起来，而是把共同前缀、长度、拒绝条件、边界与责任写得更清楚。报文之所以变短，是因为周围的契约变得更精确。

来源