<?xml version="1.0" encoding="US-ASCII"?>
<rfc category="std" docName="draft-zhuang-grow-monitoring-bgp-parameters-02"
     ipr="trust200902" obsoletes="" sortRefs="true" submissionType="IETF"
     symRefs="true" tocInclude="true" updates="" version="3" xml:lang="en">
  <!-- xml2rfc v2v3 conversion 3.32.0 -->

  <!-- Generated by id2xml 1.5.2 on 2026-03-19T18:24:25Z -->

  <front>
    <title abbrev="Monitoring BGP Parameters">Monitoring BGP Parameters Using
    BMP</title>

    <seriesInfo name="Internet-Draft"
                value="draft-zhuang-grow-monitoring-bgp-parameters-02"/>

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

      <address>
        <postal>
          <street>Huawei Bld., No.156 Beiqing Rd.</street>

          <street>Beijing 100095</street>

          <street>China</street>
        </postal>

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

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

      <address>
        <postal>
          <street>Huawei Bld., No.156 Beiqing Rd.</street>

          <street>Beijing 100095</street>

          <street>China</street>
        </postal>

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

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

      <address>
        <postal>
          <street>Huawei Bld., No.156 Beiqing Rd.</street>

          <street>Beijing 100095</street>

          <street>China</street>
        </postal>

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

    <date day="19" month="March" year="2026"/>

    <abstract>
      <t>The BGP Monitoring Protocol (BMP) <xref format="default"
      target="RFC7854"/> is designed to monitor BGP <xref format="default"
      target="RFC4271"/> running status, such as BGP peer relationship
      establishment and termination and route updates. Without BMP, manual
      query is required if you want to know about BGP running status.</t>

      <t>This document provides the use cases that the BMP station can get the
      optional parameters that are supported by the monitored network device
      and default configure parameters of the monitored network device via
      BMP.</t>
    </abstract>

    <note>
      <name>Requirements Language</name>

      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
      document are to be interpreted as described in RFC 2119 <xref
      format="default" target="RFC2119"/>.</t>
    </note>
  </front>

  <middle>
    <section anchor="sect-1" numbered="true" toc="default">
      <name>Terminology</name>

      <t>This memo makes use of the terms defined in <xref format="default"
      target="RFC7854"/>.</t>

      <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 and its software version.</t>
    </section>

    <section anchor="sect-2" numbered="true" toc="default">
      <name>Introduction</name>

      <t>The Border Gateway Protocol (BGP) is a dynamic routing protocol
      operating on an Autonomous System (AS) and typically configured on a
      network device. The BGP typically can support a number of optional
      parameters<xref format="default" target="RFC5492"/>, e.g., IPv4 Unicast,
      IPv4 Multicast, IPv6 Unicast, and other Multiple-Protocol Extended
      Capabilities, Route Refresh Capability, Outbound Route Filtering
      Capability, Graceful Restart Capability, Support for 4-octet AS number
      capability etc., and the different BGP implementations may support a
      different number of different capabilities. The network device
      configured with the BGP typically may not enable all optional
      capabilities supported in the configured BGP, but enable some currently
      required BGP optional capabilities as required for a current task.</t>

      <t>The BGP Monitoring Protocol (BMP) introduces the availability of
      monitoring BGP running status, such as BGP peer relationship
      establishment and termination and route updates. Without BMP, manual
      query is required if you want to know about BGP running status. With
      BMP, a router can be connected to a monitoring station and configured to
      report BGP running statistics to the station for monitoring, which
      improves the network monitoring efficiency. BMP facilitates the
      monitoring of BGP running status and reports security threats in real
      time so that preventive measures can be taken promptly.</t>

      <t>In order to monitor and manage effectively the operating states of
      the BGP configured on the respective network devices in the network, the
      existing practice is that a monitoring station obtains BGP information
      of the respective network devices in the network to monitor and manage
      centrally the network devices configured with the BGP in the network. By
      way of an example of a flow in which the monitoring station obtains the
      BGP information, after a BGP connection is set up between network
      devices A and B configured with the BGP (or between peers), taking the
      network device A as an example, the network devices A and B negotiate
      about their own enabled BGP optional capabilities in OPEN messages under
      a BGP rule, and the network device A further includes a BGP Monitoring
      Protocol (BMP) module connected with the monitoring station, where the
      BMP module can obtain the enabled BGP optional capabilities of the
      network device A, and the enabled BGP capabilities of the network device
      B as a result of negotiation about the enabled BGP capabilities, so that
      if the BMP module of the network device A sends the configured BGP
      information of the network device to the monitoring station in a Peer Up
      Notification message, then the BGP optional capabilities will include
      only the BGP capabilities enabled on the network device A.</t>

      <t>However, sometimes it's not sufficient to report only the
      capabilities currently enabled at the monitored device to the BMS. In
      order to better optimize the network, the BMS may want to access all the
      capabilities that are supported at each monitored devices, as well as
      the current configuration informations.</t>
    </section>

    <section anchor="sect-3" numbered="true" toc="default">
      <name>Use cases</name>

      <ul spacing="normal">
        <li>
          <t>BGP Optional Parameters Supported/Enabled: The Open Message
          reported to BMS contains only the currently enabled capabilities at
          the monitored device. If all the supported capabilities of the
          monitored devices, both the enabled and not yet enabled ones, are
          informed to the BMS, the BMS can use the more comprehensive and
          valid inputs to make decisions about the whole network optimization.
          For example, if the Graceful Restart Capability is not enabled for a
          BGP Peer, and thus the BGP Open Message (i.e., the Peer Up
          Notification in BMP) would not include the GR capability. However,
          if the BMS or the operator has the knowledge that both devices
          support the GR capability, and enables it at both devices, it could
          improve the operational stability of the network.</t>
        </li>

        <li>
          <t>BGP Default Behavior Parameters: As one of the concern from the
          operators, that in multi-vendor environment, some default
          configurations or behaviors of devices are vendor-specific, and may
          cause various issues during the interoperation test or any time
          after. Take the protocol preferences (distance) of different BGP
          routes for example: Vendor A assigns value 255 to eBGP, iBGP and BGP
          local routes by default, while vendor B assigns 20 to eBGP, 200 to
          iBGP and 200 to BGP local routes by default. In addition, value 255
          is not recognized by vendor B, and routes assigned such distance
          would be ignored.</t>
        </li>
      </ul>
    </section>

    <section anchor="sect-4" numbered="true" toc="default">
      <name>Extension of BMP Initiation Message</name>

      <t>As described in Section 4.3 of <xref format="default"
      target="RFC7854"/>, the initiation message provides a means for the
      monitored router to inform the monitoring station of its vendor,
      software version, and so on.</t>

      <t>The initiation message consists of the common BMP header followed by
      two or more Information TLVs (Section 4.4 of <xref format="default"
      target="RFC7854"/>) containing information about the monitored router.
      Currently defined types are:</t>

      <figure>
        <artwork align="left" alt="" name="" type=""><![CDATA[
Type = 0: String.

Type = 1: sysDescr.

Type = 2: sysName.
]]></artwork>
      </figure>

      <t>This document defines 3 new categories of TLV types: the BGP Optional
      Parameters and the BGP Default Behavior Parameters.</t>

      <figure anchor="ure-bgp-optional-parameters-information-tlv-01">
        <name>BGP Optional Parameters Information TLV</name>

        <artwork align="left" alt="" name="" type=""><![CDATA[
Type = TBD1: Optional Parameters Supported. The Information field 
specifies all BGP optional parameters supported by the monitored 
device. Each parameter is encoded as a triplet: 
<Parameter Type, Parameter Length, Parameter Value>.

    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)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
]]></artwork>
      </figure>

      <t>Parameter Type is a one octet field that unambiguously identifies
      individual parameters. Parameter Length is a one octet field that
      contains the length of the Parameter Value field in octets. Parameter
      Value is a variable length field that is interpreted according to the
      value of the Parameter Type field. RFC 5492 <xref format="default"
      target="RFC5492"/> defines the Capabilities Optional Parameter.</t>

      <figure anchor="ure-bgp-optional-parameters-information-tlv-02">
        <name>BGP Optional Parameters Information TLV</name>

        <artwork align="left" alt="" name="" type=""><![CDATA[
Type = TBD2: Optional Parameters Enabled. The Information field 
specifies all BGP optional parameters enabled by the monitored 
device. Each parameter is encoded as a triplet: 
<Parameter Type, Parameter Length, Parameter Value>.

    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)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...

]]></artwork>
      </figure>

      <t>Parameter Type is a one octet field that unambiguously identifies
      individual parameters. Parameter Length is a one octet field that
      contains the length of the Parameter Value field in octets. Parameter
      Value is a variable length field that is interpreted according to the
      value of the Parameter Type field. RFC 5492 <xref format="default"
      target="RFC5492"/> defines the Capabilities Optional Parameter.</t>

      <figure anchor="ure-default-behavior-parameters-sub-tlv">
        <name>Default Behavior Parameters sub TLV</name>

        <artwork align="left" alt="" name="" type=""><![CDATA[
Type = TBD3: Default Behavior Parameters.  The Information field
contains a list of default behavior parameters, in which each
parameter is encoded as a Default Behavior sub TLV <Default Behavior
Type, Default Behavior Length, Default Behavior Value>, which 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
   +-------------------------------+-------------------------------+
   |       Default Beh. Type       |        Def Beh. Length        |
   +-------------------------------+-------------------------------+
   +                  Default Beh. Value (variable)                +
   ~                                                               ~
   +---------------------------------------------------------------+

]]></artwork>
      </figure>

      <t>The Default Behavior Type is a one octet field that identifies the
      default behavior type parameter. Parameter Length is a one octet field
      that contains the length of the Parameter Value field in octets.
      Parameter Value is a variable length field that is interpreted according
      to the value of the Parameter Type field:</t>

      <ul spacing="normal">
        <li>
          <t>Type = TBD4, (32-bit integer ) Value of default Protocol
          Preference for Local route</t>
        </li>

        <li>
          <t>Type = TBD5, (32-bit integer ) Value of default Protocol
          Preference for EBGP route</t>
        </li>

        <li>
          <t>Type = TBD6, (32-bit integer ) Value of default Protocol
          Preference for IBGP route</t>
        </li>

        <li>
          <t>Type = TBD7, (32-bit integer ) Value of default BGP connect-retry
          timer time</t>
        </li>

        <li>
          <t>Type = TBD8, (32-bit integer ) Value of default BGP Keepalive
          time</t>
        </li>

        <li>
          <t>Type = TBD9, (32-bit integer ) Value of default BGP hold time</t>
        </li>

        <li>
          <t>Type = TBD10, (32-bit integer ) Value of EBGP
          route-update-interval</t>
        </li>

        <li>
          <t>Type = TBD11, (32-bit integer ) Value of IBGP route-update-
          interval</t>
        </li>

        <li>
          <t>Type = TBD12, (32-bit integer ) Value of Default
          local-preference</t>
        </li>

        <li>
          <t>Type = TBD13, (32-bit integer ) Value of Default MED</t>
        </li>
      </ul>
    </section>

    <section anchor="sect-5" numbered="true" toc="default">
      <name>Acknowledgements</name>

      <t>TBD.</t>
    </section>

    <section anchor="sect-6" numbered="true" toc="default">
      <name>IANA Considerations</name>

      <t>TBD.</t>
    </section>

    <section anchor="sect-7" numbered="true" toc="default">
      <name>Security Considerations</name>

      <t>TBD.</t>
    </section>
  </middle>

  <back>
    <references>
      <name>Normative References</name>

      <reference anchor="RFC2119"
                 target="https://www.rfc-editor.org/info/rfc2119"
                 xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
        <front>
          <title>Key words for use in RFCs to Indicate Requirement
          Levels</title>

          <author fullname="S. Bradner" initials="S." surname="Bradner"/>

          <date month="March" year="1997"/>

          <abstract>
            <t>In many standards track documents several words are used to
            signify the requirements in the specification. These words are
            often capitalized. This document defines these words as they
            should be interpreted in IETF documents. This document specifies
            an Internet Best Current Practices for the Internet Community, and
            requests discussion and suggestions for improvements.</t>
          </abstract>
        </front>

        <seriesInfo name="BCP" value="14"/>

        <seriesInfo name="RFC" value="2119"/>

        <seriesInfo name="DOI" value="10.17487/RFC2119"/>
      </reference>

      <reference anchor="RFC4271"
                 target="https://www.rfc-editor.org/info/rfc4271"
                 xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4271.xml">
        <front>
          <title>A Border Gateway Protocol 4 (BGP-4)</title>

          <author fullname="Y. Rekhter" initials="Y." role="editor"
                  surname="Rekhter"/>

          <author fullname="T. Li" initials="T." role="editor" surname="Li"/>

          <author fullname="S. Hares" initials="S." role="editor"
                  surname="Hares"/>

          <date month="January" year="2006"/>

          <abstract>
            <t>This document discusses the Border Gateway Protocol (BGP),
            which is an inter-Autonomous System routing protocol.</t>

            <t>The primary function of a BGP speaking system is to exchange
            network reachability information with other BGP systems. This
            network reachability information includes information on the list
            of Autonomous Systems (ASes) that reachability information
            traverses. This information is sufficient for constructing a graph
            of AS connectivity for this reachability from which routing loops
            may be pruned, and, at the AS level, some policy decisions may be
            enforced.</t>

            <t>BGP-4 provides a set of mechanisms for supporting Classless
            Inter-Domain Routing (CIDR). These mechanisms include support for
            advertising a set of destinations as an IP prefix, and eliminating
            the concept of network "class" within BGP. BGP-4 also introduces
            mechanisms that allow aggregation of routes, including aggregation
            of AS paths.</t>

            <t>This document obsoletes RFC 1771. [STANDARDS-TRACK]</t>
          </abstract>
        </front>

        <seriesInfo name="RFC" value="4271"/>

        <seriesInfo name="DOI" value="10.17487/RFC4271"/>
      </reference>

      <reference anchor="RFC5492"
                 target="https://www.rfc-editor.org/info/rfc5492"
                 xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5492.xml">
        <front>
          <title>Capabilities Advertisement with BGP-4</title>

          <author fullname="J. Scudder" initials="J." surname="Scudder"/>

          <author fullname="R. Chandra" initials="R." surname="Chandra"/>

          <date month="February" year="2009"/>

          <abstract>
            <t>This document defines an Optional Parameter, called
            Capabilities, that is expected to facilitate the introduction of
            new capabilities in the Border Gateway Protocol (BGP) by providing
            graceful capability advertisement without requiring that BGP
            peering be terminated.</t>

            <t>This document obsoletes RFC 3392. [STANDARDS-TRACK]</t>
          </abstract>
        </front>

        <seriesInfo name="RFC" value="5492"/>

        <seriesInfo name="DOI" value="10.17487/RFC5492"/>
      </reference>

      <reference anchor="RFC7854"
                 target="https://www.rfc-editor.org/info/rfc7854"
                 xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7854.xml">
        <front>
          <title>BGP Monitoring Protocol (BMP)</title>

          <author fullname="J. Scudder" initials="J." role="editor"
                  surname="Scudder"/>

          <author fullname="R. Fernando" initials="R." surname="Fernando"/>

          <author fullname="S. Stuart" initials="S." surname="Stuart"/>

          <date month="June" year="2016"/>

          <abstract>
            <t>This document defines the BGP Monitoring Protocol (BMP), which
            can be used to monitor BGP sessions. BMP is intended to provide a
            convenient interface for obtaining route views. Prior to the
            introduction of BMP, screen scraping was the most commonly used
            approach to obtaining such views. The design goals are to keep BMP
            simple, useful, easily implemented, and minimally service
            affecting. BMP is not suitable for use as a routing protocol.</t>
          </abstract>
        </front>

        <seriesInfo name="RFC" value="7854"/>

        <seriesInfo name="DOI" value="10.17487/RFC7854"/>
      </reference>
    </references>
  </back>
</rfc>
