摘要

  • Donald Eastlake 为路由领域审查组所做的早期审查于 9 月 27 日完成，结果为“Not ready”。这是对工作组草案的一份审查意见，不是 IESG 驳回，也不是已生效的 BGP 规则。
  • 第 13 版草案对选定数据平面的转发表核验使用 SHOULD，对路径可用性核验使用 MAY；审查指出，文本没有明确核验失败是否令该路由退出最优路径候选。
  • “查转发表”还不够具体。LDP 标签、Segment Routing 前缀 SID、隧道及递归下一跳可能对应不同的实际转发状态；查错对象会得到看似通过却无关的结果。

把一条路由列入候选，与能按它转发，是两个判断。草案举的 MPLS VPN 情形很能说明差别：边缘路由器在 IP 路由表里仍可找到下一跳，但通向它的 MPLS 标签交换路径已经不能正常工作。若 BGP 继续选择并对外宣告那条路径，进入网络的流量就可能被引到坏掉的方向；即使另一路径可用，也未必被选中。这是草案用于解释风险的拓扑设想，不是一起经核实的生产故障。

新发生的是审查程序。Donald E. Eastlake III 的审查正文标注 9 月 25 日，IETF Datatracker 记载 9 月 27 日完成，结论“Not ready”。第 13 版仍是 IDR 工作组的有效 Internet-Draft，拟走 Proposed Standard 路径；IESG 状态为“I-D Exists”，没有会议日期。页首所写更新 RFC 4271 也带着“if approved”条件。工作组曾在 2020 年完成 Last Call 并进入领域主管审查，因此不能把本轮写成草案第一次接受检验，更不能把一名审查者的判断写成 IETF 最终决定。

问题落在草案第 3 节极短的规则上。第一项称，下一跳可达性 SHOULD 在政策选定的数据平面转发数据库中解析；第二项允许用相同数据平面的 OAM 机制做路径可用性检查，措辞为 MAY。选哪个数据平面、用什么机制，由政策和部署决定，草案未具体规定。Eastlake 赞同待解决的控制平面与数据平面落差，却问：若任一检查没通过，路由究竟如何处理？现行 RFC 4271 已规定，无法解析的路由不进入第二阶段决策。第 13 版没有明确把新增检查失败定义为该意义上的“无法解析”。审查中建议的 MUST 句子只是修改建议，不是草案已经采用的命令。

即使补上失败后果，检查对象仍须落到真正用来发包的状态。MPLS 下一跳可能依赖 LDP 标签项、SR 前缀 SID、RSVP-TE 或 SR Policy 隧道；BGP 带标签单播又可能让解析继续递归。直连下一跳则可能走无标签表项。它们不能互相代替。Eastlake 要求将核验绑定于实际转发所用的标签分发或隧道机制，递归深度也与转发保持一致。否则两套实现面对同一条路由，可能因为各自检查了不同表项而得出不同的最优路径结果。

还有既有规范的边界。RFC 9012 已规定，当 Tunnel Encapsulation 属性没有可行隧道时，相应路由在 RFC 4271 的意义上不可解析。审查要求解释新草案在此之外还增加什么；目前这是重叠问题，不是已证实的规范冲突。审查也提示 OAM 活性信号可能抖动、误报或漏报，普通 IP 逐跳转发若各路由器判断不同还可能形成环路。这些是待处理的设计风险，不能写成某个网络已经发生的事实。

因此，运维核对清单不该只问“下一跳有没有路由”。它应连起政策选择的数据平面、实际标签或隧道、递归转发项、检查结果，以及该结果有没有真正改变候选资格。这是 Daniel Kade 根据审查提出的可审计运营建议，不是 IETF 强制日志格式；眼下也没有据此推算故障频率的部署数据。

来源