摘要

  • RFC 8654 允许 receiver 宣告可处理最高 65,535 octets 的 BGP message，但 OPEN 与 KEEPALIVE 除外；sender 只有收到该 peer 的 capability 后才能使用。
  • 承诺只属于当前 session。面对 4,096-octet peer，只能移除 RFC 7606 明确允许 discard 的 attributes；仍装不下就不得发送，已发布 NLRI 还必须 withdraw。
  • 安全部署先统一内部 iBGP 能力，再建立外部依赖；持续量测实际编码尺寸与资源压力，并为 rollback 保留 legacy-fit 表达。

变更窗口里，入口两端都显示 capability code 6，大于 4,096 的 UPDATE 被成功解析，route 进入 RIB。团队于是把“设备支持”写成“路径支持”。真正的故障发生在另一个 egress：邻居没有宣告 Extended Message，而 attribute block 已无法塞回旧包络。

RFC 4271 的 Length field 是两个 octets，却把合法范围限定为 19 到 4,096。RFC 8654 把协商后的上限扩至 65,535，并定义 code 6、length 0 的 capability。宣告它的含义不是“我能发大消息”，而是“这条 session 上我能接收并正确处理大消息”。

方向不能颠倒。speaker 只有收到对方 capability 后才可发送 Extended Message。RFC 5492 的一般规则要求 session 双方用 capability 明确表达能力，operator 也可把某项能力设为建立邻接的条件。实现即使具备功能，只要没有宣告，就不得暗中宽松接收；配置边界拥有权威。

OPEN 与 KEEPALIVE 不属于 RFC 8654 扩展范围。RFC 9072 处理的是另一项限制：OPEN 的 Optional Parameters 原本只有一个 octet 长度，最多 255。它以 type 255 和两 octets 长度扩展 capability 容器，并没有把 OPEN 变成 65,535-octet message，也不代表后续 UPDATE 已获授权。

65,535 是天花板，不是目标值

扩大包络不会让 bytes 失去成本。RFC 4271 可把共享 attributes 的多个 prefixes 装入一个 UPDATE；ADD-PATH 为每个 NLRI 加四-octet Path Identifier；每个 Large Community 是十二-octet operator semantics。VPN、traffic engineering 与安全扩展还会增加属性。

这些字段不是随手可删的 padding。community 可能控制 export，Path Identifier 区分候选，optional attribute 可能被下游 policy 使用。尺寸治理必须理解语义。

若 attribute set 较小，sender 可把 NLRI 分到多个 UPDATE；若 attribute block 自身已超过 4,096，拆 prefixes 没用。TCP segmentation 只切传输包，不会把一个 BGP UPDATE 自动变成多个独立声明。receiver 仍按 header 验证完整 message。

最小邻居决定传播边界

向 legacy peer 出口时，RFC 8654 只允许一种保守缩减：移除 RFC 7606 已归类为 attribute discard 的字段。任何会影响或可能影响 route selection、installation 的 attribute 都不能如此处理；local policy 也可能赋予原本中性的字段决定作用。

缩减后仍过大，就不能发送。若该 NLRI 过去已向邻居发布，还要撤回。规范选择明确失去 route，而不是传递一个语义残缺的副本。

因此同一路由可能出现在一个 border，却消失于另一个；两个 route reflectors 可能形成不同 external view；backup path 可能在 Loc-RIB 中存在，却在 failover 时因属性过大而无法发布。普通尺寸的测试不会发现这种依赖。

RFC 8654 要求相关 iBGP speakers 一致宣告能力，才能保证 AS 的一致外部视图。内部仍混合时先向外开启，相当于建立一张不可见的信息容量拓扑。

更大的 message 也扩大解析成本

接收 65,535 的承诺涉及 buffer、queue、parser、attribute validation、policy、logging 与复制。RFC 8654 明确指出 accidental 或 intentional resource exhaustion 风险。为多个 legacy egress 重排、寻找可 discard 字段也会消耗 CPU。

身份认证只能说明 peer 是谁，不能让合法的大消息变便宜。真正的压测要同时覆盖多个 peers、连续 near-limit messages、queue headroom 与失败时日志放大。

FRRouting 当前文档把 RFC 8654 列入实现范围；BIRD 3.3.0 分开 enable 与 require，并说明上限变化。这些是测试起点，不是生产 session 已协商、所有 hop 都兼容或资源足够的证明。

证据必须绑定 session epoch：local/received capabilities、peer、AFI/SAFI、running build；每条临界 route 的 inbound length、attribute length、NLRI count 与每个 egress 的 exact encoding；结果要区分 repack、discard、suppress、withdraw、Bad Message Length 和 policy reject。

最后，成功传出 UPDATE 也不等于 forwarding。还要验证 selection、recursive resolution、FIB/ASIC 与 packets。运行事实的证据层级不能被 capability 截图替代。