摘要

  • 10 月 28 日版弹性带宽感知路由个人草案，删除了旧版两种回切触发方法，改用“全部流量已回到主路径且利用率低于阈值”的条件。
  • 草案同时把回切定义为从备用路径迁回主路径，却没有写明在迁回之前如何判断可以迈出第一步。

绕行有步骤，回家却要先到家

一条聚合链路损坏了一根光纤，逻辑连接仍在，容量却少了一截。最短路径未必会随之改变，流量仍往这条路上挤。新版草案想让本地负载均衡节点直接处理这种局面：监测出口链路利用率；越过拥塞阈值时，把部分流量分到预先算好的备用路径；借助 Segment Routing 严格路径控制绕行；按可用带宽和利用率设置 UCMP 权重。中央流量工程还在做全网优化，本地节点先救急。

问题出在救急结束的时候。第 4.4 节说，回切就是把备用路径上的流量移回主路径。接下来的条件一要求：全部流量已经切回主路径，且主路径利用率没有超过“恢复后阈值”。条件二还要求这一状态持续一个可配置的恢复期。按照文字顺序，节点要先完成回切，才能满足允许回切的门槛。

7 月的 00 版并非如此。它给出两种启动办法：拥塞链路利用率降到恢复阈值以下，或者本地节点动态判断链路能够无拥塞地承载全部流量。两种办法都要求条件保持一段时间。10 月版删掉了这两个办法，把“所有流量已经回来”放到了第一条件。概述段落仍说流量可在利用率低于恢复阈值时回切，细则却没有给出回切前的判定方法。

作者也许想表达预测值：假如全部流量回归，主路径的利用率会是多少。也可能想要先试探性迁回一部分，再继续观察。现有第 4.4 节没有规定预测、试探、回滚或分批顺序。主路径此刻看起来空闲，恰恰可能是因为流量还在备用路径上。缺的是一个动作之前就能执行的判断；下一版补上它，这个文字矛盾便会消失。

IETF 文档记录把它列为个人互联网草案。这里检验的是提案文字，不是某个现网故障。这个问题仍然击中设计要害：草案把拥塞时的决定权交给本地节点，就应说明节点凭什么决定结束绕行。写出目标状态，却省略通往目标的第一步，最容易让实现者在同一个名字下各写各的规则。

来源