摘要

  • draft-ietf-idr-bgp-rpki-yang-02 在 BGP 的五个 RIB 位置提供来源验证状态计数。YANG 路径、邻居和地址族共同界定了这次观测，脱离上下文的数字没有同样含义。
  • 两个计数可以完全相同，却对应不同路由。来源验证也不等于最优路径资格、实际选路、对外通告、对端接受或真实转发。

交接班最容易误读的数字，往往不是错误数字，而是正确回答了一个过小问题的数字。

假设维护前有 10,000 条 RPKI 来源验证为有效的路由，维护后仍是 10,000。监控没有报警，趋势线平得近乎完美。可如果原集合中的一个前缀消失，同时另一个前缀进入，总数不会变。若消失的是关键客户网段，而补进来的是无关路由，业务风险已经变化，仪表盘却仍然保持绿色。

9 月 30 日发布的 draft-ietf-idr-bgp-rpki-yang-02 把这个问题照得很清楚。该 IDR 工作组草案为 BGP 中与 RPKI 有关的信息定义 YANG 模型，分别覆盖来源 AS 验证、BGPsec 和 ASPA。来源验证部分在五个明确的处理位置上提供未验证、未知、无效和有效四类 gauge32 计数。

这是一项重要的可观测性建设，但可观测不等于证明。领导层若把一个计数扩大解释为“路由结果正常”，就跨越了模型并未提供的证据边界。

五个位置代表五个不同问题

草案把统计数据挂在 adj-rib-in-pre、adj-rib-in-post、loc-rib、adj-rib-out-pre 和 adj-rib-out-post。IPv4 与 IPv6 各有自己的路径。

这些名称不是实现细节。入站策略前的 RIB 表示邻居送来了什么；入站策略后的 RIB 表示本地策略留下了什么；本地 RIB 表示路由器形成的本地选择视图；出站策略前的 RIB 表示准备面向某个邻居处理的候选内容；出站策略后的 RIB 才表示通过该邻居出站策略的集合。

因此，入站前看到 20 条无效路由，并不能证明 20 条都进入了本地选择。loc-rib 中有 10,000 条有效路由，也不能证明某个特定邻居收到了这 10,000 条。出站策略后仍有 10,000 条，更不能证明对端接受、更不能证明转发芯片已经把数据包送上了预期链路。

YANG 路径本身就是证据的一部分。把路径从图表标题里删掉，看似让界面更简洁，实际上删除了数字成立的边界。

邻居和 AFI/SAFI 同样不能省略。把多个上游合并后，总量可能保持不变，但流量依赖已经从一个故障域转移到另一个故障域；IPv4 正常也不能替 IPv6 作证。全球总量的平稳，有时只是多个局部变化互相抵消。

集合大小相同，不代表集合成员相同

gauge32 提供的是某一时刻的数量，不是路由清单，也不是路由清单的指纹。

这不是计数器的缺陷，而是数据类型的边界。两个集合可以有同样数量的成员，却没有同样的成员。某条路由退出、另一条路由进入时，计数可以完全不动；策略也可能在不同类别的前缀之间完成大规模替换，最后留下同样的总量。

真正的错误发生在解释层：把基数稳定误写成成员连续。

如果变更目标是“关键路由不能丢”，就必须另外保存集合身份。大规模环境可以对规范化后的前缀、来源 AS、AS_PATH、下一跳等关键属性生成稳定摘要；关键客户和基础设施前缀则应保留明确的成员检查。采用何种表示方式取决于规模，但证明义务不变：收据必须能回答“数的是谁”。

采样时间也会改变结论。冻结的草案没有承诺五个独立路径能组成一个事务级同步快照。收敛期间，02:00:01 读取入站阶段，02:00:08 再读取出站阶段，可能制造出并不存在的长期差异，也可能错过短暂但关键的差异。可靠记录应同时保存采样窗口、同步方法和一致性假设。

“有效”只回答来源授权问题

RPKI 来源验证的核心问题，是一条 BGP 路由的前缀和来源 AS 是否与经过验证的 ROA 载荷相符。RFC 6811 建立基础，RFC 8481 进一步澄清哪些路由接受验证，并把验证与未配置的策略动作区分开。

这个问题很重要，但它很窄。

来源有效不等于低时延，不等于商业上首选，不等于没有路由泄漏，也不等于 BGPsec 或 ASPA 的结果为有效。它不证明 RPKI 缓存数据在读取监控时足够新，不证明这条路由赢得最优路径，不证明出站策略允许发送，不证明邻居接受，更不证明数据平面真的按该路径转发。

草案之所以定义三个模型，而不是一个万能的“安全”开关，正是因为三种机制处理的断言不同。把它们压成一个绿色盾牌，会丢掉模型主动保留的差异。

计数旁边还有一组独立控制

对于管理者，草案中最值得注意的不只是统计叶子，而是那些能够改变结果的配置叶子。

来源验证可按 IPv4 或 IPv6 单独启用，并可通过 eligible-prefix-policy 限定适用前缀。路由选择还有自己的开关，决定来源验证状态是否参与最优路径计算。allow-invalid 和 allow-not-found 又分别决定无效与未找到状态是否仍可进入候选，且还可能受另一项前缀策略约束。

通告验证状态是另一件事。模型可以按 RFC 8097 向邻居发送来源验证状态扩展社区，并用专门策略限定范围。出口处理又是独立决策：可以选择是否在 BGP 出口阶段考虑验证状态、是否允许未找到路由发送，并通过出口专用策略继续限定，相关边界参考 RFC 8893。

所以，相同的验证状态分布完全可能对应不同的路由行为。只要 allow-invalid、allow-not-found、前缀适用策略或出口策略发生变化，哪一些路由进入选择、哪一些路由发给邻居就可能变化，而“有效路由总数”仍保持不动。

这也是为什么截图不能充当审计记录。有效的收据必须绑定实际生效的配置和策略版本，而不只是控制器里想要下发的配置。RFC 8342 的 NMDA 架构明确区分配置值与设备实际使用的运行值；处理延迟、协议交互或硬件状态都可能让二者暂时或持续不同。

不要把绿色方块做大，要把证据链补齐

计数仍然有价值。正确做法不是弃用计数，而是把它放进一条边界清楚的收据链。

  1. 验证输入收据： 记录依赖方或缓存来源、数据新鲜度，以及 VRP、路由器密钥或 ASPA 数据集指纹。
  2. 生效配置收据： 记录设备与软件身份、地址族、邻居、验证开关、选路与出口开关、策略标识及运行配置版本。
  3. 阶段计数收据： 记录完整 YANG 路径、阶段、状态、数值、邻居、AFI/SAFI、时间和采样一致性方法。
  4. 路由集合收据： 为该阶段的准确成员保留摘要、受控清单或关键前缀成员证明。
  5. 选路收据： 记录候选集合、验证相关资格、最终胜出路由以及解释该结果所需的其他输入。
  6. 出口收据： 保存面向特定邻居的策略后集合，以及实际发出的 UPDATE 或撤回。
  7. 对端接受收据： 证明对端收到并按照自己的策略接受该变化。
  8. 结果收据： 在有边界的时间窗内验证转发路径、可达性和预期业务结果。

前一步不能自动证明后一步。新鲜的验证数据不能证明策略已经生效；正确计数不能说明成员；成员集合不能证明选路；选路不能证明出口；出口不能证明对端接受；对端接受仍不能证明业务流量成功。

这条链也会显著改善故障定位。若有效总数稳定而服务失败，团队可以寻找第一处发生偏离的边界，而不是争论“监控到底准不准”。很多时候监控对自己测量的小问题完全准确，只是没有回答领导层附加的大问题。

这是一份草案，不是部署证明

Datatracker 将第 02 版记录为 IDR 工作组的活跃标准轨 Internet-Draft，工作组状态为 I-D Exists。它不是 RFC。冻结来源也没有证明任何指定厂商已经实现，更没有证明任何生产网络已经部署这些路径。

这个状态边界不应被淡化。采购、合规或董事会材料不能把模型写成已经普遍存在的能力。但运营团队也不必等到统一实现以后才改善证据设计。现有遥测完全可以先保存阶段、邻居、地址族、策略版本和集合身份。草案提供的是一个有希望的共同形状，证据需求早已存在。

运行中的系统决定数字能证明什么

Heng Lu 关于“最低限度初始规范、未来决策本地化与自愿采用”以及 Running-Code Primacy 的论述，提供了合适的分析框架。共同层可以规定确定性的验证规则，具体选路与出口仍由运行系统的参与者在本地决定。文档发布不会自动变成运行事实；实现、配置、验证和实际使用才会。

套用到这里，“来源有效”是一项在明确输入下产生的有限事实，而不是替本地选路和出口策略作决定的中央许可。管理模型应帮助参与者暴露并核验这些本地决策，而不是假装一个总数能够代表整张网络。

下一次变更评审，领导层应把问题改成：不是“有效路由计数是否保持绿色”，而是“哪一些路由在什么阶段、使用哪一版实际策略被选择并通告，数据包随后做了什么”。

前一个问题得到一块绿色方砖。后一个问题才得到可追溯的运行收据。

来源