GROW S. Zhuang Internet-Draft N. Geng Intended status: Standards Track H. Wang Expires: 19 April 2027 Huawei Technologies 16 October 2026 Monitoring BGP Parameters Using BMP draft-zhuang-grow-monitoring-bgp-parameters-03 Abstract The BGP Monitoring Protocol (BMP) is designed to monitor BGP running status, such as BGP peer relationship establishment, termination, and route updates. Without BMP, manual queries are required to obtain BGP operational status. This document defines extensions to the BMP Initiation Message to enable a BGP Monitoring Station (BMS) to discover optional BGP capabilities supported by the monitored network device, capabilities currently enabled, and default configuration parameters. 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." This Internet-Draft will expire on 19 April 2027. Zhuang, et al. Expires 19 April 2027 [Page 1] Internet-Draft BMP BGP Parameters October 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 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Extension of BMP Initiation Message . . . . . . . . . . . . . 4 4.1. Optional Parameters Supported (Type = TBD1) . . . . . . . 4 4.2. Optional Parameters Enabled (Type = TBD2) . . . . . . . . 5 4.3. Default Behavior Parameters (Type = TBD3) . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 8.2. Informative References . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction The Border Gateway Protocol (BGP) [RFC4271] is a dynamic routing protocol operating across Autonomous Systems (AS). BGP supports a variety of optional parameters [RFC5492], such as IPv4/IPv6 Unicast, Multiprotocol Extensions, Route Refresh, Outbound Route Filtering (ORF), Graceful Restart, and 4-octet AS number support. Different BGP software implementations may support different subsets of these capabilities. Furthermore, a network device typically does not enable all supported capabilities globally, but rather activates them based on specific deployment requirements. Zhuang, et al. Expires 19 April 2027 [Page 2] Internet-Draft BMP BGP Parameters October 2026 The BGP Monitoring Protocol (BMP) [RFC7854] facilitates the monitoring of BGP operational states, peer relationship lifecycles, and route updates. By connecting a router to a monitoring station, network operators can passively track BGP statistics, improving network monitoring efficiency and enabling real-time detection of operational anomalies. In existing BMP implementations, when a BGP session is established, peers negotiate optional capabilities via BGP OPEN messages. The BMP Peer Up Notification message reports these negotiated, currently active capabilities to the BMS. However, reporting only active capabilities is insufficient for advanced network management and optimization. To effectively optimize multi-vendor environments and troubleshoot interoperation issues, a BMS often needs visibility into *all* BGP capabilities supported by each monitored device, as well as its default configuration parameters. 2. Terminology This memo makes use of the terms defined in [RFC7854]. * BMP: BGP Monitoring Protocol. * BMS: BGP Monitoring Station. * Initiation Message: Reports to the monitoring server such information as the router vendor, software version, and device- level BGP capabilities. 3. Use Cases 1. BGP Optional Parameters Supported vs. Enabled: Standard BMP Peer Up notifications report only currently enabled capabilities. If all supported capabilities (both enabled and disabled) are reported to the BMS, operators gain a comprehensive view of the device's software and hardware feature readiness. For instance, if Graceful Restart (GR) is not currently enabled on a specific peer, the OPEN message omits it. However, if the BMS knows that both peers actually support GR, it can prompt or automatically trigger an operational change to enable GR, thereby enhancing network stability. Zhuang, et al. Expires 19 April 2027 [Page 3] Internet-Draft BMP BGP Parameters October 2026 2. BGP Default Behavior Parameters in Multi-Vendor Environments: In multi-vendor networks, default configurations and behaviors often differ significantly, which can lead to unexpected interoperation issues. A prime example is the default protocol preference (administrative distance) assigned to BGP routes: Vendor A might assign a default preference of 255 to eBGP, iBGP, and local BGP routes, whereas Vendor B assigns 20 for eBGP, and 200 for iBGP and local routes. Moreover, if a value like 255 is unrecognized or out-of-range for Vendor B, routes with such values may be dropped. Visibility into these default parameters via BMP allows the BMS to proactively detect and mitigate misconfigurations or preference mismatches. 4. Extension of BMP Initiation Message As described in Section 4.3 of [RFC7854], the Initiation Message provides a means for the monitored router to inform the monitoring station of its vendor, software version, and other global attributes. The Initiation Message consists of the common BMP header followed by two or more Information TLVs (Section 4.4 of [RFC7854]). This document defines three new Information TLV types to carry BGP optional parameters and default behavior parameters: * Type = TBD1: Optional Parameters Supported * Type = TBD2: Optional Parameters Enabled * Type = TBD3: Default Behavior Parameters 4.1. Optional Parameters Supported (Type = TBD1) The Information field specifies all BGP optional parameters supported by the monitored device. Each parameter is encoded as a triplet: . 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... | Parm. Type | Parm. Length | Parameter Value (variable) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... Figure 1: BGP Optional Parameters Information TLV Zhuang, et al. Expires 19 April 2027 [Page 4] Internet-Draft BMP BGP Parameters October 2026 Parameter Type is a one-octet field that unambiguously identifies individual parameters (as defined in [RFC5492]). Parameter Length is a one-octet field containing the length of the Parameter Value field in octets. Parameter Value is a variable-length field interpreted according to the Parameter Type. 4.2. Optional Parameters Enabled (Type = TBD2) The Information field specifies all BGP optional parameters currently enabled on the monitored device. The encoding format is identical to that of Type TBD1, using the triplet. 4.3. Default Behavior Parameters (Type = TBD3) The Information field contains a list of default behavior parameters, where each parameter is encoded as a sub-TLV: . 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 +-------------------------------+-------------------------------+ | Default Beh. Type | Def Beh. Length | +-------------------------------+-------------------------------+ | Default Beh. Value (variable) | ~ ~ +---------------------------------------------------------------+ Figure 2: Default Behavior Parameters sub-TLV The Default Behavior Type is a one-octet field identifying the parameter. Def Beh. Length is a one-octet field containing the length of the value field. Parameter Value is a 32-bit integer interpreted as follows: * Type = TBD4: Value of default Protocol Preference for Local route * Type = TBD5: Value of default Protocol Preference for EBGP route * Type = TBD6: Value of default Protocol Preference for IBGP route * Type = TBD7: Value of default BGP connect-retry timer (seconds) * Type = TBD8: Value of default BGP Keepalive timer (seconds) * Type = TBD9: Value of default BGP Hold Time (seconds) Zhuang, et al. Expires 19 April 2027 [Page 5] Internet-Draft BMP BGP Parameters October 2026 * Type = TBD10: Value of default EBGP route-update-interval (seconds) * Type = TBD11: Value of default IBGP route-update-interval (seconds) * Type = TBD12: Value of Default local-preference * Type = TBD13: Value of Default MED 5. Security Considerations The extensions defined in this document report static device capabilities and default configurations via BMP Initiation Messages. Since BMP sessions may traverse public or untrusted networks, the security considerations outlined in [RFC7854] apply. Specifically, operators SHOULD secure BMP sessions using transport-layer security (such as TCP MD5, TCP Authentication Option (TCP-AO), or IPsec/TLS encapsulation) to prevent unauthorized interception or spoofing of device configuration and capability profiles. 6. IANA Considerations This document requests IANA to assign new TLV types within the "BMP Initiation Message Information TLVs" registry established by [RFC7854]: * TBD1: Optional Parameters Supported * TBD2: Optional Parameters Enabled * TBD3: Default Behavior Parameters Additionally, IANA is requested to establish a new registry for "BMP Default Behavior Parameter Sub-TLV Types" under the BMP parameters registry: * TBD4 through TBD13 as defined in Section 4.3. 7. Acknowledgements The authors would like to thank members of the GROW working group for their valuable reviews and suggestions. 8. References Zhuang, et al. Expires 19 April 2027 [Page 6] Internet-Draft BMP BGP Parameters October 2026 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, . [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, . [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 2009, . [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, . 8.2. Informative References Authors' Addresses Shunwan Zhuang Huawei Technologies Huawei Campus, No. 156 Beiqing Road Beijing 100095 China Email: zhuangshunwan@huawei.com Nan Geng Huawei Technologies Huawei Campus, No. 156 Beiqing Road Beijing 100095 China Email: gengnan@huawei.com Zhuang, et al. Expires 19 April 2027 [Page 7] Internet-Draft BMP BGP Parameters October 2026 Haibo Wang Huawei Technologies Huawei Campus, No. 156 Beiqing Road Beijing 100095 China Email: rainsword.wang@huawei.com Zhuang, et al. Expires 19 April 2027 [Page 8]