摘要

  • RFC 9832 把运营者定义的运输类变成路由导入与下一跳解析机制；32 位 Color 是索引，不是全球通用的 SLA 释义。
  • Color 可位于 TEA 的 Color sub-TLV、BGP CT 的 Transport Class RT 和业务路由 Color 扩展团体中。RFC 给出了优先级，但正确选择仍需保留全部输入与执行策略。
  • 进入 TRDB、解析成功、启用回退、写入 FIB、真实转发和达到 SLA 是六种不同状态，前一步不能替后一步签收。

一个数字，三个作用域

分级运输最容易被讲成“业务和隧道涂上同一种颜色，网络自动把它们接起来”。RFC 9832 实际上更谨慎。运输类是在一个管理域或紧密协调的多个域内，把运营者认为具有足够相似流量工程特征的隧道归为一组。这个组由 32 位 Transport Class ID 标识，文档也把它称为 Color。

比特本身不包含“低时延”“高带宽”“避开某节点”或“具备快速重路由”的句子。意义来自运营者。除零以外的全部编号都属于 Private Use；零代表 Best Effort，且实现还应允许运营者配置另一数值。两个网络都写 100，并不说明它们采用相同时延门槛、损耗预算、保护方式、测量窗口或赔付承诺。

同一个值还可能存在于三处。隧道封装属性里的 Color sub-TLV 针对具体封装；BGP CT 路由上的 Transport Class RT 负责运输路由的分类与解析；业务路由上的 Color 扩展团体表达覆盖层的映射要求。第 7.10 节按作用域由具体到一般规定：TEA Color sub-TLV 优先，其次是 BGP CT 的 Transport Class RT，最后才是业务路由 Color。

这个顺序解决冲突，却不免除记录义务。若系统只存“最终颜色 100”，就无法说明胜出的值来自哪一属性、被压过的值是什么、哪一对等体送来这些属性、哪个策略版本执行了决定。确定性输出不等于可复现证据。

TRDB 是控制面边界，不是转发结果

每个运输类对应一个逻辑 Transport Route Database。隧道路由进入相应 TRDB。BGP CT 路由以 RD:端点为 NLRI，并携带 Transport Class RT 与 MPLS 标签或其他转发标识。若本地已配置该运输类，RT 的路由目标角色指示接收设备把路由导入哪张 TRDB。

导入不等于使用。RFC 允许把 TRDB 实现为只服务于控制面下一跳可达性的路由表；其中的隧道路由只有在解析某个下一跳时才需要进入转发面。事故分析中，“正确的路由出现在正确的库里”只能证明一个环节。它不证明业务路由选中了该库，也不证明硬件存在对应项，更不证明下一台设备支持同一种封装。

Transport Class RT 还可以扮演 Mapping Community。接收设备用它选择本地的 Resolution Scheme。每个方案包含一张或按顺序排列的多张 TRDB，设备在这些库中对协议下一跳做最长前缀匹配。只有前面的主库找不到端点时，后面的备库才会生效。

管理员可以定制这个顺序。若找不到对应运输类的解析方案，设备会使用 Best-Effort 方案；路由若没有 Mapping Community，也会走 Best Effort，且 BGP CT 路由不会因此进入某个运输类 TRDB。这不是无害的兼容默认。可达性可能保持，承诺的运输处理却已经消失。

回退不是绿色状态灯

“主用隧道不可用”和“主用 TRDB 没有匹配端点”并非同一事实。RFC 的算法只规定：在前序数据库找不到匹配时，继续搜索下一张库。它没有替运营者判定缺失原因。原因可能是隧道失效、导入不完整、RTC 过滤、端点错误、策略变更、类配置过期，或转发技术不兼容。

因此，解析收据至少要保存：收到的路由和对等体、所有携带 Color 的字段、实际 Mapping Community、Resolution Scheme 版本、TRDB 顺序、命中的数据库和端点、选择的隧道，以及是否发生回退。单一的“resolved=true”会抹去客户时延改变而路由仍通时最需要的决策路径。

若所有选中数据库都无法匹配端点，BGP CT 路由或业务路由必须被视为不可解析。Best-Effort 运输类下的不可用 BGP CT 路由还不得继续传播。Transport Class RT 可结合 Route Target Constraint 限制分发；RFC 要求构建对外过滤时考虑同一 RTC 前缀的多个 EBGP 路径，而非只看最佳路径。缺路由有时首先是分发证据，未必是隧道证据。

边界翻译编号，不翻译结果

RFC 9832 明确处理多个域不共享颜色空间的情况。其示例让业务层 color:0:100500 保持不变，同时在三个域中分别映射到运输颜色 500、300 和 100。边界路由器把 BGP CT 的 Transport Class RT 从 500 改写成 300，再从 300 改成 100。

这样做的价值是把协调限定在相邻运输域，而不要求全球业务节点共享一张颜色字典。但它也说明最终本地编号必须带着来源。transport-target:0:300 只能说明接收域要把路由导入哪个类；它不能证明上游和本地对“Gold”的理解相同，更不能证明某次策略执行无误。

完整映射收据应保留收到和发出的 RT、两侧本地定义、相邻域协议版本、策略提交、执行边界、批准者、生效时间和回滚条件。只保留最终编号，会把一次可撤销的协商翻译伪装成普遍语义。

解析成功之后还有转发

在 MPLS 场景中，边界节点以自身为下一跳重发 BGP CT 路由时，需要分配新标签，并安装一个标签路由：交换或弹出收到的标签，再把流量送进已解析的运输隧道或接口。实现还可选择性地把 BGP CT 路由写入 FIB，支持跨域端点的控制面对等可达。

这段流程清楚地暴露证据断点：路由可以正确导入，协议下一跳也可以解析，标签甚至已分配，但预期硬件项仍可能缺失、陈旧，或指向另一封装。RFC 的互通示例更直接：只有 MPLS 能力的节点与只有 SRv6 能力的节点没有共同转发技术时，彼此收到的 BGP CT 路由仍然不可用。

最终收据不在 Color 机制里，而在承诺边界上的实包路径与服务测量中：丢包、时延、可用性、保护切换与测量窗口。包到了不等于走了低时延类；平均时延低不等于路径符合约定；FIB 正确也不等于客户 SLA 已实现。

实验性协议，生产级责任

RFC 9832 的类别是 Experimental。发布说明存在一套可实现和评估的机制，不说明采用率、互通性或已经交付的结果。冻结的 RFC Editor 勘误页记录一项 Verified Editorial 勘误，把第 3 节三处 SN1 改为 SN11，不改变本文分析的机制。

安全措施的证明边界也很窄。会话保护可以保护对等体之间的传输；进出口策略能限制基础设施前缀；独立 SAFI 76 和新 RT 类型能降低与业务路由混杂的概率。但这些都不能验证运输类的业务定义。可信对等体仍可能发送形式正确、协议含义却错误的映射，BGP CT 也新增了可被利用的流量偏转面。

Lu Heng 关于“互联网无色”的论述在这里有一个克制而字面的应用：基础设施最终由服务运营者、降低摩擦和真实可用性来验证，而不是由标签验证。RFC 9832 的 Color 也应如此——它是本地索引，价值来自执行证据。Running-Code Primacy 要求可复现的路由输入、策略输出和 FIB；Reality Layers 则把标识、行政意义、控制面、转发和客户结果分开。它们是 BTW 的编辑视角，不是 IETF 的额外要求。

来源