Summary

  • IETF 的个人草案建议路由器根据本地接口利用率，按目的前缀逐步把流量导入专用的 Offloading Flex-Algo（OFA）路径。
  • “高利用率亲和性”挡住新增绕行流量，原有绕行流量可以留下；“拥塞亲和性”把链路逐出 OFA 拓扑，原有流量也必须另找路。

真正棘手的时刻发生在第一次救火之后。主路径拥塞，路由器把一部分流量送上备用通道。别的路由器也看中这条通道，空余容量迅速消失。草案先设置一条准入线：链路达到高利用率时，公布相应亲和性，新的卸载流量不能经过它，已经在上面的流量却可以继续走。若利用率继续升到拥塞阈值，另一种亲和性便把该链路从 OFA 拓扑中排除，先前绕行的流量也被迫改道。第一道门维持眼前的秩序；第二道门把压力交给别的路径。

控制权留在每台路由器手里。它测量自己的出口接口，针对目的前缀，在原路径与 OFA 路径之间以非等价多路径分配流量，逐次增加卸载份额，并在迭代之间加入抖动。草案提到的 5% 增量，以及 50%、60%、70%、80%、90% 的利用率阶梯，都是示例，不是全网统一配置。份额还要受备用路径上容量最小的链路约束。没有有效 OFA 路径，或者候选路径上已有高利用率链路，就不能继续加入新的绕行流量。RFC 9350给这套独立的 Flexible Algorithm 拓扑提供基础。

这项设计以限制新流量换取稳定，也把旧流量留在一条日益吃紧的链路上。单个大流可以扰乱测量；多台路由器同时卸载，可能在别处制造新的拥塞；拓扑一变，相关前缀的卸载就要终止并从初始状态重启。草案要求按前缀抑制反复切换，并建议每次迭代的间隔长于拥塞检测、IGP 通告限速、传播和稳定余量所需时间。沿某条 OFA 路径的每台路由器都得支持该机制；中途一台旧路由器就可能让绕行路径失效。

IETF 跟踪页把它列为个人 Internet-Draft。对照 00 版与 11 月的 01 版，可见更新主要是日期及文档页眉，两道门并非 11 月新添。现在缺的是多路由器实测轨迹：第一道门何时停止新增卸载，第二道门何时逐出旧流量，下一条路径又有没有超限。