摘要

  • RFC 9234 把 BGP Role 与 OTC 处理规则结合起来；OTC 不是脱离上下文的路由泄漏标签。
  • 合规路由器从 Provider、Peer 或 Route Server 收到未标记路由时，必须在入口补写 OTC。
  • 渐进部署期间，Role 可能只有本地配置而未获双方确认；复杂关系也不适用普通 Role 程序。
  • 运维证据应把已观测、Role 已确认、OTC 已补写、本地可用和端到端未泄漏分成不同状态。

设想一个路由监控面板：只要 UPDATE 中没有 OTC，它就显示绿色。某条来自上游的路由在采集里没有 OTC，于是面板将其标为“无泄漏”。但采集点位于入口策略之前。按照 RFC 9234，接收路由器恰恰要在这个入口为来自 Provider、Peer 或 Route Server 的未标记路由补上 OTC，并写入远端 ASN。

协议没有失效。失效的是证据模型：它把处理前的一帧数据，当成了整条路径的终局判断。

RFC 7908 把路由泄漏定义为公告传播超出预期范围。这个范围通常由分散在多个 AS 的导出和过滤策略决定，并常以 Provider、Customer、Peer 等双边关系表达。该文档给出的是工作性分类，而不是对所有可能泄漏的穷尽清单。OTC 能携带关键的关系来源信息，但某个点上看不到它，并不能还原预期范围、此前所有处理动作或实际收到路由的全部邻居。

OTC 是 type code 35、值长度为四个八位组的可选可传递路径属性。它的目标非常具体：路由一旦被发给 Customer、Peer 或 Route Server Client，之后只能继续发给 Customer。发送方向这三类邻居通告尚无 OTC 的路由时，必须补写该属性。从 Customer 或 Route Server Client 收到携带 OTC 的路由，就是泄漏，必须判为不可用；从 Peer 收到时，如果 OTC 内 ASN 不等于该 Peer 的 ASN，也必须判为泄漏。已有 OTC 的路由不得再发给 Provider、Peer 或 Route Server；OTC 一旦设置，其值必须原样保留。

这些规则之所以强，是因为判断者知道会话 Role、传播方向和处理阶段，而不是因为缺少四个字节就代表安全。