摘要

  • Juliusz Chroboczek 与 David Schinazi 共同署名的 RFC 8966 把 Babel 度量计算定义为本地策略：节点将邻居通告的度量与自己计算的链路成本合成。共同要求是本地成本为无穷时结果为无穷，其他情况下结果必须严格大于收到的度量。
  • 这项规则服务于避免持久环路，并不使一个路由值成为容量、价格、实际时延、服务可用性或用户结果的全球排名。RFC 9616 特别说明，即使 RTT 样本准确，也可能过于嘈杂，不能直接拿来选路。

数字的职责比它的外观小

路由表中的数字很容易被读成一种判断：更低便是更好，稳定便是可靠，已经选中便是已经送达。这样的读法略过了最重要的前提：谁计算了这个成本、使用了哪些接口和邻居、数值经过何种变换，以及它究竟只为哪一个本地决定服务。

RFC 8966 的设计没有要求全体节点使用同一种测量。它允许同一网络的不同节点、不同类型接口采用不同策略。协议真正需要的是一个能本地验证的安全不变量。若把本地链路成本加入通告度量，结果必须增加；否则一个转发选择可能绕着环路走，却仍在度量上假装没有变差。

这正是最小共同层的意义：共享的是避免环路所需的可检验条件，不是给所有网络、所有运营者和所有用户体验设立一个中央评分表。低度量只说明在给定输入和策略下，某节点把某条有限且可行的路径列为选择；它本身并不证明该路径现在承载流量，更不证明远端服务可用。

无环不等于存在全局最优

RFC 8966 还区分严格单调性与左分配性。前者对避免持久环路必不可少；后者受到推荐，却不是无环收敛的必要条件。若后者不成立，Babel 仍可无环收敛，但未必达到全局最优，甚至可能根本不存在一个全局最优。

这不是术语细节，而是对度量权力边界的说明。本地策略可以各不相同，仍保持协议所需的安全条件。选择规则也有边界：无穷度量或不可行路由不得被选中；序列号更高不能仅因“更新”就优先，否则可能导致振荡，某些度量下还可能形成持续黑洞。面对连续变化的度量，RFC 推荐滞后机制，要求候选路由持续表现更好才切换。

滞后机制稳定的是算法内的选择，不是对服务质量的承诺。它要求的不是一个漂亮的瞬时数字，而是足够持续的局部证据。

RTT 观察并不自动获得决定权

RFC 9616 由 Baptiste Jonglez 与 Chroboczek 共同署名，明确说 RFC 8966 没有规定唯一的度量算法。它针对隧道或 VPN 拓扑中跳数、丢包型度量可能选错路径的问题，规定基于 RTT 的扩展。但该文不把 RTT 变成网络的真相：样本可以准确，同时仍然嘈杂；若直接用于选路，可能形成反馈并频繁振荡。因此文档还定义如何把样本映射为链路成本，以及如何使用滞后机制。

它的适用范围同样有限：对称时延必须能预测该链路是否适合承载路由流量。这不证明任何当前时延、端到端体验、价格或现网部署。Chroboczek 撰写的 RFC 8965 说明 Babel 对新型或波动度量可以保持稳健，同时也记录了周期更新和完整路由表假设带来的边界。

IETF Datatracker 将 RFC 8965、8966、9616 列在 Chroboczek 的公开档案中。这支持可核查的共同作者脉络，不支持把他写成某个运行网络、某项度量或某个部署的唯一控制者。

证据边界

这些资料没有指出任何正在运行的 Babel 域、活动隧道、被选中的具体路由、当前 RTT、容量、价格、安全状态或服务送达结果。它们也没有证明某个本地度量在所有拓扑中最佳。一个可审查的度量回执应记录算法版本、输入范围、样本窗口、成本变换、可行性和滞后状态，以及选路所处的接口和拓扑假设。

来源