GROW                                                             N. GengInternet-Draft                                                 S. ZhuangIntended status: Standards Track                     Huawei TechnologiesExpires: 26 February 2026                                 25 August 2025             Synchronizing BMP Monitoring Options and State             draft-geng-grow-bmp-sync-options-and-state-01Abstract   This document proposes methods to facilitate correction of BGP   Routing Information Base inconsistencies in a non-disruptive manner   from the BMP Sender to the BMP Collector.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 26 February 2026.Copyright Notice   Copyright (c) 2025 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.Geng & Zhuang           Expires 26 February 2026                [Page 1]Internet-Draft             BMP Sync Mechanism                August 2025Table of Contents   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   2   2.  BMP Route-Refresh message . . . . . . . . . . . . . . . . . .   2     2.1.  Example of using BMP Route-Refresh messages . . . . . . .   3   3.  BMP Monitoring Options message  . . . . . . . . . . . . . . .   4     3.1.  Example of using BMP Monitoring Options message . . . . .   6   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7   5.  Security Considerations of Inter-domain SPD . . . . . . . . .   8   6.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .   8   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   8   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   8     8.2.  Informative References  . . . . . . . . . . . . . . . . .   8   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   91.  Introduction   The generation of BGP Adj-RIB-In, Loc-RIB and Adj-RIB-Out comes from   BGP route exchange and route policy processing.  BGP Monitoring   Protocol (BMP) provides the monitoring of BGP Adj-RIB-In [RFC7854],   BGP Loc-RIB [RFC9069] and BGP Adj-RIB-Out [RFC8671].  The RIB view   inconsistency may occur between the BMP sender and BMP collector due   to message loss, network flapping, instability, and faults.  In this   document, we define methods to facilitate correction of BGP Routing   Information Base (RIB) inconsistencies in a non-disruptive manner   from the BMP Sender to the BMP Collector.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-REFRESHGeng & Zhuang           Expires 26 February 2026                [Page 2]Internet-Draft             BMP Sync Mechanism                August 2025   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      |      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                      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 messages transmissions shown as follows:Geng & Zhuang           Expires 26 February 2026                [Page 3]Internet-Draft             BMP Sync Mechanism                August 2025     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 messages3.  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.  The BMP Monitoring   Options PDU is defined as follows:    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     |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Geng & Zhuang           Expires 26 February 2026                [Page 4]Internet-Draft             BMP Sync Mechanism                August 2025                  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)    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 PDUGeng & Zhuang           Expires 26 February 2026                [Page 5]Internet-Draft             BMP Sync Mechanism                August 2025   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.1.  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.      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 CollectorGeng & Zhuang           Expires 26 February 2026                [Page 6]Internet-Draft             BMP Sync Mechanism                August 2025   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   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                                   family4.  IANA Considerations   TBDGeng & Zhuang           Expires 26 February 2026                [Page 7]Internet-Draft             BMP Sync Mechanism                August 20255.  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.  Contributors   The following people made significant contributions to this document:   To be added.7.  Acknowledgements   The authors would like to acknowledge the review and inputs from xxx.8.  References8.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>.8.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>.Geng & Zhuang           Expires 26 February 2026                [Page 8]Internet-Draft             BMP Sync Mechanism                August 2025   [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>.   [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.comGeng & Zhuang           Expires 26 February 2026                [Page 9]