GROW N. Geng Internet-Draft S. Zhuang Intended status: Standards Track Huawei Technologies Expires: 16 September 2026 15 March 2026 BGP Monitoring Protocol (BMP) Enhancements for RIB View Synchronization and Monitoring Options Notification draft-geng-grow-bmp-sync-options-and-state-03 Abstract The BGP Monitoring Protocol (BMP) is a widely deployed operational tool that allows BMP collectors to obtain per-address-family BGP Routing Information Base (RIB) entries, runtime statistics, events, and other critical BGP state data from BMP sender routers, enabling full visibility into BGP routing status and supporting core network operations such as troubleshooting, security monitoring, and traffic auditing. However, two key limitations exist in the current BMP specification during practical deployment. First, transient faults, message loss, or session interruptions may cause inconsistencies between the RIB views of the BMP sender and collector, and the existing protocol lacks a non-disruptive mechanism to resolve such mismatches. Second, there is no standardized notification mechanism for senders to inform collectors of modified or updated monitoring reporting options, leading collectors to store stale or invalid BGP information as reporting configurations change. This document defines two new backward-compatible BMP message types to address these issues: a Route-Refresh message for non-disruptive RIB view synchronization between senders and collectors, and a Monitoring Options (MO) message to notify collectors of active and disabled reporting parameters. These extensions enhance the reliability and accuracy of BMP-based BGP monitoring without disrupting existing deployment workflows. 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/. Geng & Zhuang Expires 16 September 2026 [Page 1] Internet-Draft BMP refresh and sync notify March 2026 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 2. BMP Route-Refresh message . . . . . . . . . . . . . . . . . . 4 2.1. Example of using BMP Route-Refresh messages . . . . . . . 5 3. BMP Monitoring Options message . . . . . . . . . . . . . . . 6 3.1. BMP Monitoring Options of RIBs . . . . . . . . . . . . . 6 3.2. BMP Monitoring Option of Stats . . . . . . . . . . . . . 8 3.3. Example of using BMP Monitoring Options message . . . . . 8 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations of Inter-domain SPD . . . . . . . . . 11 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.1. Normative References . . . . . . . . . . . . . . . . . . 11 7.2. Informative References . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 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 Geng & Zhuang Expires 16 September 2026 [Page 2] Internet-Draft BMP refresh and sync notify March 2026 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. Geng & Zhuang Expires 16 September 2026 [Page 3] Internet-Draft BMP refresh and sync notify March 2026 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. 1.1. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 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 tuple encoded as: Geng & Zhuang Expires 16 September 2026 [Page 4] Internet-Draft BMP refresh and sync notify March 2026 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: ROUTE-REFRESH Message The meaning, usage, and encoding of this 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). 2.1. Example of using BMP Route-Refresh messages The sequences of BMP message transmission are shown as follows: Geng & Zhuang Expires 16 September 2026 [Page 5] Internet-Draft BMP refresh and sync notify March 2026 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: An example of using BMP Route-Refresh messages 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. 3.1. BMP Monitoring Options of RIBs The BMP Monitoring Options PDU is defined as follows: Geng & Zhuang Expires 16 September 2026 [Page 6] Internet-Draft BMP refresh and sync notify March 2026 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: 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) Geng & Zhuang Expires 16 September 2026 [Page 7] Internet-Draft BMP refresh and sync notify March 2026 3.2. BMP Monitoring Option of Stats 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: 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 [RFC7854]. (2 octets) 3.3. 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. Geng & Zhuang Expires 16 September 2026 [Page 8] Internet-Draft BMP refresh and sync notify March 2026 BMP Collector | | | BGP Session Router1(BMP Sender)----------------Router2 Figure 5: BGP Monitoring Example Sender initiates the BMP protocol with the Collector: 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 Figure 6: Sender sends Initial Export to Collector Sender disabled the monitoring on IPv4 multicast address family: 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 Figure 7: Sender disabled the monitoring on IPv4 multicast address family Sender disabled the monitoring on IPv4 labeled unicast address family: 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 | | Figure 8: Sender disabled the monitoring on IPv4 labeled unicast address family Geng & Zhuang Expires 16 September 2026 [Page 9] Internet-Draft BMP refresh and sync notify March 2026 Sender enabled the monitoring on IPv4 multicast address family: 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 Figure 9: Sender enabled the monitoring on IPv4 multicast address family 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. Geng & Zhuang Expires 16 September 2026 [Page 10] Internet-Draft BMP refresh and sync notify March 2026 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 7.1. Normative References [RFC2918] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918, DOI 10.17487/RFC2918, September 2000, . [RFC7313] Patel, K., Chen, E., and B. Venkatachalapathy, "Enhanced Route Refresh Capability for BGP-4", RFC 7313, DOI 10.17487/RFC7313, July 2014, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . 7.2. Informative References [RFC5291] Chen, E. and Y. Rekhter, "Outbound Route Filtering Capability for BGP-4", RFC 5291, DOI 10.17487/RFC5291, August 2008, . [RFC7854] Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP Monitoring Protocol (BMP)", RFC 7854, DOI 10.17487/RFC7854, June 2016, . Geng & Zhuang Expires 16 September 2026 [Page 11] Internet-Draft BMP refresh and sync notify March 2026 [RFC8671] Evens, T., Bayraktar, S., Lucente, P., Mi, P., and S. Zhuang, "Support for Adj-RIB-Out in the BGP Monitoring Protocol (BMP)", RFC 8671, DOI 10.17487/RFC8671, November 2019, . [RFC9069] Evens, T., Bayraktar, S., Bhardwaj, M., and P. Lucente, "Support for Local RIB in the BGP Monitoring Protocol (BMP)", RFC 9069, DOI 10.17487/RFC9069, February 2022, . Authors' Addresses Nan Geng Huawei Technologies Beijing China Email: gengnan@huawei.com Shunwan Zhuang Huawei Technologies Beijing China Email: zhuangshunwan@huawei.com Geng & Zhuang Expires 16 September 2026 [Page 12]