摘要

  • RFC 10005 定义了可传递与不可传递两种 BGP Link Bandwidth 扩展社区；带宽值是以字节每秒为单位的 32 位 IEEE 754 浮点数，但标准明确不规定这个数怎样计算。
  • 同一个数值可指物理接口、聚合路径、服务器容量或相对权重。证据不能停在 BGP 表，而要贯通源端、进出策略、next-hop 变化、多路径资格、硬件 FIB 和真实流量结果。

一次容量调整会上，三个团队都拿出截图。边缘团队证明自己发出了 70；骨干团队证明路由反射器收到了 70；平台团队证明目标前缀存在两条路径。可事故发生后，没人能回答转发芯片是否真的按 70/30 编程，也没人保存 70 的计算来源。这个数字看似穿过了整个系统，责任却在每个交接点消失。

RFC 10005 于 2026 年 6 月作为 Proposed Standard 发布。它解决的是互操作问题：不同 BGP 实现怎样识别、编码和安全处理 Link Bandwidth。它没有承诺数值是真实测量，也没有替运营者选择流量目标。

协议只给数值一个载体

可传递形式的 Type 是 0x00，不可传递形式是 0x40，两者的 SubType 都是 0x04。Global Administrator 占两个字节，应该填写附加该社区的路由器 ASN，也可以是任意两字节值；四字节 ASN 无法完整编码，应使用 AS_TRANS。RFC 特别说明，这个字段不改变社区的用途和语义。

因此，Global Administrator 不能被当成签名。它不证明谁测量了容量，也不证明谁对链路有法律或商业控制权。要确定声明者，仍需查看邻居会话、设备版本、策略、配置与变更记录。

Local Administrator 占四个字节，以 IEEE 754 单精度浮点数存放字节每秒，不是比特每秒。单位足够精确，含义仍不完整。RFC 把数值的确定与计算留在范围之外。

最新的用例草案 v11进一步揭示了这种多义性：数值可以来自直接相连接口，可以是多条下游路径之和，也可以用服务器数量表示 anycast 服务能力；有些示例甚至只把它当作与实际容量成比例的权重。协议报文里没有字段区分这些来源。

第一段控制权：谁写入原始声明

发送端应该能选择可传递或不可传递形式，并通过本地策略设置 Global Administrator 与带宽值。不同实现可能使用不同的传递性默认值，因而不能用厂商名称推断实际状态。

发送端还可以写入零。RFC 以维护期间“不再吸引流量”为例，但零只是意图。接收端可能排除零值路径，也可能回到等价分流，具体由本地策略决定。

原始声明的责任记录至少应包含：数值来自配置接口速率、自动发现速率、下游聚合、服务器等价数，还是人工比例；采样时间与刷新规则；适用前缀；允许传播的管理边界；过期与回滚条件。没有这些字段，“70”只是无法审计的参数。

第二段控制权：策略可以在入口和出口改写

RFC 10005 允许在 Adj-RIB-In 处理时附加或更新社区，也允许在生成 Adj-RIB-Out 时附加或更新。换言之，接收邻居发来的数值与下一个邻居看到的数值可以不同，而且两者都符合协议。

这正是责任转移点。入口策略采用远端值，等于选择相信远端语义；入口策略替换它，等于本地重新声明；出口策略继续传播，则同时作出披露决定。RFC 警告，容量信息可能敏感，向不可信网络或管理域外发送时应过滤。可传递不是授权。

迁移期还可能同时携带可传递与不可传递两个社区，其值应该一致。旧实现或许只认识其中一种。如果中间设备只更新一个，后续设备会根据各自支持能力得到不同权重。RFC 明确指出，只升级路由反射器并不是互操作目标。

第三段控制权：next hop 改变后，旧数值还算不算数

当重新发布时改变 next hop，设备的默认行为可以是删除、原样保留或重新生成 Link Bandwidth；实现应该公开默认值，并允许按会话修改。若 next hop 不变，包括常见的路由反射场景，则不应修改社区。

保留旧数值意味着运营者认定它仍能描述新路径；重算意味着本地模型替代上游模型；删除意味着拒绝传播已失去上下文的声明。三者没有统一优劣，但每一种都需要所有者。

多路径聚合让问题更复杂。RFC 允许重新发布值基于 Local-RIB 中的组成路径计算，却把算法留在范围之外。用例草案把“contributing bandwidth”定义为本地选择的输入：远端值、本地接口值，或两者的函数。累加还可以分别基于远端、本地或贡献值。同一组路径在三种合法配置下会产生三个不同总数。

第四段控制权：接收端决定数值是否进入 FIB

当所有参与路径都有非零值时，接收端可以用数值或比例进行加权负载均衡。零值与非零值混合、全部为零时，行为由本地策略确定。若任一路径缺少有效社区，默认应采用等价分流，除非本地配置覆盖。负值不应发出，收到后忽略。

同一路由出现多个 Link Bandwidth 社区时，默认使用最低值，包括零，并忽略传递性差别；配置可以改写这个偏好。带宽值不应参与 BGP best-path 选择。它只能影响已经符合 multipath 条件的路径权重。

所以，路由表显示属性存在，不代表路径进入多路径集合；控制平面显示权重，不代表硬件 FIB 已写入；FIB 显示比例，也不代表哈希、长连接和实际流量立即按比例分布。

70 的远端声明遇到 50 的本地瓶颈

用例草案给出最清楚的责任反例：两条上游路径分别声明聚合能力 30 与 70，但接收端通往“70”那一侧的本地链路只有 50。如果直接按远端值分配 30%/70%，本地 50 链路可能拥塞。

接收端可以只用远端值，只用本地接口值，或使用 min(local, remote) 等函数。选择哪个函数不是 IETF 对业务风险的决定，而是接收端运营者的决定。若它选择远端 70，就应对自己看得见的本地 50 负责。

Juniper 文档说明配置的带宽不是链路实时流量，而且比率可能比物理接口值更重要。Cisco 与 Arista 展示了接口派生、策略显式设置与按邻居重算等控制。这些资料证明实现有选择空间，不证明任何生产网络启用了某个默认值。

把四段控制权做成一张责任账本

每个关键前缀都应保存 pre-policy 与 post-policy 路由、原始浮点字节、解码值、来源类别、邻居、地址族、next hop、传递性与 Global Administrator。每次重写都要有旧值、新值、算法、操作者、时间与适用边界。

接收侧继续保存 multipath 候选与入选理由、零值/缺失/多值处理、local/remote 函数、硬件 FIB 成员与权重。最后加入接口利用率、队列、丢包、延迟、流量份额与应用结果。只有这条链闭合，数值才成为可用证据。

Heng Lu 的运行代码优先要求把标准、配置意图和实际运行分开验证；最小初始规范则把公共层限制在互操作、安全和可本地验证的规则。RFC 10005 最有价值的地方，正是提供一个薄而明确的共同载体，而不是替运营者接管容量决策。

一个数值可以穿过四段控制权。责任不能只在最后一个表格里寻找。