Summary

  • IETF 的个人草案拟在 BMP 统计报告里增加十类 BGP 消息计数，分别记录 UPDATE、KEEPALIVE、NOTIFICATION、ROUTE-REFRESH 和全部消息的收发量；数的是协议消息，不是前缀。
  • 草案要求 Peer Down 事件本身不得清零累计计数。进程重启、删除邻居、人工清除或路由处理器切换则可能重置计数，监控端必须辨别两种事件。

最后一次路由快照可以很安静，中间的邻居却未必安静。同一个前缀撤回再发布，表项数可能回到原位，UPDATE 消息已经跑了一圈。RFC 7854定义的 BMP 能发送路由视图、会话升降和统计报告，但现有统计主要给出表占用量及某些特定的 UPDATE 处理结果，缺少各类 BGP 消息的总数。

10 月 29 日的 IETF 记录把这份文件列为个人 Internet-Draft。作者提出五组双向计数：UPDATE、KEEPALIVE、NOTIFICATION、ROUTE-REFRESH，以及全部 BGP PDU。UPDATE 和总消息数用 64 位；其余用 32 位。监控站由此可以在同一条 BMP 数据流上并排看到路由状态与消息负荷。一个 UPDATE 可承载多个 NLRI，BMP 路由监控导出的条数也不等于 BGP PDU 的条数。

真正尖锐的规则写在断线之后。草案规定，发出 Peer Down 本身不能重置这些计数。因此邻居重新建立会话后，NOTIFICATION 的累计值还能提示此前发生过多少次这类消息，即使监控站错过了单次断线报告。Peer Down 留下具体一次关闭的原因；累计计数留下时间跨度内的数量。若监控软件见到邻居重连就从零算起，反而抹掉了草案打算保留的历史。

另一种中断必须认真对待。设备进程重启、删除邻居、人工清除计数或路由处理器切换，都可能让计数器重新开始。草案要求新的 BMP Initiation 被视为计数不连续；单纯 Peer Down 接 Peer Up 则不是。只靠“数值下降了没有”仍会漏报：清零后的繁忙会话可能在下一次采样前超过旧值。草案没有计数不连续时间字段，因此两次报告之间的人工清除要靠其他设备记录来核实。某次报告没带某项统计，含义是未提供，绝非零。

IANA 的 BMP 参数表仍把这些新类型所在范围列作未分配；草案里十个编号都是 TBD。这是一套待讨论的测量语义，不能说成设备已经按正式编号上线。若要证明监控产品真的接得上这条历史，需要一份命名设备的轨迹：邻居掉线、设备重启、逐次 BMP 报告，以及计数重置的独立记录。