摘要

  • 10 月 28 日的个人草案提出一种 BGP 扩展团体属性，装入四字节路由器 ID 和两字节出口分组 ID。通告方写入自己的编号，支持该机制的入口路由器再把远端编号映射到本地 ECMP 子组。
  • 格式图把类型字节写成 0x83，子类型仍为 TBD；IANA 登记表将 0x83–0x8f 保留作实验用途。草案的 IANA 一节尚未交代如何取得长期使用的类型编号。

编号跟着路由走，实际链路由入口挑

普通 ECMP 用流特征哈希，把流分配给等价链路。少数巨型流撞在同一条路上，就会出现一边拥挤、一边空闲；改成逐包分流又可能打乱顺序。配套的增强 ECMP 草案让入口设备先把链路划成小组，再在选定组内做哈希。它列出的链路数量是示例，不是实测收益。

新草案负责把“选哪一组”的远端线索附在 BGP 路由上。出口设备写入本机 Router ID 和自己分配的出口组号。入口设备收到后，将这个远端组号映射到自己的本地子组。出口掌握标签，入口掌握物理端口。路由属性里出现一个组号，不能证明任何数据包最终走了哪条线。

公开编号表在这里打断了漂亮的流程图。草案把扩展团体属性的首字节固定画成 0x83；IANA 对传递型扩展团体属性的登记表把这一整段标为实验用途。新属性的子类型尚无号码。草案提出一个 GroupID 子类型登记项，却没说明首字节如何离开实验区间，成为持久分配。实验室可以借用试验牌；跨设备长期识别同一信号，得先有正式牌号。

IETF 状态页仍称它为个人草案。若接收路由器不支持增强机制，可以忽略该属性，继续普通 ECMP。安全章节也只有 TBD。这些原始记录没有跨实现测试或 AI 集群负载改善数据。能改变判断的证据很明确：修订后的类型与子类型分配说明，加上记录收到的属性、本地映射和实际链路选择的测试轨迹。

来源：分组 ID 草案；增强 ECMP 草案；IETF 状态；IANA 登记表。