BMP Extension for Non-Disruptive RIB View Synchronization

The BGP Monitoring Protocol (BMP) is widely deployed to stream BGP data—including Adj-RIB-In , Adj-RIB-Out , and Loc-RIB —to centralized monitoring stations (collectors). In large-scale production networks, data loss between the BMP sender (router) and collector can occur due to TCP socket queue overflows, transient collector downtime, or internal router state resets. When a mismatch occurs, the collector retains stale BGP entries, resulting in incorrect routing topology maps and security auditing failures. Currently, BMP lacks a non-disruptive, targeted re-synchronization mechanism. To recover from a single peer's state desynchronization, operators are forced to reset the entire BMP session or flap the BGP peer, which generates massive CPU and bandwidth overhead. This document addresses this gap by defining a new BMP message type: the BMP Route-Refresh Message. By integrating standard BGP Route- Refresh and Enhanced Route-Refresh (BoRR/EoRR) capabilities into BMP, the sender can demarcate and stream a clean, fresh copy of a specific RIB view (<Peer, AFI, SAFI>) without disrupting other monitored sessions or resetting TCP connections.

BoRR: Beginning of a Route Refresh EoRR: Ending of a Route Refresh

The BMP Route-Refresh message is a new BMP message type (Type = TBD1). It MUST be preceded by the Common BMP Header and the Per-Peer Header defined in . The payload of this message encapsulates a 4-octet ROUTE-REFRESH PDU as defined in and updated by :

Fields: AFI (Address Family Identifier): 2 octets. Identifies the primary address family. Sub-Type: 1 octet. Defines the operation subtype as specified in : 0: Normal Route Refresh Request / Notification 1: Beginning of Route Refresh (BoRR) 2: End of Route Refresh (EoRR) SAFI (Subsequent Address Family Identifier): 1 octet.

A BMP Sender MAY transmit a BMP Route-Refresh message under any of the following conditions: Local administrative CLI command or controller request. Internal BGP soft-reset or RIB clearing event for a specific peer. Detection of BMP socket buffer drops affecting a specific peer. When initiating a RIB re-synchronization for a given <Peer, AFI, SAFI>, the BMP Sender MUST execute the following sequence: Transmit a BMP Route-Refresh message with Sub-Type = 1 (BoRR). Stream the complete set of current active routes via standard BMP Route Monitoring (RM) messages for that <Peer, AFI, SAFI>. Transmit a BMP Route-Refresh message with Sub-Type = 2 (EoRR).

Upon receiving a BMP Route-Refresh message: If Sub-Type = 1 (BoRR): The collector MUST mark all existing routes belonging to the indicated <Peer, AFI, SAFI> in its database as "Stale" or "Historical". During Route Monitoring Ingestion: As new RM messages arrive, the collector updates matching entries, clearing the "Stale" status. If Sub-Type = 2 (EoRR): The collector MUST purge all remaining routes under that <Peer, AFI, SAFI> that are still marked as "Stale".

The sequence of BMP message transmission during a re-synchronization event is shown below:

| 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 | | ~ ~ Figure 2: Example of BMP Route-Refresh Message Exchange ]]>

An attacker manipulating BMP streams could send forged EoRR messages to force a collector to prematurely purge valid RIB state. BMP sessions MUST be protected via IPSec, TLS, or strict ACL filtering as recommended in .

IANA is requested to allocate a new message type from the "BMP Message Types" registry:

TBD