BGP Monitoring Protocol (BMP) Enhancements for RIB View Synchronization and Monitoring Options Notification

Introduction The BGP Monitoring Protocol (BMP), defined primarily in and extended by subsequent specifications, enables a BMP collector (monitoring station) to retrieve a comprehensive set of BGP-related data from a BMP sender (typically a BGP-enabled router). This data includes per-address-family Routing Information Base (RIB) entries (covering Loc-RIB , Adj-RIB-In , and Adj-RIB-Out ), runtime BGP statistics, events, and peer session state information. By ingesting this real-time and historical data, the BMP collector gains full visibility into the BGP routing state and operational status of the monitored router, supporting use cases such as routing troubleshooting, traffic engineering, security monitoring, and network state auditing. BMP has been widely deployed in production networks, serving as a critical tool for large-scale BGP network operations. Despite its widespread adoption and proven utility, existing BMP implementations and the base protocol specification face two notable limitations in practical deployment scenarios, which hinder reliable and consistent monitoring of BGP state. These gaps are detailed below:

RIB View Inconsistency Without Non-Disruptive Resolution: In production networks, message loss, router process restarts, or temporary session interruptions between the BMP sender and collector can lead to a mismatch between the BGP RIB view maintained by the sender and the corresponding data set stored by the collector. The current BMP protocol lacks a standardized mechanism to perform targeted, non-disruptive RIB synchronization between the sender and collector. Existing recovery approaches often require full re-synchronization or manual intervention, which introduces unnecessary overhead, disrupts ongoing monitoring flows, and delays the resolution of state inconsistencies.
Lack of Monitoring Options Notification Mechanism: Operators commonly configure the BMP sender to adjust the set of information types reported to the collector based on network requirements, resource constraints, or operational policies — for example, enabling or disabling specific RIB type reporting or statistic collection. The current BMP specification does not define a dedicated message type for the sender to explicitly notify the collector of active, disabled, or modified monitoring configuration options. As a result, the collector has no standardized way to identify which data types are currently being transmitted, which previously reported data types have been ceased, and which entries in its local database are now stale or invalid. This mismatch can lead to the collector retaining obsolete BGP routing information, compromising the accuracy and reliability of monitoring and analysis workflows.

To address these two critical operational gaps, this document defines two new, backward-compatible BGP Monitoring Protocol message types. These extensions are designed to integrate seamlessly with existing BMP deployments and resolve the identified limitations without disrupting normal BMP traffic flows or requiring invasive changes to deployed router and collector systems. First, this document defines a new BMP Route-Refresh message type (assigned type code TBD1). This message type is intended to enable controlled, non-disruptive synchronization of the full or targeted BGP RIB view from the BMP sender to the BMP collector. It facilitates on-demand correction of BGP RIB inconsistencies, allowing the collector to reconcile its local state with the authoritative RIB data on the sender without interrupting ongoing peer monitoring or route reporting functions. Second, this document defines a new BMP Monitoring Options (MO) message type (assigned type code TBD2). This message type serves as a standardized notification and synchronization mechanism for monitoring configuration between the sender and collector. The BMP sender transmits the MO message to inform the collector of the exact set of enabled monitoring options currently active on the sender. By receiving and processing MO messages, the BMP collector can clearly identify which BGP information types are expected to be received, which active reporting streams remain valid, and which previously stored data entries are no longer updated and should be marked as stale or purged. This ensures the collector maintains an accurate, up-to-date view of the monitored data set and eliminates the retention of invalid or obsolete BGP information.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

BMP Route-Refresh message This document defines a new BMP Route-Refresh message type (TBD1) that is used to synchronize the RIB view from the BMP sender to the BMP collector. Following the common BMP header and per-peer header is a Route-Refresh PDU. The Route-Refresh PDU is a ROUTE-REFRESH message defined in and updated by , and its format is as follows:

Type: 5 - ROUTE-REFRESH
Message Format: One <AFI, Sub-Type, SAFI> tuple encoded as:

ROUTE-REFRESH Message The meaning, usage, and encoding of this <AFI, Sub-Type, SAFI> tuple are defined in and updated by as follows:

AFI - Address Family Identifier (2 octets)
Sub-Type - Message Subtype (1 octet):
- 0 - Normal route refresh request with/without Outbound Route Filtering (ORF)
- 1 - Demarcation of the beginning of a route refresh (BoRR) operation
- 2 - Demarcation of the ending of a route refresh (EoRR) operation
- 255 - Reserved
SAFI - Subsequent Address Family Identifier (1 octet).

Example of using BMP Route-Refresh messages The sequences of BMP message transmission are shown as follows:

An example of using BMP Route-Refresh messages | Sender notifies BoRR operation | | | | Collector marks the routes of | | the specific RIB view as | | stale/historical or purges | | them directly | | | ------- BMP RM Msg.-------> | Sender sends zero or more | --------........----------> | Route Monitoring Messages for | ------- BMP RM Msg.-------> | the specific RIB view | | Collector uses the new routes | | to update the stale/historical | | routes | ------- BMP EoRR ---------> | Sender notifies EoRR operation | | | | Collector purges the routes | | remaining the stale/historical | | state | | ~ ~ ]]>

BMP Monitoring Options message This document defines a new Monitoring Options (MO) message type (TBD2) that is used to synchronize the monitoring options from the BMP sender to BMP collector. Following the common BMP header and per-peer header is a BMP Monitoring Options PDU. Four types of BMP Monitoring Options PDUs are defined for Adj-RIB-In, Adj-RIB-Out, Loc-RIB, and Stats, respectively.

BMP Monitoring Options of RIBs The BMP Monitoring Options PDU is defined as follows:

The BMP Monitoring Options PDU Where:

Type - 2 octets, It indicates as follows:
- 1 - Adj-RIB-In
- 2 - Adj-RIB-Out
- 3 - Loc-RIB
SubType - 2 octets, It indicates as follows:
- 1 - pre-policy
- 2 - post-policy
Flags - 2 octets, the least significant bit of Flags Indicates whether the options are enabled or disabled, and other bits are reserved.
Length - 2 octets
The list of (AFI, SAFI) follows the Length field.
- AFI - Address Family Identifier (2 octets)
- SAFI - Subsequent Address Family Identifier (1 octet)
- Res. - Reserved field that will be set Zero (1 octet)

BMP Monitoring Option of Stats

The BMP Monitoring Options PDU Where:

Type - 2 octets, It indicates as follows:
- 4 - Stats
Flags - 2 octets, the least significant bit of Flags Indicates whether the options are enabled or disabled, and other bits are reserved.
Length - 2 octets
The list of Stat Types follows the Length field.
- Stat Type - Defines the type of the statistic . (2 octets)

Example of using BMP Monitoring Options message In the following scenario, a BGP session is established between Router1 and Router2, and IPv4 unicast, IPv4 multicast, and IPv4 labeled unicast address families are enabled on both the BGP speakers. The two BGP speakers exchange IPv4 unicast, IPv4 multicast, and IPv4 labeled unicast address family routes. Router1 as the BMP Sender sends BMP messages to the BMP Collector.

BGP Monitoring Example Sender initiates the BMP protocol with the Collector:

Sender disabled the monitoring on IPv4 multicast address family Sender disabled the monitoring on IPv4 labeled unicast address family:

Sender disabled the monitoring on IPv4 labeled unicast address family Sender enabled the monitoring on IPv4 multicast address family:

IANA Considerations This document requests IANA to allocate two new, unused type codes from the BMP Message Type registry for the extensions defined herein, with the following formal registration details: 1.Message Type Code1: TBD1

Message Name: BMP Route-Refresh Message
Reference: This document
Description: A non-disruptive message type used to synchronize BGP RIB views between a BMP sender (router) and BMP collector, enabling resolution of RIB state inconsistencies without interrupting ongoing BMP monitoring sessions.

2.Message Type Code2: TBD2

Message Name: BMP Monitoring Options (MO) Message
Reference: This document
Description: A notification message type used by a BMP sender to explicitly inform a BMP collector of active, disabled, or modified monitoring reporting parameters, ensuring the collector maintains accurate and up-to-date awareness of valid BMP data streams.

Security Considerations of Inter-domain SPD The same considerations as in Section 11 of apply to this document. Implementations of this protocol SHOULD require that sessions only be established with authorized and trusted monitoring devices. It is also believed that this document does not introduce any additional security considerations.

Acknowledgements The authors would like to acknowledge the review and inputs from xxx.