摘要

  • RFC 9573 把按入口 PE 区分的大量标签语义，收敛为全域共同标签块或少数共享的上下文标签空间。
  • 状态缩减成立的前提，是所有相关 PE 与分段点都支持同一程序、掌握同一分配；RFC 明确把如何保证这些条件留在范围之外。
  • 可靠上线必须分别留下分配权、配置代际、标签空间选择、转发表落项、路由一致性和租户流量结果的凭证。

节省下来的九十九万九千个标签去了哪里

RFC 9573 给出一个醒目的算例：1,001 台 PE，每台承载 1,000 个 VPN 或广播域。原有上游分配方式下，出口 PE 需要按 1,000 个入口上下文理解合计一百万个标签。若同一服务在所有 PE 上使用同一标签，所需状态可以降到服务数量本身。

这九十九万九千个解释并不是被算法消灭了。它们被一份共同约定替代：某个数字在域内只表示某个 VPN、BD 或 Ethernet Segment。原来由“入口是谁”隔离的语义，改由预配置的一致性来隔离。

因此真正的控制面不只是 BGP 路由。还包括谁生成映射、哪些设备属于该域、它们何时接受同一版本，以及硬件表项是否真的按该版本写入。

规范要求全员支持，却不负责点名全员

RFC 9573 规定，启用这些程序时，所有 PE 和分段点都必须支持；但如何保证这一点不在文档范围内。VPN、BD、ES 的标签如何分配、怎样让所有成员知道，同样由范围外的方法完成。

这是协议边界，不是协议缺陷。问题在于运营方不能把边界外的假设偷偷当作边界内的证明。DCB 标志说明路由声明该标签来自 Domain-wide Common Block，并不能证明每台机器都预留了同一段，也不能证明某台掉线设备没有保留旧含义。

“全域”也不是天然全球。文档把 domain 定义得很宽松，本质上是共享同一 DCB 的路由器集合。成员清单必须成为可审计对象，而不能只存在于设计图上。

外层选对表，内层仍可能选错业务

当默认标签空间无法拿出足够大的共同块时，可以用一个 DCB 标签标识共享的上下文标签空间。报文先压入业务标签，再压入选择该空间的 DCB 标签。接收端先根据外层进入一张表，再用内层标签找到业务。

这种方式把一个映射拆成两个映射。外层“选择器到表”正确，不代表内层“标签到 VPN/BD/ES”正确。接收 PE 还必须在默认 MPLS 表中安装选择器，并在目标上下文表中安装服务项。

Context-Specific Label Space ID Extended Community 携带的是空间坐标，不是配置历史。它不会带上审批人、控制器代际、硬件写入回执或回滚状态。这些证据必须由运营系统补齐。

分段让统一语义再次出现局部例外

两个流在区域 A 可以共用选择性隧道 T1，到区域 B 却分别进入 T2 与 T3。边界分段点必须在不依赖本地 VRF 的情况下，把它们切到不同的下游隧道。此时一个 VPN 共同标签不够用。

RFC 9573 允许中央实体给每台 PE 分配互不重叠的标签块，PE 再从自己的块内给动态分段 PMSI 分配标签。局部自治重新出现，但它依赖块所有权绝不重叠、回收过程可证明、配置代际可追溯。

另一条路是在分段点的 VRF 中做 (C-S,C-G) 查找。它减少逐 PMSI 标签，却增加流路由与 VRF 状态。架构选择不是“要不要状态”，而是把状态放在哪里、由谁观察、哪种失败更容易隔离。

矛盾信号不能靠猜

DCB 标志与上下文空间标识不能同时出现在一条路由上；同时出现必须按撤回处理。两者都没有，则回到源 PE 的上游标签空间解释。

共享同一隧道的多条 x-PMSI/IMET 路由也必须采用一致的解释方式。若有的使用 DCB、有的使用上下文空间或旧方式，接收端无法确定隧道封装之后的标签应在哪张表解释，必须把这些路由视为撤回。

这是有价值的拒绝凭证，却只覆盖控制面歧义。撤回发生后，旧转发表何时清空、在途报文是否结束、租户隔离是否保持，仍需数据面观察。

注册号只固定语法

IANA 为 DCB 位、Extended Community 子类型和空间标识类型建立了注册。它们让不同实现使用同一编码。注册本身不证明设备已实现、特性已启用、控制器分配无冲突，也不证明业务已经成功交付。

RFC 9573 还明确认为三种分配方法没有在既有基础之外引入新的安全问题。本文不把配置一致性边界夸大成已知攻击或事故。能被来源支持的结论更窄：共同标签的语义依赖协议外的共同状态。

Sources

来源