Summary

  • An individual IETF draft proposes ten BMP statistics for received and sent BGP UPDATE, KEEPALIVE, NOTIFICATION, ROUTE-REFRESH and total messages. Each counts protocol messages, not routes or prefixes.
  • A Peer Down event alone must leave those cumulative counters intact. A process restart, neighbor removal, operator clear or routing-processor failover can reset them, so a monitoring station must separate a session flap from a counter discontinuity.

The peer is back in Established. Its route table looks much like it did an hour ago. That view cannot say how hard the control plane worked to get there. A prefix may have been withdrawn and announced again; the final table size stays put while UPDATE messages accumulate. RFC 7854 gives BMP route views, statistics and Peer Up/Down reports, but the existing statistics count selected outcomes and table occupancy rather than every BGP message type.

The 29 October submission record identifies the new text as an individual Internet-Draft. It proposes five received/sent pairs: UPDATE, KEEPALIVE, NOTIFICATION, ROUTE-REFRESH and all BGP PDUs. UPDATE and total would use 64-bit counters; the other pairs would use 32-bit counters. A monitoring station could see message load beside the route view on one BMP feed. It should never turn a PDU count into a prefix count: one UPDATE can carry multiple NLRIs, and a BMP route-monitoring export may represent a different slice of the exchange.

The draft's most consequential sentence is about survival. Generating Peer Down must not itself reset the proposed counters. NOTIFICATION counts then remain available after the neighbor returns, including for a monitoring station that missed the individual teardown report. Peer Down still records the reason for a particular closure; the counter records a cumulative number. Treating the return to Established as a fresh zero would throw away the very history the proposal is trying to preserve.

But permanence has limits. The speaker may reset its counters after a process restart, neighbor deletion, operator clear or routing-processor failover. The draft requires a new BMP Initiation to be treated as a discontinuity, while Peer Down followed by Peer Up is not one by itself. A simple “did the number fall?” test is insufficient: after a reset, a busy session may climb past the last sampled value before the next report. The proposal has no discontinuity-time statistic, so an operator clear between reports can remain invisible unless another record supplies it. A missing statistic in one report is absent, not zero.

The IANA BMP registry lists current statistics and the unassigned range; the proposal still calls its ten types TBD1 through TBD10. It describes a possible measurement contract, not deployed counters with assigned type numbers. A trace from a named implementation showing a peer flap, a device restart, the BMP reports and the reset record would settle how reliably a collector can join these events. Until then, the proposal's operational demand is clear: preserve the count across a session event, and mark the actual break in the counting instrument.