Summary

  • draft-geng-grow-bmp-monitor-options-00 proposes an in-band Enable or Disable declaration for BMP RIB views and statistics. Revision 00 is an individual work-in-progress draft; its message type remains TBD2.
  • A RIB Disable is operationally destructive: the collector is told to purge the stored <Peer, AFI, SAFI> view immediately. Mutual authentication protects the channel, but safe deletion also needs exact scope, operator authority, an auditable receipt and a defined test for when a re-enabled view is complete again.

A route collector has received no update for forty minutes. That could mean the routing state is stable. It could mean the router stopped exporting one address family. Under the base BGP Monitoring Protocol, those two conditions can look alike while the collector continues to present an old view as current.

BMP Extension for Monitoring Options (MO) Notification, dated 30 September 2026, addresses that ambiguity. The draft proposes a new message by which a BMP sender enumerates monitoring that is enabled or disabled. It is a sensible repair to an observability gap. It is also a change in authority: the Disable bit does not merely explain silence. For a RIB view, it instructs the collector to delete state.

Revision 00 is an individual Internet-Draft with intended Standards Track status. It expires on 3 April 2027. It is not an RFC, working-group consensus or evidence that an implementation exists. Its proposed BMP message type is still TBD2 and awaits any IANA decision.

Silence needed a name

RFC 7854 gave operators a structured stream of BGP observations: peer state, route monitoring and statistics, later extended to Adj-RIB-Out and the Local RIB. But the protocol has no in-band declaration that an operator changed what the sender monitors.

Without that declaration, the collector cannot safely infer why a stream stopped. No new routes may have appeared. A filter may have changed. A particular AFI/SAFI may have been disabled. The TCP session can remain healthy in all three cases. Silence alone carries no cause.

The proposed Monitoring Options message makes the administrative claim explicit. A RIB Options PDU identifies Adj-RIB-In, Adj-RIB-Out or Loc-RIB; distinguishes pre-policy from post-policy where applicable; carries an Enable or Disable flag; and lists one or more AFI/SAFI pairs. The message follows the BMP Common Header and may include a Per-Peer Header. A separate Statistics form names the statistic types affected.

Those fields are not decoration. They define the blast radius. “Monitoring disabled” is too coarse to be an audit record. A defensible record needs the sender, peer, RIB surface, policy stage, address family, subsequent address family and time.

The notification changes the database

The draft's operating sequence is direct. When an operator disables monitoring for a family, the BMP sender must immediately send a Disable message. When the collector receives it, the collector must immediately purge all stored RIB entries associated with the disabled <Peer, AFI, SAFI> view.

That requirement solves the stale-view problem by refusing to leave an unobserved view looking current. Yet it changes the security category of the message. A status notification can be logged and displayed. A purge instruction destroys the collector's live representation. It therefore needs the controls of a destructive administrative operation even if the wire format calls it an option.

The distinction is especially important because BMP data feeds other systems. Topology analytics, route-leak detection, policy checks and forensic searches may all read the collector. A correctly scoped purge prevents those consumers from trusting stale routes. An incorrectly scoped purge can blind them. In both cases a green BMP session indicator can survive.

The draft itself recognizes the danger. Its security section warns that unauthorized MO messages could trick a collector into purging its entire monitored database with fake Disable options. It requires mutual authentication and protected transport such as TLS.

TLS is necessary, but its receipt answers a narrower question: did this protected session reach the authenticated peer without ordinary in-transit tampering? It does not show which human approved the change. It does not prove that automation selected the right AFI/SAFI or peer. It does not make a compromised but authenticated router trustworthy. Authentication of the messenger is not authorization of every deletion the messenger can name.

Immediate hygiene and durable evidence are different jobs

The phrase “must immediately purge” should not be confused with “must erase every historical trace.” Revision 00 specifies the collector's live RIB behavior. It does not set a complete archival or evidence-retention policy.

That leaves a useful local design choice. The live view can be removed at once so no consumer mistakes it for current observation, while an immutable pre-change digest, scoped change record or historical copy remains under a separate retention policy. The archive must be labelled historical, not quietly served as the live RIB. Conversely, a deletion log that records only “success” is weak evidence if it cannot identify which view and how many entries changed.

A strong receipt binds the operator request to the authenticated session and the wire tuple, records the rows removed and those deliberately untouched, and preserves the transaction result. It should also reveal malformed or over-broad requests before they mutate state. An authenticated sender should receive no more destructive scope than its operational role needs.

Enable starts recovery; it does not certify completion

When monitoring is re-enabled, the proposed sequence sends an Enable notification and then resumes Route Monitoring messages. The example says the collector restores the view as those messages arrive.

But the draft does not define a beginning-of-snapshot marker, an expected route count, an end marker or a rule for when the restored view becomes complete enough for reliance. The first new route proves only that ingestion restarted. It does not prove that every current route has arrived or that no gap occurred between deletion and reconstruction.

This matters because a partial fresh view can look more credible than a plainly disabled one. If downstream alarms are reactivated at Enable receipt, they may reason over the first slice of a rebuilding table. The system needs an explicit local state such as disabled, rebuilding and current, with the last transition tied to evidence.

A companion individual draft, draft-geng-grow-bmp-rr-sync-00, proposes a separate BMP Route-Refresh mechanism with Beginning and End of Route Refresh markers around a complete stream for a scoped view. That is evidence that synchronization is a distinct protocol problem. It is not part of Monitoring Options, is not an approved standard, and cannot be assumed to exist wherever MO might be implemented.

A deletion receipt is a chain, not a checkbox

The operational proof can be made concrete:

  1. retain the exact draft revision and implementation behavior;
  2. identify the mutually authenticated sender and collector;
  3. bind an approved operator change to the sender's configuration transition;
  4. decode the applicable peer, RIB type, policy subtype and AFI/SAFI scope;
  5. validate that the sender is allowed to mutate precisely that scope;
  6. record the live entries purged and the entries left intact;
  7. preserve historical evidence separately from the live view;
  8. accept a matching Enable and observe Route Monitoring resume;
  9. hold the view in rebuilding state until a declared completeness test passes;
  10. only then restore downstream reliance.

No step proves the next. A valid certificate does not prove a correct AFI. A correctly formed Disable does not prove an approved change. A successful purge does not prove evidence survived. An Enable does not prove the table is whole.

Heng Lu's distinction between minimum initial specification and localized future decision is exact here. The common protocol can define deterministic fields for an interoperable state declaration. It need not centralize every operator's retention, approval and reliance policy. Those decisions stay with the party that bears the risk, while running code and receipts—not publication—show whether the proposed transition actually works.

The draft's most useful contribution may therefore be larger than its new bit. It exposes a truth about observability systems: once a telemetry message can erase the view, it is part of the control plane of evidence.

Sources