| Internet-Draft | BMP RIB Synchronization | September 2026 |
| Geng & Zhuang | Expires 3 April 2027 | [Page] |
The BGP Monitoring Protocol (BMP) provides full visibility into BGP Routing Information Base (RIB) state across routers and collectors. However, transient network faults, process restarts, or buffer overflows can cause data inconsistencies between the BMP sender's authoritative RIB and the collector's stored view. Existing recovery requires tearing down BMP sessions or re-exporting all peers, introducing severe operational disruption.¶
This document defines a new BMP message type, the BMP Route-Refresh message. It encapsulated standard BGP Route-Refresh and Enhanced Route-Refresh semantics within BMP to enable fine-grained, non- disruptive, and targeted per-peer or per-AFI/SAFI RIB view re-synchronization.¶
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 [RFC2119][RFC8174] when, and only when, they appear in all capitals, as shown here.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 3 April 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
The BGP [RFC4271] Monitoring Protocol (BMP) [RFC7854] is widely deployed to stream BGP data—including Adj-RIB-In [RFC7854], Adj-RIB-Out [RFC8671], and Loc-RIB [RFC9069]—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 [RFC2918] and Enhanced Route-Refresh (BoRR/EoRR) [RFC7313] 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.¶
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 [RFC7854].¶
The payload of this message encapsulates a 4-octet ROUTE-REFRESH PDU as defined in [RFC2918] and updated by [RFC7313]:¶
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI | Sub-Type | SAFI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: BMP Route-Refresh Message Payload
¶
Fields:¶
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:¶
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:¶
BMP Sender BMP Collector
~ ~
| ------- BMP BoRR ---------> | 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 [RFC7854].¶
IANA is requested to allocate a new message type from the "BMP Message Types" registry:¶
+------+--------------------------+---------------+ | Type | Description | Reference | +------+--------------------------+---------------+ | TBD1 | BMP Route-Refresh Message| This document | +------+--------------------------+---------------+¶
TBD¶