



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 <AFI, Sub-Type, SAFI> 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 <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).

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,
              <https://www.rfc-editor.org/info/rfc2918>.

   [RFC7313]  Patel, K., Chen, E., and B. Venkatachalapathy, "Enhanced
              Route Refresh Capability for BGP-4", RFC 7313,
              DOI 10.17487/RFC7313, July 2014,
              <https://www.rfc-editor.org/info/rfc7313>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

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, <https://www.rfc-editor.org/info/rfc5291>.

   [RFC7854]  Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP
              Monitoring Protocol (BMP)", RFC 7854,
              DOI 10.17487/RFC7854, June 2016,
              <https://www.rfc-editor.org/info/rfc7854>.







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, <https://www.rfc-editor.org/info/rfc8671>.

   [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,
              <https://www.rfc-editor.org/info/rfc9069>.

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]
