摘要

  • RFC 8362 要求其扩展 LSA 设置 U 位，使不认识该功能码的路由器仍能按编码范围保存和泛洪它。LSDB 中出现该记录，证明的是传递链路，而不是语义理解、功能启用、SPF 使用、RIB/FIB 安装或数据包效果。
  • 未知但格式正确，与格式错误，是两种相反的处理状态。前者可作为不透明信息继续传播；长度不一致或编码错误的扩展 LSA 则不得安装、确认或泛洪，并应被计数和记录。

一张表里的四种事实

设想同一区域内有三台路由器。第一台发布一份 Extended Router-LSA，第三台认识其中的新扩展，中间设备的软件版本却早于这项定义。中间设备无法解释新字段，也不能据此执行相应功能，但它仍可让这份 LSA 抵达第三台设备。

原因藏在 OSPFv3 的 LS Type 中。RFC 5340 规定，类型里除了功能码，还有 U 位和泛洪范围位。遇到未知功能时，U=0 的 LSA 按链路本地范围处理；U=1 时，路由器按类型中编码的范围存储并泛洪。RFC 8362 为主要的扩展 LSA 分配新功能码，即在对应基础功能码上加十进制 32（0x20），并要求把 U 位置为 1。

中间设备并非什么都没做。它验证足够的结构、保管一个 LSA 实例，并参与可靠泛洪。然而，这只是“保管者”的权限，不是“语义见证人”的权限。一个常见的绿色状态，往往把四项事实压成一项：

  1. 字节到达，格式正确的 LSA 进入 LSDB；
  2. 软件认识该 LSA、TLV 或 sub-TLV 的语法；
  3. 相关功能已启用，并确实使用该信息作出计算；
  4. 计算结果进入 RIB、FIB，并反映到数据包。

RFC 8362 明确允许第一项成立，而后三项都不成立。因此，“我在 LSDB 里看到了它”不能被改写成“这台设备支持它”。

为未来含义准备的外壳

早期 OSPFv3 的 Router-LSA、Network-LSA 等采用固定格式。固定正文很难承载不断增加的能力。RFC 8362 定义扩展版本，把可变信息放进类型—长度—值结构，必要时再用 sub-TLV 细分。新功能码区分新的外壳，U 位则让这个外壳穿过尚未学会其含义的路由器。

这种设计解决了传播问题，却没有替未来扩展回答“部分部署能否工作”。RFC 8362 要求，每个新增 TLV 或 sub-TLV 的规范自行定义部分支持时的行为。有的功能只要求两个端点理解，有的需要连续的能力拓扑，还有的在信息不完整时必须退回旧行为。扩展 LSA 成功泛洪，不等于这些条件已经满足。

在一个已知的扩展 LSA 中，未知 TLV 和 sub-TLV 会在解析与处理时被忽略。“忽略”既不等于删除，也不等于支持。路由器可以保留外层 LSA 以继续泛洪，同时不赋予某个部件任何语义。后来的 RFC 9492 给出很好的例子：为某个应用发布链路属性，与在链路上启用该应用，是两个不同动作。

陌生不等于损坏

向前兼容需要容纳新的、格式正确的含义，却不要求传播损坏的编码。RFC 8362 划出的界线很硬：扩展 LSA 一旦出现长度不一致或其他编码错误，就不得装入 LSDB，不得确认，也不得泛洪；实现还应计数并记录错误。

因此，监控系统至少要保留三类结果：

  • 已知且有效： 解析定义内容，并只按扩展规范与配置允许的方式使用；
  • 未知但有效： 在 U 位和范围规则允许时，把它作为不透明信息保管与转发，不宣称理解；
  • 格式错误： 阻止它进入 LSDB 和泛洪系统，留下拒绝证据。

把后两类都叫“unsupported”会产生方向相反的故障。凡未知必丢，会破坏新旧版本之间的转交能力；凡未知必收，又会把损坏内容扩散到更大故障域。可靠实现必须区分“我不认识，但结构有效”和“这份结构本身无效”。

证据名称也要与处理状态对应。未知 LSA 视图证明保管；已解码 TLV 视图证明识别；malformed 计数器证明拒绝。任何一个单独存在，都不能证明路由已被选择或流量已经改变。

如何确认是“那一份”LSA

RFC 5340 用 LS Type、Link State ID 与 Advertising Router 标识一份 LSA。序列号、校验和与年龄帮助判断具体实例和新旧。校验和不包含 LS age，而年龄会在保存和泛洪过程中变化。因此，不应声称每一跳都保持逐字节不变。

更可靠的传递回执，应记录类型及范围位、发布路由器、Link State ID、序列号、校验和、观察区域或接口以及采集时间。LS age 可以辅助讲述传播过程，却不是不可变的正文。再把这一回执与软件版本、支持的语法、功能配置、计算输出、RIB/FIB 以及数据包观察分别关联，才能回答从“到达”到“生效”的完整问题。

管理系统也可能削弱证据。轮询会漏掉短暂拒绝，控制器可能抹平范围位，数据库也可能在功能关闭后保留旧记录。采集时间、源路由器和模型路径必须与结果一起保存。

两种迁移，都不能靠“看见”验收

RFC 8362 描述的完整迁移使用两个独立 OSPFv3 实例：旧 LSA 与扩展 LSA 分开运行。新实例先配置更高的管理距离，即较低的优先级；运营者比较两套 RIB，解释差异后切换优先级，再次核对，最后才移除旧实例。验收门槛是路由结果，而不是扩展 LSA 已经到齐。

稀疏模式则继续用旧 LSA 驱动普通 SPF，只让扩展 LSA 承载新功能所需的信息。它避免两套完整实例，却更依赖准确的能力地图：哪些节点必须理解，哪些 TLV 必须齐全，部分部署如何退化。零散看到几份扩展 LSA，回答不了这些问题。

RFC 9587 的 OSPF YANG 模型把这种界线带到运维层。它提供扩展 LSA 支持状态，默认值为 false；也能以类型、长度和十六进制值呈现未知 TLV 或 sub-TLV。不透明信息因此可以被观察，但不会被伪装成已理解信息。模型字段是证据入口，不是效果证明。

Acee Lindem 的准确位置

RFC 8362 于 2018 年 4 月发布，作者为 Acee Lindem、Abhay Roy、Dirk Goethals、Veerendranatha Reddy Vallem 与 Fred Baker，并更新 RFC 5340 和 RFC 5838。IETF 当前的 Link State Routing 工作组页面把 Lindem 列为主席之一；这是有时间边界的组织角色，不是对开放标准或部署网络的所有权。

这些资料支持一项克制的归因：Lindem 参与了集体标准工作，使 OSPFv3 可扩展状态能在理解能力不同的设备之间传播；他后来也共同参与了相关运维模型。资料不支持把扩展 LSA 说成他的个人发明，也不支持把后续所有 TLV、厂商实现或网络选择归到他名下。

这种有限归因与协议的权力结构恰好一致。发布者决定自己宣布什么；协议决定有效外壳怎样传播；实现决定能识别什么；配置决定什么可以参与计算；路由与转发平面产生结果；运营者决定保留什么证据。没有一行 LSDB 记录能替代所有角色。

从传递回执到语义回执

一份可辩护的部署记录应串起七个环节：LSA 身份与范围、各版本识别能力、功能启用状态、SPF 或应用计算输出、RIB/FIB 安装结果、与同一事件关联的流量效果，以及未进入传播系统的格式错误记录。

第一环并非第六环的低配版本，而是另一种事实。有时，路由器面对无法理解的信息，最正确的行为就是忠实地把它交给能理解的设备。RFC 8362 的价值，在于为这种诚实的保管留出协议空间。运营纪律则是给它应有的信用，同时不多给一分。

来源