<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-zhuang-grow-monitoring-bgp-parameters-03"
     ipr="trust200902">
  <front>
    <title abbrev="BMP BGP Parameters">Monitoring BGP Parameters Using
    BMP</title>

    <author fullname="Shunwan Zhuang" initials="S." surname="Zhuang">
      <organization>Huawei Technologies</organization>

      <address>
        <postal>
          <street>Huawei Campus, No. 156 Beiqing Road</street>

          <city>Beijing</city>

          <region/>

          <code>100095</code>

          <country>China</country>
        </postal>

        <phone/>

        <facsimile/>

        <email>zhuangshunwan@huawei.com</email>

        <uri/>
      </address>
    </author>

    <author fullname="Nan Geng" initials="N." surname="Geng">
      <organization>Huawei Technologies</organization>

      <address>
        <postal>
          <street>Huawei Campus, No. 156 Beiqing Road</street>

          <city>Beijing</city>

          <region/>

          <code>100095</code>

          <country>China</country>
        </postal>

        <phone/>

        <facsimile/>

        <email>gengnan@huawei.com</email>

        <uri/>
      </address>
    </author>

    <author fullname="Haibo Wang" initials="H." surname="Wang">
      <organization>Huawei Technologies</organization>

      <address>
        <postal>
          <street>Huawei Campus, No. 156 Beiqing Road</street>

          <city>Beijing</city>

          <region/>

          <code>100095</code>

          <country>China</country>
        </postal>

        <phone/>

        <facsimile/>

        <email>rainsword.wang@huawei.com</email>

        <uri/>
      </address>
    </author>

    <date day="16" month="October" year="2026"/>

    <area>Ops &amp; Mgmt Area</area>

    <workgroup>GROW</workgroup>

    <keyword>RIB View Synchronization</keyword>

    <keyword>Draft</keyword>

    <abstract>
      <t>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.</t>

      <t>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.</t>

      <t/>
    </abstract>

    <note title="Requirements Language">
      <t>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
      <xref target="RFC2119"/><xref target="RFC8174"/> when, and only when,
      they appear in all capitals, as shown here.</t>
    </note>
  </front>

  <middle>
    <section title="Introduction">
      <t>The Border Gateway Protocol (BGP) <xref target="RFC4271"/> is a
      dynamic routing protocol operating across Autonomous Systems (AS). BGP
      supports a variety of optional parameters <xref target="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.</t>

      <t>The BGP Monitoring Protocol (BMP) <xref target="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.</t>

      <t>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.</t>

      <t>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.</t>

      <t/>
    </section>

    <section title="Terminology">
      <t>This memo makes use of the terms defined in <xref
      target="RFC7854"/>.<list style="symbols">
          <t>BMP: BGP Monitoring Protocol.</t>

          <t>BMS: BGP Monitoring Station.</t>

          <t>Initiation Message: Reports to the monitoring server such
          information as the router vendor, software version, and device-level
          BGP capabilities.</t>
        </list></t>
    </section>

    <section title="Use Cases">
      <t/>

      <t><list style="numbers">
          <t>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.</t>

          <t>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.</t>
        </list></t>
    </section>

    <section title="Extension of BMP Initiation Message">
      <t>As described in Section 4.3 of <xref target="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.</t>

      <t>The Initiation Message consists of the common BMP header followed by
      two or more Information TLVs (Section 4.4 of <xref target="RFC7854"/>).
      This document defines three new Information TLV types to carry BGP
      optional parameters and default behavior parameters:</t>

      <t><list style="symbols">
          <t>Type = TBD1: Optional Parameters Supported</t>

          <t>Type = TBD2: Optional Parameters Enabled</t>

          <t>Type = TBD3: Default Behavior Parameters</t>
        </list></t>

      <t/>

      <section title="Optional Parameters Supported (Type = TBD1)">
        <t>The Information field specifies all BGP optional parameters
        supported by the monitored device. Each parameter is encoded as a
        triplet: &lt;Parameter Type, Parameter Length, Parameter
        Value&gt;.</t>

        <t><figure>
            <artwork><![CDATA[ 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
      ]]></artwork>
          </figure>Parameter Type is a one-octet field that unambiguously
        identifies individual parameters (as defined in <xref
        target="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.</t>

        <t/>
      </section>

      <section title="Optional Parameters Enabled (Type = TBD2)">
        <t>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 &lt;Parameter Type,
        Parameter Length, Parameter Value&gt; triplet.</t>
      </section>

      <section title="Default Behavior Parameters (Type = TBD3)">
        <t>The Information field contains a list of default behavior
        parameters, where each parameter is encoded as a sub-TLV: &lt;Default
        Behavior Type, Default Behavior Length, Default Behavior
        Value&gt;.</t>

        <t><figure>
            <artwork><![CDATA[ 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
      ]]></artwork>
          </figure>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:</t>

        <t><list style="symbols">
            <t>Type = TBD4: Value of default Protocol Preference for Local
            route</t>

            <t>Type = TBD5: Value of default Protocol Preference for EBGP
            route</t>

            <t>Type = TBD6: Value of default Protocol Preference for IBGP
            route</t>

            <t>Type = TBD7: Value of default BGP connect-retry timer
            (seconds)</t>

            <t>Type = TBD8: Value of default BGP Keepalive timer (seconds)</t>

            <t>Type = TBD9: Value of default BGP Hold Time (seconds)</t>

            <t>Type = TBD10: Value of default EBGP route-update-interval
            (seconds)</t>

            <t>Type = TBD11: Value of default IBGP route-update-interval
            (seconds)</t>

            <t>Type = TBD12: Value of Default local-preference * Type = TBD13:
            Value of Default MED</t>
          </list></t>

        <t/>
      </section>
    </section>

    <section title="Security Considerations">
      <t>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 <xref target="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.</t>

      <t/>
    </section>

    <section title="IANA Considerations">
      <t>This document requests IANA to assign new TLV types within the "BMP
      Initiation Message Information TLVs" registry established by <xref
      target="RFC7854"/>:</t>

      <t><list style="symbols">
          <t>TBD1: Optional Parameters Supported</t>

          <t>TBD2: Optional Parameters Enabled</t>

          <t>TBD3: Default Behavior Parameters</t>
        </list>Additionally, IANA is requested to establish a new registry for
      "BMP Default Behavior Parameter Sub-TLV Types" under the BMP parameters
      registry:<list style="symbols">
          <t>TBD4 through TBD13 as defined in Section 4.3.</t>
        </list></t>

      <t/>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>The authors would like to thank members of the GROW working group for
      their valuable reviews and suggestions.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>

      <?rfc include="reference.RFC.4271"?>

      <?rfc include="reference.RFC.5492"?>

      <?rfc include="reference.RFC.7854"?>

      <?rfc include="reference.RFC.8174"?>
    </references>

    <references title="Informative References"/>
  </back>
</rfc>
