摘要

  • 第 13 版草案把 Route Target 的管理员字段值复制到另一种 Extended Community 子类型，但不给这份副本路由传播或 VRF 导入效力。
  • 传递型副本仍可能跨越 AS 边界；基于 Route Target 子类型编写的 eBGP 过滤规则可能匹配不到它。

BGP 标签本身很小，它们代表的权限却不能混为一谈。

Route Target（RT）可以告诉 VPN 把一条路由归到哪里。在实际网络中，它还能限制哪些路由器收到这条路由，并触发匹配的 VRF 导入。普通 Extended Community 可以携带相关标记，却不自动拥有这些控制能力。当一条路由只需要在部分 PE 路由器上与某个 VPN 相关联时，这个区别就很关键。

这正是 第 13 版草案 描述的场景。草案于 10 月 28 日更新。假设十台 PE 路由器会导入带有 RT1 的 VPN 路由。另一条路由需要在其中一部分设备上关联到这个 VPN，但它的传播由另一枚 RT3 控制。如果把 RT1 直接当作关联标记，所有导入 RT1 的设备都可能把它理解为要接收这条路由。若为每个子集另设一个标记，同一 VPN 就会堆出一串值。

草案给出的办法是派生一枚 Extended Community：保留 RT 的 Global Administrator 和 Local Administrator 值，只替换子类型，并称之为 RT-derived EC。数值仍指向那枚 RT；不同的子类型则说明这不是 RT 本身。

草案把界线写得很清楚：RT-derived EC 不限制路由传播，不触发 VRF 导入，也不会匹配专门匹配对应 RT 的策略。它不能放进 RFC 4684 定义的 Route Target Membership NLRI。草案负责定义编码对应关系和代码点；收到它之后该怎么处理，必须由另一份用途规范说明。

边界问题从传递属性开始。派生时保留 Type 字段的高位字节，因此从传递型 RT 派生的 EC 也仍是传递型。没有相反策略时，它可以跨越 AS 边界。原本按 RT 子类型过滤或改写的规则，不会自动覆盖派生子类型。管理员值和本地值相同，代码点却不同，匹配结果也不同。

草案记录了多个 Extended Community 注册表中的 0x15 子类型分配，其中包括 AS 专用的传递格式。它没有把 0x15 指定为所有 RT 格式通用的取值；其他对应关系仍是申请项或待定项。RFC 4360 解释了 Extended Community 类型字段为何能支持分类策略。这里，恰恰是子类型的变化，让边界规则可能漏掉同一组管理员值。

IETF 运营审查组在 10 月 30 日完成对第 13 版的审查，结果标为“有细节需处理”。审查人 Gen Chen 要求增加专门的运营考量章节，并指出跨 AS 过滤与泄漏风险、范围边界以及旧版 BGP 的行为；如果不希望传播 0x15，运营方可考虑在 eBGP 边界过滤它。这是审查意见，不是已经发生泄漏的证据。它指出的问题是：定义一个编码，不等于解释它在混合网络中的实际路径。

截至 11 月 2 日，草案处于 IESG 评估阶段，排定 11 月 5 日讨论。信息类编码规范可以规定哪些位彼此对应，却没有替每个运营方决定谁来过滤、旧设备如何处理，以及后续用途应如何隔离。子类型只占一个字节，盘点策略却是一项更大的工作。

来源：第 13 版草案 · IETF 运营审查 · RFC 4360 · RFC 4684