GROW N. Geng Internet-Draft S. Zhuang Intended status: Standards Track Huawei Technologies Expires: 3 April 2027 30 September 2026 BMP Extension for Non-Disruptive RIB View Synchronization draft-geng-grow-bmp-rr-sync-00 Abstract 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. 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. 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." Geng & Zhuang Expires 3 April 2027 [Page 1] Internet-Draft BMP RIB Synchronization September 2026 This Internet-Draft will expire on 3 April 2027. 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 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. BMP Route-Refresh Message Format . . . . . . . . . . . . . . 3 4. Operational Procedures . . . . . . . . . . . . . . . . . . . 4 4.1. Sender Behavior . . . . . . . . . . . . . . . . . . . . . 4 4.2. Collector Behavior . . . . . . . . . . . . . . . . . . . 4 4.3. Example Message Sequence . . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 8.2. Informative References . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction 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. Geng & Zhuang Expires 3 April 2027 [Page 2] Internet-Draft BMP RIB Synchronization September 2026 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 () without disrupting other monitored sessions or resetting TCP connections. 2. Terminology * BoRR: Beginning of a Route Refresh * EoRR: Ending of a Route Refresh 3. BMP Route-Refresh Message Format 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: * AFI (Address Family Identifier): 2 octets. Identifies the primary address family. * Sub-Type: 1 octet. Defines the operation subtype as specified in [RFC7313]: - 0: Normal Route Refresh Request / Notification - 1: Beginning of Route Refresh (BoRR) Geng & Zhuang Expires 3 April 2027 [Page 3] Internet-Draft BMP RIB Synchronization September 2026 - 2: End of Route Refresh (EoRR) * SAFI (Subsequent Address Family Identifier): 1 octet. 4. Operational Procedures 4.1. Sender Behavior A BMP Sender MAY transmit a BMP Route-Refresh message under any of the following conditions: 1. Local administrative CLI command or controller request. 2. Internal BGP soft-reset or RIB clearing event for a specific peer. 3. Detection of BMP socket buffer drops affecting a specific peer. When initiating a RIB re-synchronization for a given , the BMP Sender MUST execute the following sequence: 1. Transmit a BMP Route-Refresh message with Sub-Type = 1 (BoRR). 2. Stream the complete set of current active routes via standard BMP Route Monitoring (RM) messages for that . 3. Transmit a BMP Route-Refresh message with Sub-Type = 2 (EoRR). 4.2. Collector Behavior Upon receiving a BMP Route-Refresh message: * If Sub-Type = 1 (BoRR): The collector MUST mark all existing routes belonging to the indicated 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 that are still marked as "Stale". Geng & Zhuang Expires 3 April 2027 [Page 4] Internet-Draft BMP RIB Synchronization September 2026 4.3. Example Message Sequence 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 5. Security Considerations 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]. 6. IANA Considerations 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 | +------+--------------------------+---------------+ Geng & Zhuang Expires 3 April 2027 [Page 5] Internet-Draft BMP RIB Synchronization September 2026 7. Acknowledgements TBD 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2918] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918, DOI 10.17487/RFC2918, September 2000, . [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, . [RFC7313] Patel, K., Chen, E., and B. Venkatachalapathy, "Enhanced Route Refresh Capability for BGP-4", RFC 7313, DOI 10.17487/RFC7313, July 2014, . [RFC7854] Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP Monitoring Protocol (BMP)", RFC 7854, DOI 10.17487/RFC7854, June 2016, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [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, . 8.2. Informative References Geng & Zhuang Expires 3 April 2027 [Page 6] Internet-Draft BMP RIB Synchronization September 2026 Authors' Addresses Nan Geng Huawei Technologies Huawei Campus, No. 156 Beiqing Road Beijing 100095 China Email: gengnan@huawei.com Shunwan Zhuang Huawei Technologies Huawei Campus, No. 156 Beiqing Road Beijing 100095 China Email: zhuangshunwan@huawei.com Geng & Zhuang Expires 3 April 2027 [Page 7]