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

Status of This Memo

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 16 September 2026.¶

Copyright Notice

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.¶

Table of Contents

1. Introduction

The BGP Monitoring Protocol (BMP), defined primarily in [RFC7854] 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 [RFC9069], Adj-RIB-In [RFC7854], and Adj-RIB-Out [RFC8671]), 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.¶

2. 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 [RFC2918] and updated by [RFC7313], and its format is as follows:¶

• Type: 5 - ROUTE-REFRESH¶

• Message Format: One <AFI, Sub-Type, SAFI> tuple encoded as:¶

    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      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The meaning, usage, and encoding of this <AFI, Sub-Type, SAFI> tuple are defined in [RFC2918] and updated by [RFC7313] as follows:¶

• AFI - Address Family Identifier (2 octets)¶

• Sub-Type - Message Subtype (1 octet):¶

  • 0 - Normal route refresh request [RFC2918] with/without Outbound Route Filtering (ORF) [RFC5291]¶

  • 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).¶

  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
     |                             |
     ~                             ~

3. 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.¶

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              Type             |             SubType           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              Flags            |             Length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              AFI1             |      Res.     |     SAFI1     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              AFI2             |      Res.     |     SAFI2     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             ......                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              AFIn             |      Res.     |     SAFIn     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              Type             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              Flags            |             Length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Stat Type 1         |           Stat Type 2         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             ......                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Stat Type n-1       |           Stat Type n         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   BMP Collector
      |
      |
      |                 BGP Session
   Router1(BMP Sender)----------------Router2

BMP Sender                    BMP Collector
   ~                             ~
   |------ Initial Export -------> | Sender Sends Route Monitoring
   |                               |  messages for IPv4 unicast,
   |                               |  IPv4 multicast and IPv4
   |                               |  labeled unicast address
   |                               |  families
   |                               | Collector stores the RIB info
   |                               |  for the Sender

BMP Sender                    BMP Collector
   |-MO with(AFI 1/SAFI 2) disable-| Sender sends an MO message
   |                               |  to Collector
   |                               | Collector purges the IPv4
   |                               |  multicast RIB view of the
   |                               |  specific BGP peer

BMP Sender                    BMP Collector
   |-MO with(AFI 1/SAFI 4) disable-| Sender sends an MO message
   |                               |  to Collector
   |                               | Collector purges the IPv4
   |                               |  labeled unicast RIB view
   |                               |  of the specific BGP peer
   |                               |

BMP Sender                    BMP Collector
   |-MO with(AFI 1/SAFI 2) enabled-| Sender sends an MO message
   |                               |  to Collector
   |-------BMP RM(AFI 1/SAFI 2)--> | Sender sends zero or more
   |                               |  Route Monitoring Messages
   |                               |  for theIPv4 multicast
   |                               |  address family of the
   |                               |  specific BGP peer
   |                               | Collector stores the RIB
   |                               |  info for IPv4 multicast
   |                               |  address family of the
   |                               |  specific BGP peer

4. 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.¶

5. Security Considerations of Inter-domain SPD

The same considerations as in Section 11 of [RFC7854] 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.¶

6. Acknowledgements

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

7. References

Authors' Addresses