摘要

  • RFC 10005 规定 BGP Link Bandwidth Extended Community 以四字节 IEEE 754 浮点数传递每秒字节数，但数值如何得出、如何变成流量权重均不在规范范围内。
  • 零值、缺失值、多份 Community、传递属性和下一跳变化都要经过实现默认值或本地策略；合法字段不等于当前可用容量、已安装权重或实际吞吐。
  • Pradosh Mohapatra 是六位署名作者之一。其集体标准工作定义了一个克制的传递工具，运营证据仍须从数值源头一直连接到 FIB 与逐路径结果。

一次扩容后的看板上，三条路径分别显示 40、80 和 120。权重也按一比二比三计算，变更记录没有报错。半小时后，第三条路径的队列最深、丢包最多。复盘才发现，前两条数字是接口速率，第三条是远端多条路径的汇总；本地到下一跳只有 50 的可达瓶颈。

三个数都可能按 RFC 10005 的格式正确编码。错误发生在另一个层面：它们使用同一单位，却描述不同对象；汇总值又在跨越下一跳后被当成了本地可贡献容量。看板把格式一致误写成了语义一致。

2026 年 6 月发布的 RFC 10005 属于 IETF 标准轨道文件，题为 BGP Link Bandwidth Extended Community。Pradosh Mohapatra、Reshma Das、Satya Mohanty、Serge Krier、Rafal Jan Szarecki 与 Akshay Gattani 共同署名。文件统一了编码与处理选择，也明确把最关键的两件事留在范围之外：带宽值如何计算或确定，以及加权负载分担使用什么算法。

数字有单位，却没有语义标签

Link Bandwidth Community 有传递型与非传递型两种形式，类型分别为 0x00 和 0x40，子类型为 0x04。字段先放置两字节 Global Administrator，再放置四字节 Local Administrator。后者是 IEEE 754 单精度浮点数，单位为每秒字节，而不是每秒比特。

单位差异看似简单，却是证据链最早的一道断点。界面若显示 bit/s，就已经做了乘八转换；若再换成十进制 Gbit/s 并四舍五入，就进行了第二次转换。审计记录应同时保留原始四字节、解码值、原始单位、显示单位与转换规则，而不能只留下“80 Gbps”这类不可逆标签。

更大的问题是字段中没有“这是什么带宽”。它可能是物理接口线速，可能是远端路径汇总，可能是配置值、测量值、服务器数量衍生权重，也可能是维护信号。RFC 10005 不替发送方作出语义选择。

2026 年 4 月的 draft-ietf-bess-ebgp-dmz-10 仍是工作草案，不是最终 RFC。它用案例区分远端带宽、本地链路带宽和本地计算的贡献值。若收到 70 Gbit/s，而本地到下一跳只有 50 Gbit/s，接收方可以用本地限制函数把贡献压到 50。这个例子说明需要什么记录，不增加 RFC 10005 的规范承诺。

因此，每个值都要附有独立的“出生证明”：语义类型、来源系统、测量或配置方法、观察时刻、有效期、所有者。数值能够穿越 BGP，并不意味着这些背景也会随四字节自动穿越。

Global Administrator 不是完整身份凭证

两字节 Global Administrator 应填写附加 Community 的路由器 ASN，但也可以是任意两字节值。四字节 ASN 装不下时使用 AS_TRANS。RFC 还说明，这个字段不改变 Community 的使用与语义。

它因此不能单独证明“谁测量了容量”，也不能成为数据所有权或授权签名。真正的发送者身份应从路由、邻居会话、地址族、管理域和附加策略事件中取得，并与原始 Community 关联。

这条边界在跨域场景尤其重要。Link Bandwidth 值可能泄露敏感容量信息，RFC 建议在路由离开管理域或走向不受信网络时采用策略过滤。审计不能只记录一条“已启用过滤”的配置，而应记录在哪个边界、由哪版策略、对哪条路由、实际移除或保留了什么。

最小字段保持克制，未来决策留给本地系统，是一种协调优势。但本地自由必须伴随本地责任；否则，字段越易传播，来源越容易丢失。

下一跳变化会重写责任边界

BGP Speaker 重新发布路由并改变下一跳时，RFC 10005 允许三种动作：移除原 Community、原样保留，或重新生成。实现应公开默认动作，并允许按会话覆盖。若下一跳未改变，则不应修改 Community。

三种动作表达三种不同声明。移除意味着下游不应继续依赖上游数值；保留意味着运输原声明，但没有增加本地测量；重新生成意味着以本地输入形成新值。最终四字节不会告诉下游发生过哪一种。

即使输入和输出恰好相同，重新生成也不是“什么都没发生”。比如收到 50，本地限制函数算出 50，再发布 50。数值相同，证据主体、计算方法与时间已经改变。若只按数值是否变化记录事件，这次责任转移会完全消失。

每个下一跳边界都应保存旧下一跳、新下一跳、收到的原始值、动作、策略版本、本地输入、结果、时间和执行者。这样，故障调查才能回答数字在哪一跳失去原语义，而不是从最后一个看板逆向猜测。

零、缺失、无效与过期必须分栏

零是合法值。发送方可以在维护期间发布零，但接收方的本地策略决定零意味着什么。零值路径可以被排除，也可以触发等价分担，或进入其他配置规则；所有路径均为零时，同样不存在唯一的强制结果。

缺失是另一种状态。如果参与 multipath 的某条路径没有有效 Community，RFC 默认采用等价负载分担，除非配置另有规定。负数不应由发送方生成，接收方应忽略。正数若超过来源有效期，则是格式合法但证据过期。

把四者都写成 unknown 会破坏处置能力。零可能是主动排空；缺失可能是能力不兼容；无效可能指向发送缺陷；过期可能是更新节流造成。不同状态应保留不同告警、责任人和回退动作。

一条路由还可能携带多份 Link Bandwidth Community。用于加权分担时，默认选取最低值，包括零；配置可以改变偏好。迁移过程中，旧实现可能只识别一种传递形式，于是一份得到更新，另一份仍然陈旧，下游据此算出不当权重。

监控应把类型、原始值和时间作为一个集合比较。两种传递形式数值不一致时应报警，不能悄悄挑一个显示并丢弃另一个。

控制面比例不是硬件里的比例

当所有贡献路径都有非零值时，数值或比例可以用于加权负载分担。RFC 10005 不规定具体算法，并明确建议不要把该值用于 BGP 最佳路径选择。它影响的是合格 multipath 之间的分配，而不是把最佳路径过程变成容量测量器。

接收策略可以把 30 与 70 化为三比七。FIB 可能因为 bucket 数量有限而近似成别的比例；硬件也可能为了 resilient hashing 保留既有流。即使安装比例完全正确，少量大流与大量小流的组合仍可使实际字节比例明显偏离。

所以至少需要四份可关联回执：接收的 Community 集合、策略计算结果、FIB 或 ECMP 安装值、逐路径实测流量。配置差异只证明意图改变；控制面命令最多证明软件采纳；硬件确认才证明编程；计数器与性能指标才证明结果。

“分配符合权重”也不等于“容量充足”。接口线速、可达瓶颈、当前余量与已交付吞吐是四个量。两条路径可以按理想比例分流，同时都在发生排队与丢包。必须把字节、包、丢失、时延、队列深度和拥塞状态放在同一代记录里。

为稳定而抑制更新，也要记录陈旧

快速变化的值可能影响协议稳定与运营，RFC 因此建议限制 churn。阈值、定时器和发布频率都合理，却会制造多个时钟：来源观察、决定发布、BGP 发送、接收、策略计算、硬件安装。

如果只保存最后接收时间，十分钟前测得、刚刚才发布的值会看起来只老了一秒。被阈值抑制的变化也应留下审计事件；稳定性机制不能把“没有传播”伪装成“没有变化”。

运维指标应直接比较数值年龄与其有效期。若来源过期，而旧值仍在影响 FIB，就要标出谁有权继续使用、回退策略是什么、最长宽限期多长。稳定与新鲜度之间的权衡必须成为显式决策。

Pradosh Mohapatra 的署名说明贡献，不授予控制权

RFC 10005 记录 Pradosh Mohapatra 的所属机构为 Google LLC，并列出其他五位作者。2026 年 9 月 1 日抓取时，与该文档关联的 IETF Datatracker 官方参与者页面列出十一份 RFC，但仍显示旧拼法“Prodosh Mohapatra”。RFC 10005 与 ipSpace 公开作者页使用“Pradosh Mohapatra”，本文据此采用规范身份。

ipSpace 的有日期履历还记录了他此前在 Cumulus Networks 与 Cisco 从事路由软件工作的背景。它能帮助确认人物及技术脉络，却不能证明 RFC 所列机构之外的当前职位、对 IETF 共识的控制，或任何具名网络的部署结果。

人物视角不应把六人标准改写成单人发明。它真正有用之处，是让一项可核实贡献的边界变得清楚：Mohapatra 与共同作者标准化了一个承载数值的机制，同时没有把发送者的本地判断升级为全球统一的容量事实。

为每个带宽值建立可追溯回执

第一层保存路由与地址族、邻居、管理域、传递类型、Global Administrator、原始浮点字节、解码的每秒字节数与显示转换。第二层保存语义、来源、方法、观察时间、有效期和所有者。

第三层记录下一跳变化以及移除、保留或重生成；聚合要保留所有组成路径、零值与缺失值处理、公式和版本。第四层连接接收策略、计算比例、FIB 权重与硬件确认。最后加入逐路径流量、丢失、时延、队列、告警、决策、回滚和陈旧清理。

这条链不会削弱 Community 的价值，反而使它可靠。BGP 负责证明发布了什么；本地策略证明如何解释；运行中的转发表证明安装了什么；流量证明发生了什么。“可用容量”只有在这些证据相互吻合后，才成为可以承担后果的结论。

来源