摘要

  • 11 月 2 日的 ROV 测试方法个人草案把第一只表设在相关 RTR 更新 PDU 发出时，直到 BGP RIB 与 FIB 都稳定才停；第二只表在相关 VRP 完成安装后才开始，终点相同。
  • 第一只表包括 RTR 传送、VRP 安装、路由源状态重算和 BGP 收敛。第二只表只看安装后的阶段。草案要求只公布其中一项时写清楚是哪一项。
  • 草案列出的 VRP 与路由表规模是测试负载；附录 B 另有 BIRD/Linux 环境实测，不能当成其他设备的成绩。没有起止事件、负载和多次运行的离散程度，“ROV 很快”没有采购意义。

新证据进入网络后，数据包不会立刻改道。路由器先接收缓存经 RTR 送来的验证数据，更新本地 VRP 表，再重新判断受影响 BGP 路由的源状态，按本地策略选路，最后写入 FIB。真正让流量走新路径的是最后一步。把秒表放在 VRP 安装完之后，等于把前面的等待从成绩里裁掉，却仍把成绩叫作“收敛”。

RFC 8210规定缓存与路由器之间的 RPKI-to-Router 传输。RFC 6811规定 BGP 路由源可被判作 Valid、Invalid 或 NotFound，如何处置由本地策略决定。判定、选路和转发是三件不同的事。对一个正在购买路由安全能力的运营者，问题不是芯片多久给一条记录贴标签，而是从新记录送出到转发状态稳定，整条链条拖了多久。

草案第 00 版的“VRP 触发收敛”测试明确拆开这段时间。端到端计时从 RTR 模拟器发送第一条相关 VRP 更新 PDU 开始，到被测设备的 BGP RIB 和 FIB 同时稳定结束。另一项计时从设备完成相关 VRP 更新安装开始，到同一个稳定状态结束。两项共享终点，却不共享起点。前者回答网络何时完成新证据引发的转发变化；后者帮助定位安装之后的 BGP 处理时间。

这会直接改变报价表上的排序。设两台设备都在同一时刻写稳 FIB；从更晚的起点计时，数值自然更小。这只是起跑线的算术，不是对某厂商行为的指控。要判断具体设备的表现，必须在同一次测试里留下两个起点和共同终点的时间戳。把不同实验的结果拼成一张排行榜，连算术都站不住。

草案还提出逐站记录。VRP 安装测试要记录第一条 RTR 更新发出的时刻，以及本地 VRP 表反映变化的时刻；如设备允许，还要分出第一条、最后一条 VRP 安装和整批处理耗时。验证延迟测试观察受影响 BGP 前缀的状态变化。端到端收敛测试看最优路径选择、撤销或替换，以及 RIB、FIB 最终稳定。“验证只要几毫秒”可能是真的，但只回答了其中一个站点的问题。

负载配置同样不能藏。草案举出 5 万、10 万、50 万和 100 万条 VRP 的表规模，也给出可能采用的 BGP 基线：100 万条 IPv4 路由和 25 万条 IPv6 路由；若分地址族测试须明确注明。这些是实验条件示例，不是全球路由表的现值，也不是任何型号的测速结果。报告应写明实际 ROA/VRP 数量、BGP 路由覆盖率、VRP 重叠情况、前缀长度分布及状态发生变化的前缀数。

附录 B 给了一个可核对的样本。BIRD 2.19.2/Linux 测试环境先装入 1,060,368 条 VRP，选择 1,000 个前缀，执行 1,230 次 VRP 操作；十次运行的端到端平均收敛时间为 5,027.552 毫秒，安装后的平均值为 4,813.556 毫秒。两者相差约 214 毫秒，正是该实验中晚起跑线没算进去的一段；大部分实测时间发生在安装之后。这组数不代表其他路由器。它说明成绩必须连同起点、负载和终点一起交付。

更新的形状也会改变工作量。变化集中在一部分验证结构，与散落在许多部分，不一定触发相同的处理路径；草案要求两种安排都测。为让实验可重复，测试从 RTR、VRP、BGP 已同步的状态出发，先预热设备，并建议关闭或限制日志、实时遥测和干扰测试的后台任务。安静实验室能比较算法，却不能替正在记录路由事件的生产网承诺延迟。生产配置应单独复测，草案没有给出一个可以直接填进容量表的“遥测损耗百分比”。

这份草案没有实测赢家，也没有声称发生过事故。它做了一件更有用的事：让一只秒表必须亮出起跑线。决定 ROV 容量时，主数字应从相关 RTR 更新送出算到 FIB 稳定；安装后的短数字留给故障定位。两只表和负载必须同页出现。

ROV 测试草案第 00 版 · RFC 8210 · RFC 6811