摘要

  • RFC 1245 讨论 OSPF Version 2 的资源消耗、路由流量、扩展能力与稳健性；RFC 1246 则记录实现、仿真、运行网络和三轮互操作测试，两者承担不同的证明责任。
  • RFC 1246 不只保存通过的项目，也明确写下首轮记录不完整、三个现场网络均采用同一种实现，以及跨厂商路由器之间同时运行多种路由协议尚未测试。
  • RFC 1247 才是协议规范。把三份文档分开阅读，才能辨认一个结论来自计算、实验室配置、实际运行还是标准决策。

一张链路状态数据库可以在纸面上有漂亮的上界，两个程序却仍可能在一个未写清的字段上作出相反选择。反过来，几台路由器在测试室里成功建立邻接，也不能回答数据库扩大十倍、故障同时发生或外部路由持续涌入时的资源问题。

OSPF 工作组把这种张力直接写进了出版结构。1991 年 7 月发布的 RFC 1245 名为《OSPF Protocol Analysis》，是信息类分析报告；同月的 RFC 1246 名为《Experience with the OSPF Protocol》，保存实现与使用经验。另一本 RFC 1247 才是标准轨道上的 OSPF Version 2 规范。

这不是把同一篇材料拆成上、下册。RFC 1247 规定协议行为，RFC 1245 评估设计在特定假设下怎样扩展，RFC 1246 检查独立代码与真实网络怎样表现。三者可以互相支持，却不能互相冒名。

计算先画出边界

RFC 1245 从协议结构出发。OSPF 路由器维护链路状态数据库并计算最短路径；区域缩小详细拓扑传播和计算的范围；多接入网络上的指定路由器减少邻接数量与同步流量；序列号、确认和老化机制共同支撑可靠泛洪。

报告继而追问实际约束：路由更新会占多少带宽，最短路径计算多久发生一次，数据库会长到多大，同一个局域网上能容纳多少路由器，网络分割、设备重启和旧通告清除时会怎样。

答案并非来自一种证据。部分结论源于公式与协议结构，部分采用 BARRNet、NASA Sciences Internet 和 OARnet 的运行统计，部分引用仿真。一个内存估算来自 Proteon P4200 的特定配置，作者还提醒其他实现可能不同。测得一个设备的占用量，并没有把它变成所有路由器的容量保证。

局域网规模的例子尤其清楚。RFC 1245 一处写到仿真中有超过 50 台路由器连接到同一 LAN，另一处写到互操作测试曾把 13 台路由器接到同一以太网且没有遇到问题。前者探索模型中的配置，后者记录实际运行过的配置。两者都没有覆盖所有计时器、实现、故障组合和负载。

因此，分析给出的是一个带条件的包络。数据库构成、通告更新频率、包大小、拓扑、计时器和实现内存都属于结论的一部分。日后的网络若越过这些条件，就需要新的计算或新的测试，不能只继承一句“已经分析过”。

测试网络发现文字没有封住的缝隙

RFC 1246 换了一组观察单位。报告列出至少参加过一轮互操作测试的五种实现：3Com、ACC、Proteon、Wellfleet 和 University of Maryland 的实现；又记录从 1990 年春季开始的现场试验，以及 NSI、BARRNet、OARnet 三个运行系统。报告快照中的路由器数量分别为 15、14、13。

这些网络提供了数据库同步、可靠泛洪、外部路由导入、等价多路径、stub area 和故障恢复的运行材料。但三套现场部署全部使用 Proteon 实现。RFC 1246 因而把“多厂商现场部署”列入尚未在运行环境中测试的项目，同时把另外开展的多厂商互操作测试作为不同证据引用。

两种环境的差别会改变可见的问题。现场网络带来真实业务、维护节奏和故障，却可能始终保持同一套代码。互操作会话让不同实现相遇，却通常使用事先规划的拓扑和压缩的测试时间。报告还指出，测试期间路由器频繁重启，因此 MaxAge 清除流程比普通运行中更常被触发。测试并非缩小版生产，生产也不是自动完成的互操作矩阵。

失败把缺陷分了类

首轮互操作测试发现，在 Database Description 过程中存在一个窗口：并发泛洪的 MaxAge 通告可能使数据库同步无法完成。规范对 MaxAge LSA 的处理必须修改。另一个问题是，规范没有说明通告默认目的地的外部 LSA 应怎样填写 Network Mask；一个实现的假设碰上另一个实现，歧义才变成可观察的故障。

这两项都不是带宽公式能够排除的问题。它们来自独立代码对同一文本的不同解释。RFC 1246 同时承认首轮测试记录不完整，无法在文中重现测试配置图。因此，发现本身仍然有效，但后人不能从简短结论中还原所有参与设备、链路和参数。

后续轮次扩展到虚拟链路、不同网络类型、认证、路由层级、可靠泛洪、通告清除和外部路由导入。一个导入 400 条外部路由的配置暴露了实现的缓冲区分配和避免 IP 分片策略问题；报告同时认为整个系统在其他方面相当稳定。这里至少有三类记录：规范需要澄清的地方、实现代码的缺陷、特定配置下通过的项目。把它们合成“OSPF 已验证”会丢掉最有用的信息。

报告确实用“verified”描述某些有环拓扑和超过 400 条 LSA 数据库中的可靠泛洪，也记录一次导入多达 400 条外部路由。但它没有把边界藏起来：不同厂商路由器之间同时运行 OSPF 与 RIP、EGP 等多种路由协议的情形尚未测试；不同实现交换路由信息的内部架构也不相同。

后来的推荐仍有自己的权限

1992 年的 RFC 1371 解释 IESG 为何建议把 OSPF 作为 IP 互联网的 common IGP。它强调选择需要以运行经验为依据，也明确说明这种指定并不强制使用 OSPF。

这是一项基于当时证据的标准治理决定，不是对早期材料的重新命名。推荐没有把 RFC 1245 的估算变成测量，也没有把 RFC 1246 的测试会话变成全球多厂商部署。

这段历史最值得保留的不是一句“OSPF 通过了”。真正的成果是一条可检查的证据链：规范、分析假设、实现清单、仿真、受控互操作、现场部署、发现的缺陷、未覆盖范围和后来的决策。信心来自这些记录能够连接，而不是来自它们听起来像同一种成功。

来源

证据边界

这些 RFC 证明的是 1991 至 1992 年文档所记录的分析、实现、测试环境、现场系统、发现和标准建议。它们不证明任意规模的性能、所有厂商组合、普遍部署、后来不再出现缺陷、当前网络状态或必须采用 OSPF。