摘要

  • 当修复 LSP 的回执与后续对账请求共用一个 PSNP 发送机制时，ASH rev05 要求实现优先发送回执，再用剩余空间承载请求。
  • 草案把每个邻居、每个 IS-IS 层级的对账限制为一次未完尝试；在约 6,700 个片段、40 个节点的实验里，重叠尝试产生的 PSNP 请求约为片段总数的 5 倍，而且仍在增加。

找到差异，只是修复的起点

CASH 先用节点范围摘要比较两份 LSDB；不一致时，PASH 把范围逐步切细；到单节点或具体片段，普通 SNP 请求或 flooding 才把缺失 LSP 补齐。这个过程看似有序，却在最后一段出现竞争。

接收方要做两件事：确认已经收到的修复 LSP，同时请求仍然缺失的 LSP。若两类条目经过同一个 PSNP 发送队列，调度顺序便不再是实现细节。新的请求会增加工作，回执则能让对端停止旧工作。请求一直抢先，发送端看不到回执，重传计时器到期，同一批 LSP 再次进入网络，也再次挤占回执。

9 月 26 日发布的 rev05 原文把这条反馈链写进了规范。与此同时，Datatracker显示它仍是个人 Internet-Draft，没有 RFC stream，也没有正式 IETF 地位；文头的 Experimental 只是拟议目标，不能当作采用或部署事实。

一次尝试，必须等到所有尾账清零

rev04已经规定：每个 peer、每个 level 同时只能有一次 reconciliation attempt。只要上一轮仍有 PASH、PSNP 待发，或者由它引出的 LSP 发送与重传尚未完成，就不能再发新的周期 CASH。

草案给出的实验很具体。在约 6,700 个片段、40 个节点的场景里，重叠尝试造成的 PSNP 请求约等于全部片段数量的 5 倍，观察结束时数字还在上升。作者把放大归因于重叠修复，而不是拓扑规模或哈希函数。也就是说，正确的摘要算法仍可能被错误的任务生命周期拖入放大环。

rev05 新增的调度规则承接了这项发现：若回执条目与 reconciliation 条目共享 PSNP 机制，实现应先确认收到的 LSP，再把剩余容量留给新的修复请求。这里的 SHOULD 允许有理由的例外，但管理者必须要求实现说明例外，并用运行证据证明它不会饿死回执。

三张凭证不能共用一个绿灯

BTW 旧文《哈希对上了，不等于网络就是对的》讨论的是 rev01：摘要相等只能终止一次差异搜索，不能证明物理拓扑或转发结果。本篇不重复那条结论，而是追问发现差异之后，修复队列何时有权宣布结束。

一个 PSNP 回执只证明某个协议对象在特定范围内被接收。它不等于整份 LSDB 已经一致。ASH 对账也必须等到该轮产生的 PASH、PSNP、LSP 发送和重传全部完成。即使如此，SPF 是否选出预期路径、FIB 是否安装、业务报文是否到达，仍需另外验证。

因此至少要保留三张凭证。第一张是 reconciliation receipt：邻居、层级、尝试标识、触发原因、范围、请求队列、回执等待时间、未结 LSP、重传次数、延迟 CASH 周期与完成时刻。第二张记录 LSDB、SPF 与 FIB 状态。第三张用真实流量证明路径。任何一张的绿色状态都不能自动填进下一张。

能力声明也不能越权。Hello Capability 草案中的 ASH_RX 与 ASH_TX 按方向、按邻接生效，只说明愿意接收或可能发送。RFC 1195给出 IS-IS 集成背景；RFC 5304与 RFC 5310保护 PDU 完整性，却不保证拓扑真实；RFC 9681可以加快 flooding，但不会替代结账。

Running-Code Primacy要求观察回执是否发出、重传是否停止、尝试是否真正关闭、流量是否恢复。Minimum Initial Specification支持把共同规则缩到“一次尝试、回执优先、明确完成”，其余调度仍留给本地实现。Reality Layers则提醒联盟：能力、数据库一致与业务可达属于不同现实层。

来源