摘要

  • RFC 9719 中的 was-the-last-lie-accepted 只说明某个接口最近收到的 Link Information Element 是否通过接受检查；它不证明邻接已进入 ThreeWay，更不证明层级、TIE 数据库、RIB/FIB 或业务交付正确。
  • clear-neighbor 与 clear-all-neighbors 是重建动作，不是恢复证明。可靠的处置必须保留清除前证据，并在清除后重新走完状态、数据库、路由、硬件转发和交付验证链。

一个布尔值的准确边界

RFC 9719 为 RIFT 定义了符合 NMDA 的 YANG 1.1 模型，并扩展 IETF routing 模型。它把配置意图与运行状态放在可编程、可审计的结构中。其中最容易被过度解释的叶子是 was-the-last-lie-accepted：最近收到的 LIE 被接受时为真，被拒绝时为假。若遭拒绝，last-lie-reject-reason 和 neighbor-error 通知可提供原因。

这个值没有歧义，歧义来自人们把它的语义向外扩张。它没有回答对端是否以所需状态看见本端，没有回答邻接是否进入 ThreeWay，没有回答 ZTP 是否选出了正确层级，也没有回答 TIE 数据库、路由计算、硬件转发或端到端交付是否成功。

RFC 9692 的有限状态机清楚说明了原因。TwoWay 已经意味着收到有效 LIE，但该 LIE 尚不是有效的 ThreeWay LIE。只有 ThreeWay 邻接才会被通告，TIE、TIDE、TIRE 也只有在 ThreeWay 条件下才进入正常交换。换言之，LIE 接受是输入校验结果，而 ThreeWay 是双向关系证明；两者不能互换。

从接收口到真实交付

第一站是接口。如果最后一条 LIE 被拒绝，应先保存拒绝字符串、通知、对端身份和时间线，再考虑修改。不同实现可能使用不同的具体措辞，因此结构化 YANG 状态应与日志并存，而不是让日志替代标准字段。

若 LIE 被接受，下一站是邻接状态。确认它是否进入并稳定保持 ThreeWay。停在 TwoWay 不代表监控互相矛盾，它恰好描述“收到了有效发现信息，但尚未获得对等确认”的状态。

第三站是 ZTP offer。RFC 9719 分别暴露发送和接收的 offer、最佳 offer、待移除 offer 及相关原因。LIE 能被接受，不等于层级和南北方向就符合 fabric 的设计意图。工程师需要把运行 offer 与预期配置分开比较。

第四站是拓扑同步和计算。查看 TIE 数据库、TIDE/TIRE 队列与计数、邻居数量、SPF 起止时间以及触发 SPF 的 TIE。邻接稳定但数据库不完整，依然无法支持“路由正确”的结论。

最后必须走出 RIFT 模型。RFC 9692 明确把实现如何编程转发平面留在规范之外。因此 RIB、FIB、ASIC 计数器和真实探测流量都是独立证据。管理模型可以说明控制平面相信什么，却不能单独证明数据包穿过了 fabric。

为什么清除操作不能成为工单的句号

RFC 9719 定义了清除单个邻居和清除某接口全部邻居的动作。动作调用成功，只说明设备接受了命令。它不说明连接已经重建，也不说明原始故障消失。标准的安全章节甚至指出，未经授权的清除可能反复触发邻接重建并破坏稳定性。

因此，清除前要保存现场；清除时要选择影响最小的动作；清除后则要重新观察 LIE、ThreeWay、offer、TIE 数据库、SPF、路由安装、硬件转发和业务交付。若只是症状暂时消失，应记录为临时恢复，而不是根因解决。

可机器执行的证据纪律

RFC 9719 的真正价值不是制造一个总健康灯，而是让不同证据的边界变得可机器读取。自动化可以对重复拒绝的 LIE 告警，可以在 ThreeWay 后启动数据库检查，可以关联触发 SPF 的 TIE 与计算时长，也可以比较预期配置和实际 offer。

它不该做的，是把一个局部布尔值升级成整个 fabric 的绿色状态。标准提供的是一组可以连接起来的观察点，不是一项替代所有测试的结论。