摘要

  • 2026年9月7日发布的draft-ietf-sidrops-rtr-yang第09版，新增独立的刷新间隔、Serial Query与Reset Query计数器、Router Key与ASPA计数器，以及五类较新的Error Report计数器。
  • 这些字段让路由器—缓存边界更容易观察，但不能证明故障责任归属、缓存数据是否进入本地路由策略，也不能直接衡量流量影响持续多久。
  • 这些叶节点是只读运行状态。RFC 8342把系统状态和采集统计定义为瞬时数据，因此事后再查一次设备，并不等于保存了历史。
  • 草案列出两项已知实现，但两项都写明针对draft-03，最后更新于2026年3月30日。文本没有证明它们支持第09版新增字段。
  • Daniel Kade提出“RPKI缓存状态回执”，绑定模型版本、采集时间、计数器重置纪元、会话与序列号、定时状态、错误增量及运营者动作。这是本文建议，不是草案要求。

同样是断线，协议给出的命令不同

外部仪表板很容易把所有路由器—缓存中断画成同一个红点。正在修订的RPKI-to-Router Version 2协议却区分传输故障、缓存重启和缓存关闭。

缓存预计短暂离线、并打算在客户端数据过期前恢复时，会发出Cache Restart。Cache Shutdown的含义更强：它要求客户端路由器清除从该缓存学到的数据。传输长时间停滞，则可能触发Transport Failure报告并结束会话。网络尚未应用本地路由政策之前，这三种事件的操作后果已经不同。

时间参数决定路由器还能做什么。Refresh Interval规定正常轮询节奏；Retry Interval规定查询失败后的重试；Expire Interval限定在无法成功刷新时，旧数据最多还能使用多久。所以，“会话断开”可以和“缓存数据暂时仍有效”同时成立。只报告“RPKI缓存宕机”，会丢掉最关键的状态。

第09版YANG草案把这条边界中的更多环节变成机器可读状态。这才是新闻事件；它不是现实故障报告，也不是某个实现已经合规的声明。

第09版把间隔和截止时刻拆开

08到09版的差异新增refresh-interval，表示两次周期性Serial Query之间的秒数。原有refresh-time的说明同时被改得更明确：它是下一次刷新预计发生的时刻，以百分之一秒为单位。

这项细分看似很小，却把规则与当前状态分开了。间隔来自缓存传递的策略；截止时刻是设备在一次具体交换之后算出的现场状态。若只留下一个没有时间戳的数字，后来的人无法判断路由器是在遵守间隔、重新计算截止时间，还是早已失去连接。

PDU子树还明确增加Serial Query和Reset Query计数。前者请求某个已知序列号之后的变更，后者请求完整活动数据集。Reset Query增加，可能意味着系统进入了不同于日常增量轮询的恢复路径。Router Key和ASPA也获得专门计数器，对应Version 2协议新增的数据类别。

错误子树则补齐新词汇：ASPA提供者列表错误、传输故障、顺序错误、缓存重启和缓存关闭。旧字段的描述也被明确绑定到Error Report代码。拟议管理面因此可以表示代码0至13，而不是让Version 2新增状态停留在模型之外。

但字段名称不是裁决。ASPA错误计数上升，不代表错误列表已经影响选路。Reset Query不解释为何发生全量同步。收到Cache Restart，也不证明缓存最终在Expire期限前回来了。

每个计数器都必须有起点

草案把错误字段描述为与缓存服务器“交换”的Error Report PDU计数，并未把发送与接收分开。即使数字完全准确，它也不能独立归责。

数字本身也不携带时间基线。“4”可能是设备开机以来四次、管理进程重启以来四次、板卡更换以来四次，或者采集器上线以来四次。YANG类型从零开始计数，但它不会自动生成不可追加修改的事件日志。

底层标准正好说明了这条边界。RFC 7950用config false标识状态数据。RFC 8342把只读状态和采集统计归入系统状态，并明确这类状态是瞬时的，会随着内部组件或外部系统的交互而变化。运行状态的价值在于显示设备此刻正在使用什么；它不会替运营者保存昨天。

因此，每次快照至少需要携带模块版本、采集时间、采集成功或失败、计数器重置纪元、受限的缓存与会话标识、协议版本、Session ID、当前序列号、最后一次End of Data，以及Refresh、Retry、Expire状态。缺少这些上下文，两个数值甚至不一定具备可比性。

运行代码也有版本号

第09版保留实现状态章节，这是一项有用的证据纪律。它列出Juniper Networks（HPE）和New H3C Technologies，但边界写得同样清楚：两项记录都标为Draft-03，最后更新于2026年3月30日，也都没有提供具体实现经验。

这些记录只能支持一个有限结论：实施者曾报告针对早期模型的工作。它们不能证明第09版新字段已经可用、互操作、默认开启或进入生产。若报道“已有实现”却删掉版本号，恰好抹去了这份证据最有用的部分。

制度状态也必须保留版本。Datatracker把该文件列为SIDROPS工作组的活跃互联网草案，拟进入Standards Track；IESG状态为I-D Exists，没有列出document shepherd，consensus boilerplate仍为未知。工作组接管意味着它比个人投稿多了一层流程背景，但它尚未成为RFC，也没有完成IETF审查。

来源