Summary

  • 10月28日的 IDR 工作组草案 draft-ietf-idr-rt-derived-community-13 提出一种从 Route Target 派生的 BGP 扩展团体属性。它保留 Global Administrator 与 Local Administrator 数值，但更换子类型。按该草案本身的规则，派生标签只标明所对应的 RT，不限制路由传播，也不触发导入 VRF。文件尚在 IESG 评估，目标状态为 Informational。
  • IANA 目前已有六项相关编号，引用的是2021年的前身草案。新版要求更新引用并申请更多编号。编号登记只确定标签的名字和位置，接收方具体怎么用还要由各用途文件说明。

十台边缘路由器，不应只有一张收件名单

草案的例子 设定一个 VPN 有十台提供商边缘路由器。共同的 Route Target 让它们把相应 VPN 路由导入各自的 VRF。现在有另一条 BGP 路由需要表明与这个 VPN 有关，实际却只需送到其中几台。如果在它身上直接贴共同 RT，现有分发逻辑可能把它交给全部十台。如果每一个子集都另造一个 RT，同一个 VPN 的关联身份又碎成许多牌号。问题不是号码太少，而是一个号码同时回答了“属于谁”和“送给谁”。

派生扩展团体属性拆开这两个问题。它复制原 RT 的管理者字段数值，改用登记的派生子类型。接收者可反推它对应哪一个 RT。第2节明确，这个属性凭草案自身不限制路由分发，也不让路由进入任何 VRF。它不能装进 RFC 4684 的 RT 成员资格 NLRI；匹配真正 Route Target 的策略也不会把派生属性当成同一项。牌子可以指向钥匙，却不是钥匙。

现行 RFC 4360 说明了原钥匙的作用：Route Target 标识可接收带该属性路由的一组路由器。草案借用相同的管理者数值，是为了让不同子集认识共同的 VPN 身份；改变子类型，是为了把原 RT 的分发与导入效力留在原位。只看数值像不像，就给派生牌子原钥匙的权限，会抹掉设计中最重要的界线。

登记一个代码，不会替网络制定收件规则

IANA 现行 BGP 扩展团体属性登记表 已列出一些子类型 0x15 的 RT-derived-EC，IPv6 地址专用表也有 0x0015。草案说已有六项分配，引用仍指向2021年的前身文件。它请求 IANA 更新这些引用、重命名 EVPN 对应项，并给基于 UUID 的 IPv6 RT 以及两种 Transport Class 配对分配更多数值。后面这些是草案里的请求，不能把“请求”写成登记表已经完成的动作。

同样不能把常见的 0x02 到 0x15 当成万能换算式。草案称它是约定，具体对应关系由表1建立。表中另有以 0x0011 为 RT 值的 IPv6 项，其派生值仍待分配。实装要看准确类型、子类型与正式登记配对；凭常见数字推断权限，恰好会犯这份文件试图防止的错误。

草案把派生标签的后续行为留给用途文件。每份用途文件要写清 AFI/SAFI、可携带的路由类型，以及接收方据此采取什么动作。这不是文字工作的尾注，而是下一道权力门槛：共同规范允许网络表达一种关联；能否安装、导入、广告或转发，须另有可检验的规则。一个观察到标签的计数器不能证明业务已抵达。

截至10月28日，Datatracker 将第13版列为 IESG Evaluation，IANA 审查状态是版本变更后需重审。官方文件能证明拟议语义和现有编号，尚没有指名的实网泄露或错误导入记录。最终 RFC、IANA 更新和实现证据会改变可下的结论。