摘要

  • 收到邻居的数据库描述报文后，如果其中某个 LSA 报头与本端准备发送的实例相同或更新，RFC 5243 允许从该邻居的 Database summary list 中删除本端条目。
  • 删除只取消一次多余的描述动作；它不证明请求列表为空、邻接进入 Full、SPF 完成、路由进入 FIB，或真实流量已经通过。

同一个报文，让两个清单朝相反方向变化

OSPF 两个邻居开始交换数据库时，各自会准备一份面向该邻居的摘要清单，里面不是完整 LSA，而是准备放入 Database Description（DD）报文的 LSA 报头。

收到一个合格的 DD 报文后，本端逐项比较。若邻居列出的实例与本端相同或更近，本端再把相同或更旧的报头发回去没有意义，于是可以从摘要清单删除。若另一个条目显示邻居的实例更新，本端却必须把它加入 Link state request list，稍后请求完整 LSA。

于是，一个报文可以同时让“还要描述什么”变少，让“还要取得什么”变多。只看总数下降，会把省去重复劳动误读为任务接近完成。

这并非 OSPF 特有的仪表盘问题。工单被取消，可能因为已执行、重复、失效、被更新任务取代，也可能因为记录丢失。系统若只保存“离开队列”，就丢掉了最关键的因果关系。RFC 5243 给出的删除原因非常窄：邻居已证明回传同一或更旧报头没有信息增益。

可以否定一次发送，不能肯定全局完成

这个机制赋予收到的报头一种“负向权限”。它足以否定一个拟进行的动作：不要把这份相同或更旧的摘要再发给这个邻居。

它没有“正向权限”去宣告更多事实。一个 LSA 的比较结果无法替整个 LSDB 作证；一个邻居的摘要清单无法替请求和重传清单作证；一次交换优化无法替 SPF、RIB、FIB 或数据面作证。

如果监控系统把 Database summary list 叫作“同步剩余量”，这种边界就会消失。随着优化生效，进度条可能迅速接近百分之百，而请求列表仍在增长。正确标签应当描述事实本身，例如“面向该邻居、因对端已持有相同或更新实例而省去的 LSA 报头”。

记录越具体，越不容易冒充权力更大的结论。

下一份响应之前，是本地一致性边界

RFC 5243 允许实现先查询本地数据库、再更新摘要清单，也允许顺序相反。但它要求：在发送下一份 DD 响应前，必须对收到报文中的每个 LSA 完成摘要清单更新。

原因很实际。下一份响应不应从一份只处理到一半的视图生成，否则报文前半部分已经证明多余的条目，仍可能被后半途构造出的响应带回去。

这是一条本地一致性要求，不是分布式提交。邻居没有为共同事务盖章，双方也没有互相证明完整数据库。后续请求仍可能存在，交换仍可能重启，状态也可能回退。

在其他控制系统中，“回复前处理完成”也常被写成“全局已提交”。管理层需要追问：完成的是哪台设备上的哪一步？这一步约束下一次输出，还是证明远端状态和业务结果？RFC 5243 只回答前者。

三份清单，防止一种叙事吞掉全部状态

RFC 2328 为每个邻居保留不同的记录。Database summary list 决定 DD 报文准备描述哪些 LSA；Link state request list 保存本端缺少或版本较旧、需要向邻居取得的 LSA；Link state retransmission list 保存已经泛洪、尚待确认的 LSA。

三者回答不同问题。把它们合并成“同步队列”，会让故障调查失去路径。

邻居状态机同样没有把交换结束写成一瞬间的成功。DD 报文交换完毕触发 ExchangeDone。请求列表为空时，邻接可进入 Full；请求仍存在时，先进入 Loading，直到 LoadingDone 才到 Full。

而 Full 仍只是 OSPF 邻接状态。它不能单独证明某条路由已完成 SPF 计算、写入 RIB、被硬件接受、双向物理路径可用，或者应用请求得到响应。

向后兼容，让采用情况更难从线路上看见

RFC 5243 不增加报文类型、能力位或 IANA 编号。一个路由器可以自行少发重复报头，不必等对端协商同样功能。这正是它“完全向后兼容”的价值。

代价是可观察性。没有功能握手，就不能从“握手成功”推出双方都实现了同一优化。抓包看到 DD 报文较少，可能因为 RFC 5243，也可能因为数据库较小、装包方式不同或其他本地选择。线路证据能说明发了什么，不能凭空解释未发生动作的内部原因。

文档建议按字典序排列 LSA，以便更快查询并促进实现一致。OSPFv2 使用 LS type、Link State ID、Advertising Router 的顺序；OSPFv3 交换后两个字段。这个顺序是建议，不是同步正确性的前提。观察到顺序不能当作完整合规证明，没有观察到也不能当作同步失败。

“约一半”是文档中的机制估计

RFC 5243 说，在大型网络中，如果邻居形成邻接时通常已接近同步，DD 开销可降低约一半。它给出的例子假设双方数据库完全相同，所有报头各需两个完整 DD 报文；优化后每方只发一个完整报文。

这个例子解释为什么能省，并不证明所有生产网络都省一半，也不证明某厂商默认启用、CPU 降低、收敛加快或事故减少。实际结果依赖数据库相似度、报文装载、时序与实现。

RFC 5243 是 Informational 文档。RFC 9454 后来把数据库交换中的旧称呼更新为 Leader/Follower，但没有扩大这项优化的证据能力。RFC 4222 另行讨论 OSPF 控制报文拥塞，RFC 4811 另行定义带外 LSDB 重同步。它们都没有把“少发一个重复报头”变成业务结果。

让记录停留在它真正能证明的现实层

Lu Heng 关于 reality layers 与 running code 的要求，可以在这里转化为一条操作纪律：每条记录只承担它实际观察到的事实。

本例的事实链很清楚。邻居公布了某个 LSA 报头；本端比较了标识与新旧；一次拟发送被判定为重复；条目在下一份响应生成前从面向该邻居的摘要清单移除。

这是有价值的效率证据。只要同时保存比较依据、删除原因、请求与重传义务、邻居状态以及后续计算和转发证据，它就不会越权。系统可以更快，也可以如实说明自己还没有证明什么。

来源