<?xml version='1.0' encoding='UTF-8'?>


<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" consensus="true" docName="draft-ietf-grow-bmp-bgp-rib-stats-17" number="9972" updates="" obsoletes="" tocInclude="true" symRefs="true" sortRefs="false" ipr="trust200902" submissionType="IETF" version="3" xml:lang="en" >

  <front>
    <title abbrev="BMP New Statistics">Advanced BGP Monitoring Protocol (BMP)
    Statistics Types</title>
    <seriesInfo name="RFC" value="9972"/>

    <author fullname="Mukul Srivastava" initials="M." role="editor" surname="Srivastava">
      <organization>Hewlett Packard Enterprise</organization>
      <address>
        <postal>
          <street>10 Technology Park Dr</street>
          <city>Westford</city>
          <region>MA</region>
          <code>01886</code>
          <country>United States of America</country>
        </postal>
        <email>mukul.srivastava@hpe.com</email>
      </address>
    </author>
    <author fullname="Yisong Liu" initials="Y." surname="Liu">
      <organization>China Mobile</organization>
      <address>
        <postal>
          <street>32 Xuanwumen West Street</street>
          <city>Beijing</city>
          <region>Xicheng District</region>
          <code>100053</code>
          <country>China</country>
        </postal>
        <email>liuyisong@chinamobile.com</email>
      </address>
    </author>
    <author fullname="Changwang Lin" initials="C." role="editor" surname="Lin">
      <organization>New H3C Technologies</organization>
      <address>
        <postal>
          <street>8 Yongjia North Road</street>
          <city>Beijing</city>
          <region>Haidian District</region>
          <code>100094</code>
          <country>China</country>
        </postal>
        <email>linchangwang.04414@h3c.com</email>
      </address>
    </author>
    <author fullname="Jinming Li" initials="J." surname="Li">
      <organization>China Mobile</organization>
      <address>
        <postal>
          <street>32 Xuanwumen West Street</street>
          <city>Beijing</city>
          <region>Xicheng District</region>
          <code>100053</code>
          <country>China</country>
        </postal>
        <email>lijinming@chinamobile.com</email>
      </address>
    </author>
    <date year="2026" month="May"/>

    <area>OPS</area>
    <workgroup>grow</workgroup>

    <keyword>IDR</keyword>
    <keyword>GROW</keyword>
    <keyword>BGP</keyword>
    <keyword>BMP</keyword>

    <abstract>
      <t>The BGP Monitoring Protocol (BMP) described in RFC 7854 defines statistics
      message types to observe events that occur on a monitored router. This
      document defines new statistics types to monitor BMP Adj-RIB-In and
      Adj-RIB-Out Routing Information Bases (RIBs).</t>
    </abstract>
  </front>
  <middle>
    <section anchor="introduction">
      <name>Introduction</name>
      <t><xref section="4.8" target="RFC7854"/> defines a number of
      different BGP Monitoring Protocol (BMP) statistics types to observe
      major events that occur on a monitored router. Statistics are either counters
      or gauges. <xref section="6.2" target="RFC8671"/> also defines several
      BMP statistics types for Adj-RIB-Out of a monitored router.</t>
      <t>New BMP statistics types are needed to enable more-refined BGP route
      monitoring and analysis to improve operational maintenance and
      troubleshooting capabilities.</t>
      <t>This document defines gauges for new BMP statistics. The
      applicability scope of these new gauges (Adj-RIB-In, Adj-RIB-Out,
      Loc-RIB) is provided in <xref target="Application_Scope_of_Statistics"/>. The format of the BMP statistics
      message remains the same as defined in <xref target="RFC7854"/>.</t>
      <section>
        <name>Requirements Language</name>
        <t>
    The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/> 
    when, and only when, they appear in all capitals, as shown here.
        </t>
	<aside><t>Note that the key words are used to stress importance for operations; they are not required as a formal implementation requirement.</t></aside>
      </section>
    </section>
    <section>
      <name>Terminology</name>

<!--[rfced] We had the following questions about the Terminology
     section:

a) We notice that some entries in the Terminology section include
quotes from their defining documents while others do not.  Should this
be made uniform?

b) We do not see any uses of Monitoring Station in this document.
Please review if updates to the following text should be made.

Original:
The terms "Producer" and "Collector" are equivalent to "Monitored
Router" and "Monitoring Station", respectively.

-->
      
      <t>This document makes use of the following terms: </t>
      <dl spacing="normal" newline="false">
        <dt>Adj-RIB-In:</dt><dd><t>As defined in <xref target="RFC4271"/>:</t>
	<blockquote>The
          Adj-RIBs-In contains unprocessed routing information that has been
          advertised to the local BGP speaker by its peers.</blockquote></dd>
          <dt>Pre-policy Adj-RIB-In:</dt><dd>The result before applying the inbound
          policy to an Adj-RIB-In. Note that this is an explicit definition
          that aligns with the pre-policy Adj-RIB-In concept specified in
          <xref section="2" target="RFC7854"/>.</dd>
          <dt>Post-policy Adj-RIB-In:</dt><dd>As defined in <xref section="2" target="RFC7854"/>.</dd>
          <dt>Adj-RIB-Out:</dt><dd><t>As defined in <xref target="RFC4271"/>:</t><blockquote>The
          Adj-RIBs-Out contains the routes for advertisement to specific peers
          by means of the local speaker's UPDATE messages.</blockquote></dd>
          <dt>Pre-policy Adj-RIB-Out:</dt><dd>As defined in <xref section="3" target="RFC8671"/>.</dd>
          <dt>Post-policy Adj-RIB-Out:</dt><dd>As defined in <xref section="3" target="RFC8671"/>.</dd>
          <dt>Loc-RIB:</dt><dd><t>As defined in <xref section="1.1" target="RFC4271"/>:</t><blockquote>The Loc-RIB contains the routes that have been selected by the
          local BGP speaker's Decision Process." Note that the Loc-RIB state
          as monitored through BMP might also contain routes imported from
          other routing protocols such as an IGP or local static routes.</blockquote></dd>
          <dt>Route:</dt><dd>As defined in <xref section="1.1" target="RFC4271"/>.</dd>
      </dl>
      <t>The terms "producer" and "collector" are equivalent to "monitored
      router" and "monitoring station", respectively. Also, "implementation"
      follows the same usage as in <xref target="RFC7854"/>.</t>
    </section>
    <section anchor="Stats">
      <name>RIB Monitoring Statistics</name>
      <t>This section defines different statistics types for Adj-RIB-In and
      Adj-RIB-Out monitoring types. Some of these statistics are also
      applicable to Loc-RIB; refer to <xref target="Application_Scope_of_Statistics"/> for more details.</t>
      <section anchor="stats-format">
        <name>Statistics Format</name>
        <t>The BMP Statistics Report Message carries statistic information in
        Type-Length-Value (TLV) formats. Each Statistic is encoded as a TLV
        (Stat Type, Stat Len, Stat Data) (see <xref section="4.8" target="RFC7854"/>). "Stat Data" is being referred to as "value" when
        defining various RIB Monitoring Statistics.</t>

<!--[rfced] Do uses of "per-" apply to both AFI and SAFI?  Note that
    more instances occur throughout the document.

Note also that, for this instance, as AFI and SAFI are marked as well-known abbreviations, it may actually be easier for the reader if the expansions were removed:

Original:
...Global Statistics and Per-Address Family Identifier
(AFI)/Subsequent Address Family Identifier (SAFI) [RFC4760]
Statistics.

Perhaps:
...Global Statistics and Statistics per-AFI or per-SAFI (see [RFC4760]).

-->

<!--[rfced] Is the switch between singular and plural in these
     sentences intentional?

a) a statistic vs. statistics

Original:
Both a Global Statistic and its corresponding Per-AFI/ SAFI Statistics
can be reported simultaneously.

Perhaps:
Both Global Statistics and and their corresponding Per-AFI/ SAFI
Statistics can be reported simultaneously.

b) AFI/SAFIs

Original:
The Per-AFI/SAFI Statistics apply only to the AFI/SAFIs that a BGP
speaker supports and negotiates with its peer.

Perhaps:
The Per-AFI/SAFI Statistics apply only to the AFIs/SAFIs that a BGP
speaker supports and negotiates with its peer.

Note: even when not preceded by "Per", it may be beneficial to clarify
the use of the slash character.  Are these either/or relationships or
and relationships?  If it has a special meaning, it may be good to
define AFI/SAFI in the Terminology section.
-->
	
        <t>Statistics defined in this document can be categorized into two
        granularities: Global Statistics and Per-Address Family Identifier
        (AFI) / Subsequent Address Family Identifier (SAFI) Statistics (see <xref target="RFC4760"/>). Statistics defined with Per-AFI/SAFI
        descriptions belong to Per-AFI/SAFI Statistics, while other statistics
        belong to Global Statistics. Both a Global Statistic and its
        corresponding Per-AFI/SAFI Statistics can be reported
        simultaneously.</t>
        <t>The Per-AFI/SAFI Statistics apply only to the AFI/SAFIs that a BGP
        speaker supports and negotiates with its peer. The authoritative
        registries for AFI/SAFI values are maintained by IANA (see <xref target="IANA-AFI"/> and <xref target="IANA-SAFI"/>).</t>
        <t>For Global Statistics, the "Stat Data" (value) field is a single
        64-bit unsigned integer gauge where the "Stat Len" field <bcp14>MUST</bcp14> be set to 8. Each
        global statistic <bcp14>MUST</bcp14> appear only once in a BMP Statistics Report
        Message.</t>
	
<!--[rfced] We plan to reformat the following text but have waited as
     there were so many uses, we felt it would clutter the diff file.

Original:
...formatted as: 2-byte AFI, 1-byte SAFI, and a 64-bit Gauge.

Perhaps:
...formatted as a 2-byte AFI, a 1-byte SAFI, and a 64-bit Gauge.

Note that we will update the following similar use (many instances
exist) to appear as above unless we hear objection.

Original:
The value is structured as: 2-byte AFI, 1-byte SAFI, followed by a
64-bit Gauge.

Perhaps:
The value is structured as a 2-byte AFI, a 1-byte SAFI, and a 64-bit
Gauge.
-->
	
        <t>For Per-AFI/SAFI Statistics, the "Stat Data" (value) field is a
        11-byte structured value formatted as: 2-byte AFI, 1-byte SAFI, and
        a 64-bit Gauge. The "Stat Len" <bcp14>MUST</bcp14> be set to 11. For any given
        per-AFI/SAFI Statistic, duplicate (AFI, SAFI) pairs <bcp14>MUST NOT</bcp14> appear
        within the same BMP Statistics Report Message. Per-AFI/SAFI statistics
        <bcp14>MUST NOT</bcp14> be included in the BMP Statistics Report Message if there is
        no data to report for that AFI/SAFI.</t>
        <t>If statistics apply to the Loc-RIB, the "Peer Type" field in the
        Per-Peer Header of the corresponding BMP Statistics Report Message
        <bcp14>MUST</bcp14> be set to 3 (Loc-RIB Instance Peer) <xref target="RFC9069"/>.
        Otherwise, the "Peer Type" field <bcp14>MUST</bcp14> be set as defined in 
        <xref target="RFC7854" section="4.2"/>.</t>
        <t>A BMP implementation <bcp14>MUST</bcp14> ignore unrecognized stat types upon
        receipt.</t>
      </section>
      <section anchor="adj-rib-in-stats">
        <name>Adj-RIB-In RIB Monitoring Statistics Definition</name>
        <dl spacing="normal" newline="true">
          <dt>Type = 18: (64-bit Gauge)</dt><dd>Current number of routes in
          the pre-policy Adj-RIB-In. This gauge is similar to stats type 7 defined
          in <xref target="RFC7854"/> and makes it explicitly for the
          pre-policy Adj-RIB-In.</dd>
          <dt>Type = 19: (64-bit Gauge)</dt><dd><t>Current number of routes in
          the per-AFI/SAFI pre-policy Adj-RIB-In. This gauge is similar to stats
          type 9 defined in <xref section="4.8" target="RFC7854"/> and makes
          it explicitly for the pre-policy Adj-RIB-In.</t><t>The value is structured
          as: 2-byte AFI, 1-byte SAFI, followed by a 64-bit Gauge.</t></dd>
          <dt>Type = 20: (64-bit Gauge)</dt><dd>Current number of routes in
          the post-policy Adj-RIB-In.</dd>
          <dt>Type = 21: (64-bit Gauge)</dt><dd><t>Current number of routes in
          the per-AFI/SAFI post-policy Adj-RIB-In.</t><t>The value is structured as:
          2-byte AFI, 1-byte SAFI, followed by a 64-bit Gauge.</t></dd>
          <dt>Type = 22: (64-bit Gauge)</dt><dd>


<!--[rfced] Should the following update be made?

Original:
The stats type 0 is a 32-counter which is a monotonically increasing
number...

Perhaps:
Stats type 0 is a 32-bit counter that is a monotonically increasing
number...

-->
	  <t>Current number of routes in the
          per-AFI/SAFI pre-policy Adj-RIB-In rejected by an inbound policy.  This
          gauge is different from stats type 0 defined in <xref
          target="RFC7854" section="4.8"/>. Stats type 0 is a 32-counter
          that is a monotonically increasing number; the stats type 22
          is a 64-bit gauge that represents the current number of routes
          rejected by an inbound policy due to ongoing policy configuration
          changes.</t><t>The value is structured as: 2-byte AFI,  1-byte SAFI,
          followed by a 64-bit Gauge.</t></dd>
          <dt>Type = 23: (64-bit Gauge)</dt><dd><t>Current number of routes in
          the per-AFI/SAFI post-policy Adj-RIB-In accepted by an inbound policy.</t><t>The
          value is structured as: 2-byte AFI, 1-byte SAFI, followed by a
          64-bit Gauge.</t></dd>
          <dt>Type = 26: (64-bit Gauge)</dt><dd><t>Current number of routes in the
          per-AFI/SAFI post-policy Adj-RIB-In or Loc-RIB suppressed by
          a configured route-damping policy.</t><t>The value is structured as: 2-byte
          AFI, 1-byte SAFI, followed by a 64-bit Gauge.</t><t>'Suppressed' refers to
          a route that has been declared suppressed by the BGP Route Flap
          Damping mechanism as described in <xref section="2.2"
          target="RFC2439"/>.</t></dd>
          <dt>Type = 27: (64-bit Gauge)</dt><dd><t>Current number of routes in
          the per-AFI/SAFI post-policy Adj-RIB-In or Loc-RIB marked as stale by
          Graceful Restart (GR) events.</t><t>The value is structured as: 2-byte
          AFI, 1-byte SAFI, followed by a 64-bit Gauge.</t><t>'Stale' refers to a
          route that has been declared stale by the BGP GR mechanism as
          described in <xref section="4.1" target="RFC4724"/>.</t></dd>
          <dt>Type = 28: (64-bit Gauge)</dt><dd><t>Current number of routes in
          the per-AFI/SAFI post-policy Adj-RIB-In or Loc-RIB marked as stale by
          Long-Lived Graceful Restart (LLGR).</t><t>The value is structured as:
          2-byte AFI, 1-byte SAFI, followed by a 64-bit Gauge.</t><t>'Stale' refers
          to a route that has been declared stale by the BGP LLGR mechanism
          as described in <xref section="4.3" target="RFC9494"/>.</t></dd>
          <dt>Type = 29: (64-bit Gauge)</dt><dd>Current number of routes in the 
          post-policy Adj-RIB-In left before exceeding the received-route
          threshold as defined in <xref section="6.7" target="RFC4271"/>.</dd>
          <dt>Type = 30: (64-bit Gauge)</dt><dd><t>Current number of routes
          in the per-AFI/SAFI in post-policy Adj-RIB-In left before exceeding the
          received-route threshold that corresponds to the upper bound of
          per-AFI/SAFI accepted routes following the model defined in <xref
          section="6.7" target="RFC4271"/>.</t><t>The value is structured as: 2-byte
          AFI, 1-byte SAFI, followed by a 64-bit Gauge.</t></dd>
          <dt>Type = 31: (64-bit Gauge)</dt><dd>Current number of routes in
          the post-policy Adj-RIB-In or Loc-RIB left before exceeding a
          license-customized route threshold. If no such license is
          configured, or if the license does not impose a hard limit, this
          value <bcp14>MUST NOT</bcp14> be reported.</dd>
          <dt>Type = 32: (64-bit Gauge)</dt><dd><t>Current number of routes in
          the per-AFI/SAFI post-policy Adj-RIB-In or Loc-RIB left before exceeding
          a license-customized route threshold.  If no such license is
          configured, or if the license does not impose a hard limit, this
          value <bcp14>MUST NOT</bcp14> be reported.</t><t>The value is structured
          as: 2-byte AFI, 1-byte SAFI, followed by a 64-bit Gauge.</t></dd>
          <dt>Type = 33: (64-bit Gauge)</dt><dd>Current number of routes in
          the pre-policy Adj-RIB-In rejected due to exceeding the maximum AS_PATH
          length supported by the local configuration.</dd>
          <dt>Type = 34: (64-bit Gauge)</dt><dd><t>Current number of routes in
          the per-AFI/SAFI in pre-policy Adj-RIB-In rejected due to exceeding the
          maximum AS_PATH length supported by the local configuration.</t><t>The
          value is structured as: 2-byte AFI, 1-byte SAFI, followed by a
          64-bit Gauge.</t></dd>
          <dt>Type = 35: (64-bit Gauge)</dt><dd>

<!--[rfced] We see both "invalidated through the ROA of RPKI" for
     Types 35, 36, 41, and 42 in Section 3.2 and "invalidated after
     verifying route origin AS number through the ROA of RPKI" for the
     same types in Section 8.  Please let us know if/how these should
     be made uniform.
	      -->

	  <t>Current number of routes in the
          per-AFI/SAFI post-policy Adj-RIB-In invalidated through the Route
          Origin Authorization (ROA) of Resource Public Key Infrastructure
          (RPKI) <xref target="RFC6811"/>. This is the total number of routes
          invalidated due to a mismatch of origin Autonomous System (AS) numbers and a mismatch of
          prefix length.</t><t>The value is structured as: 2-byte AFI,
          1-byte SAFI, followed by a 64-bit Gauge.</t></dd>
          <dt>Type = 36: (64-bit Gauge)</dt><dd><t>Current number of routes in
          the per-AFI/SAFI post-policy Adj-RIB-In validated by verifying the route
          origin AS number through the ROA of RPKI <xref
          target="RFC6811"/>.</t><t>The value is structured as: 2-byte AFI, 1-byte
          SAFI, followed by a 64-bit Gauge.</t></dd>
          <dt>Type = 37: (64-bit Gauge)</dt><dd><t>Current number of routes in
          the per-AFI/SAFI post-policy Adj-RIB-In whose RPKI route origin
          validation state is NotFound due to the absence of a matching ROA of
          RPKI <xref target="RFC6811"/>.</t><t>The value is structured as: 2-byte
          AFI, 1-byte SAFI, followed by a 64-bit Gauge.</t></dd>
        </dl>
      </section>
      <section anchor="adj-rib-out-stats">
        <name>Adj-RIB-Out RIB Monitoring Statistics Definition</name>
        <dl spacing="normal" newline="true">
          <dt>Type = 38: (64-bit Gauge)</dt><dd><t>Current number of routes in
          the per-AFI/SAFI pre-policy Adj-RIB-Out rejected by an outbound policy.
          These routes are active routes that otherwise would have been
          advertised in the absence of an outbound policy that rejected them.</t>
          <t>The value is structured as: 2-byte AFI, 1-byte SAFI, followed by
          a 64-bit Gauge.</t></dd>
          <dt>Type = 39: (64-bit Gauge)</dt><dd>Current number of routes in the
          pre-policy Adj-RIB-Out filtered due to the AS_PATH length exceeding the
          locally configured maximum.</dd>
          <dt>Type = 40: (64-bit Gauge)</dt><dd><t>Current number of routes in
          the per-AFI/SAFI pre-policy Adj-RIB-Out filtered due to AS_PATH length
          exceeding the locally configured maximum.</t><t>The value is
          structured as: 2-byte AFI, 1-byte SAFI, followed by a 64-bit
          Gauge.</t></dd>
          <dt>Type = 41: (64-bit Gauge)</dt><dd><t>Current number of routes in
          the per-AFI/SAFI post-policy Adj-RIB-Out invalidated through the ROA of
          RPKI <xref target="RFC6811"/>. This is the total number of routes
          invalidated due to a mismatch of origin AS numbers and a mismatch of prefix lengths.</t><t>The value is structured as: 2-byte AFI, 1-byte
          SAFI, followed by a 64-bit Gauge.</t></dd>
          <dt>Type = 42: (64-bit Gauge)</dt><dd><t>Current number of routes in
          the per-AFI/SAFI post-policy Adj-RIB-Out validated by verifying the route
          origin AS number through the ROA of RPKI <xref
          target="RFC6811"/>.</t><t>The value is structured as: 2-byte AFI,
          1-byte SAFI, followed by a 64-bit Gauge.</t></dd>
          <dt>Type = 43: (64-bit Gauge)</dt><dd><t>Current number of routes in
          the per-AFI/SAFI post-policy Adj-RIB-Out whose RPKI route origin
          validation state is NotFound due to the absence of a matching ROA of
          RPKI <xref target="RFC6811"/>.</t><t>The value is structured as:
          2-byte AFI, 1-byte SAFI, followed by a 64-bit Gauge.</t></dd>
        </dl>
      </section>
    </section>
    <section anchor="Application_Scope_of_Statistics">
      <name>Application Scope of Statistics</name>
      <t>This section briefly lists the statistics defined in this document
      and outlines their scope of application.</t>

      <table anchor="tbl-scope-of-application" align="center">
        <name>Scope of Application</name>
        <thead>
          <tr>
            <th align="left">Type</th>
            <th align="left">Pre-policy Adj-RIB-In</th>
            <th align="left">Post-policy Adj-RIB-In</th>
            <th align="left">Loc-RIB</th>
            <th align="left">Pre-policy Adj-RIB-Out</th>
            <th align="left">Post-policy Adj-RIB-Out</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="center">18</td>
            <td align="center">Y</td>
            <td align="center">N</td>
            <td align="center">N</td>
            <td align="center">N</td>
            <td align="center">N</td>
          </tr>
          <tr>
            <td align="center">19</td>
            <td align="center">Y</td>
            <td align="center">N</td>
            <td align="center">N</td>
            <td align="center">N</td>
            <td align="center">N</td>
          </tr>
          <tr>
            <td align="center">20</td>
            <td align="center">N</td>
            <td align="center">Y</td>
            <td align="center">N</td>
            <td align="center">N</td>
            <td align="center">N</td>
          </tr>
          <tr>
            <td align="center">21</td>
            <td align="center">N</td>
            <td align="center">Y</td>
            <td align="center">N</td>
            <td align="center">N</td>
            <td align="center">N</td>
          </tr>
          <tr>
            <td align="center">22</td>
            <td align="center">Y</td>
            <td align="center">N</td>
            <td align="center">N</td>
            <td align="center">N</td>
            <td align="center">N</td>
          </tr>
          <tr>
            <td align="center">23</td>
            <td align="center">N</td>
            <td align="center">Y</td>
            <td align="center">N</td>
            <td align="center">N</td>
            <td align="center">N</td>
          </tr>
          <tr>
            <td align="center">26</td>
            <td align="center">N</td>
            <td align="center">Y</td>
            <td align="center">Y</td>
            <td align="center">N</td>
            <td align="center">N</td>
          </tr>
          <tr>
            <td align="center">27</td>
            <td align="center">N</td>
            <td align="center">Y</td>
            <td align="center">Y</td>
            <td align="center">N</td>
            <td align="center">N</td>
          </tr>
          <tr>
            <td align="center">28</td>
            <td align="center">N</td>
            <td align="center">Y</td>
            <td align="center">Y</td>
            <td align="center">N</td>
            <td align="center">N</td>
          </tr>
          <tr>
            <td align="center">29</td>
            <td align="center">N</td>
            <td align="center">Y</td>
            <td align="center">N</td>
            <td align="center">N</td>
            <td align="center">N</td>
          </tr>
          <tr>
            <td align="center">30</td>
            <td align="center">N</td>
            <td align="center">Y</td>
            <td align="center">N</td>
            <td align="center">N</td>
            <td align="center">N</td>
          </tr>
          <tr>
            <td align="center">31</td>
            <td align="center">N</td>
            <td align="center">Y</td>
            <td align="center">Y</td>
            <td align="center">N</td>
            <td align="center">N</td>
          </tr>
          <tr>
            <td align="center">32</td>
            <td align="center">N</td>
            <td align="center">Y</td>
            <td align="center">Y</td>
            <td align="center">N</td>
            <td align="center">N</td>
          </tr>
          <tr>
            <td align="center">33</td>
            <td align="center">Y</td>
            <td align="center">N</td>
            <td align="center">N</td>
            <td align="center">N</td>
            <td align="center">N</td>
          </tr>
          <tr>
            <td align="center">34</td>
            <td align="center">Y</td>
            <td align="center">N</td>
            <td align="center">N</td>
            <td align="center">N</td>
            <td align="center">N</td>
          </tr>
          <tr>
            <td align="center">35</td>
            <td align="center">N</td>
            <td align="center">Y</td>
            <td align="center">N</td>
            <td align="center">N</td>
            <td align="center">N</td>
          </tr>
          <tr>
            <td align="center">36</td>
            <td align="center">N</td>
            <td align="center">Y</td>
            <td align="center">N</td>
            <td align="center">N</td>
            <td align="center">N</td>
          </tr>
          <tr>
            <td align="center">37</td>
            <td align="center">N</td>
            <td align="center">Y</td>
            <td align="center">N</td>
            <td align="center">N</td>
            <td align="center">N</td>
          </tr>
          <tr>
            <td align="center">38</td>
            <td align="center">N</td>
            <td align="center">N</td>
            <td align="center">N</td>
            <td align="center">Y</td>
            <td align="center">N</td>
          </tr>
          <tr>
            <td align="center">39</td>
            <td align="center">N</td>
            <td align="center">N</td>
            <td align="center">N</td>
            <td align="center">Y</td>
            <td align="center">N</td>
          </tr>
          <tr>
            <td align="center">40</td>
            <td align="center">N</td>
            <td align="center">N</td>
            <td align="center">N</td>
            <td align="center">Y</td>
            <td align="center">N</td>
          </tr>
          <tr>
            <td align="center">41</td>
            <td align="center">N</td>
            <td align="center">N</td>
            <td align="center">N</td>
            <td align="center">N</td>
            <td align="center">Y</td>
          </tr>
          <tr>
            <td align="center">42</td>
            <td align="center">N</td>
            <td align="center">N</td>
            <td align="center">N</td>
            <td align="center">N</td>
            <td align="center">Y</td>
          </tr>
          <tr>
            <td align="center">43</td>
            <td align="center">N</td>
            <td align="center">N</td>
            <td align="center">N</td>
            <td align="center">N</td>
            <td align="center">Y</td>
          </tr>
        </tbody>
      </table>
    </section>
    <section anchor="Implementation-Considerations">
      <name>Implementation Considerations</name>
      <t>This document specifies gauges for new BMP statistics. The format of
      BMP statistics messages remains unchanged from <xref target="RFC7854"/>. This section outlines the implementation
      considerations for new BMP statistics.</t>

<!--[rfced] Is there any issue with using both RECOMMENDED and SHOULD
     in the same sentence?

Original:
...it is RECOMMENDED that BMP producers capable of generating both
(Types 7 and 18) or (Types 9 and 19) BMP statistics SHOULD transmit
both corresponding types simultaneously.

Perhaps:
...it is RECOMMENDED that BMP producers capable of generating both
(Types 7 and 18) or (Types 9 and 19) BMP statistics transmit both
corresponding types simultaneously.
-->

<!--[rfced] Please rephrase "absent policy otherwise" in the
     following:

Original:
For backward compatibility, and absent policy otherwise...

Perhaps:
For backward compatibility, and absent any other policy...
-->
      
      <t>For backward compatibility, and absent policy otherwise, it is
      <bcp14>RECOMMENDED</bcp14> that BMP producers capable of generating both (Types 7 and
      18) and (Types 9 and 19) BMP statistics <bcp14>SHOULD</bcp14> transmit both
      corresponding types simultaneously. This allows BMP collectors to
      process either format according to their needs without disrupting
      existing implementations that rely on Type 7 or Type 9. The selection of
      which statistic types to generate within each pair <bcp14>SHOULD</bcp14> be treated as
      an implementation decision rather than a protocol requirement, with the
      BMP collector behavior for handling these statistic types remaining
      implementation specific.</t>
      <t>Some statistics are dependent on feature configurations, such as GR,
      LLGR, and RPKI; therefore, the corresponding statistics <bcp14>SHOULD</bcp14> only be generated
      and sent when these features are enabled on the BMP producer. These
      statistics include the following Types: 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37,
      39, 40, 41, 42, and 43.</t>
      <t>Some statistics are also relevant for the Loc-RIB view <xref target="RFC9069"/>; therefore, they may apply to the Loc-RIB view after
      best-path selection is completed. These statistics include Types 26, 27,
      28, 31, and 32. When these statistics apply to the Loc-RIB view, the
      "Peer Type" field in the Per-Peer Header of the corresponding BMP Statistics
      Report Message <bcp14>MUST</bcp14> set to 3.</t>
      <t>Certain statistics may have logical relationships (e.g., per-AFI/SAFI
      counts summing to global totals). BMP statistics producers and
      collectors <bcp14>MAY</bcp14> perform consistency checks but <bcp14>MUST NOT</bcp14> assume strict
      dependencies (due to potential race conditions or partial failures).
      Discrepancies (e.g., sum(per-AFI/SAFI) != global count) <bcp14>SHOULD</bcp14> be logged
      as warnings but <bcp14>MUST NOT</bcp14> disrupt protocol operation.</t>

<!--[rfced] This list is not of a parallel structure.  How may we
     update?

Original:
To avoid adversely impacting the restart process, a BMP statistics
producer MAY choose to sample this value at a lower frequency, buffer
updates, or temporarily suspend reporting for this type during the
most critical phases of a switchover.

Perhaps:
To avoid adversely impacting the restart process, a BMP statistics
producer MAY choose to sample this value at a lower frequency, sample
it at buffer updates, or temporarily suspend reporting for this type
during the most critical phases of a switchover.

-->
      
      <t>The generation and transmission of type 27 and 28 during an active
      GR/LLGR event consumes additional control plane resources (e.g., CPU).
      BMP statistics producers <bcp14>SHOULD</bcp14> prioritize the core GR/LLGR convergence
      procedures. To avoid adversely impacting the restart process, a BMP
      statistics producer <bcp14>MAY</bcp14> choose to sample this value at a lower
      frequency, buffer updates, or temporarily suspend reporting for this
      type during the most critical phases of a switchover.</t>
      <t>These gauges may reset due to manual clearance or overflow. BMP
      statistics producers and collectors <bcp14>MUST</bcp14> track discontinuities and log
      this anomaly.</t>
    </section>
    <section anchor="Operational">
      <name>Operational Considerations</name>
      <t>This section outlines some operational considerations of new BMP
      statistics for BMP operators.</t>
      <t>Transmission scheduling and triggering mechanisms for new gauges are
      implementation dependent. BMP operators <bcp14>SHOULD</bcp14> determine appropriate
      report generation and delivery strategies, including configurable timing
      intervals and threshold values. The mechanism for controlling the
      reporting of new gauges <bcp14>SHOULD</bcp14> be consistent with that of existing
      types.</t>
      <t>BMP operators <bcp14>SHOULD</bcp14> rate-limit statistics updates to minimize
      performance impact on control plane processes. BMP operators <bcp14>SHOULD</bcp14> only
      enable necessary statistics to reduce memory and CPU overhead.
      Implementations <bcp14>SHOULD</bcp14> also support per-router configuration of
      statistic subsets for collection and reporting.</t>
      <t>Some BMP statistics producers, or configurations in BMP statistics
      producers, <bcp14>MAY</bcp14> discard routes that do not match policy; thus, the
      accepted count (Type 23) and the Adj-RIB-In counts (Type 21) will be
      identical in such cases. BMP operators <bcp14>SHOULD</bcp14> be aware of this behavior
      when interpreting these gauges. BMP operators <bcp14>SHOULD</bcp14> be aware that BMP
      statistics producers and collectors <bcp14>MAY</bcp14> log inconsistencies between
      statistics as warnings.</t>
    </section>
    <section anchor="Security">
      <name>Security Considerations</name>
      <t>Procedures and protocol extensions defined in this document do not
      affect the BMP security model. All security and authentication
      mechanisms required by <xref section="11" target="RFC7854"/>, 
      <xref section="8" target="RFC8671"/>, and <xref section="7" target="RFC9069"/> are also applicable to the gauges defined in this
      document. This document does not add any additional security
      considerations.</t>
      <t>Monitored devices <bcp14>SHOULD</bcp14> be configured to implement rate-limited
      reporting of new gauges.</t>
    </section>
    <section anchor="IANA">
      
<!--[rfced] We had the following questions/comments related to the
     IANA Considerations section:

a) We will communicate any updates to the descriptions of the Stat
types to IANA upon the completion of AUTH48.

b) We will update the format of the list to instead appear as a table.
We have kept as is for now in order to facilitate diff review. Please
let us know any objections.

-->
      
      <name>IANA Considerations</name>
      <t>IANA has assigned the following new parameters in the "BMP Statistics Types" registry, part of the <eref
      target="https://www.iana.org/assignments/bmp-parameters/"
      brackets="angle"> "BGP Monitoring Protocol (BMP) Parameters" registry group</eref>.</t>
      <t>IANA has listed these entries as follows.  This document serves as a reference for each entry.</t>
      <dl spacing="normal" newline="false">
        <dt>Type = 18:</dt><dd>Number of routes currently in the pre-policy
        Adj-RIB-In.</dd>
        <dt>Type = 19:</dt><dd>Number of routes currently in the per-AFI/SAFI
        pre-policy Adj-RIB-In.</dd>
        <dt>Type = 20:</dt><dd>Number of routes currently in the post-policy
        Adj-RIB-In.</dd>
        <dt>Type = 21:</dt><dd>Number of routes currently in the per-AFI/SAFI
        post-policy Adj-RIB-In.</dd>
        <dt>Type = 22:</dt><dd>Number of routes currently in the per-AFI/SAFI
        pre-policy Adj-RIB-In rejected by an inbound policy.</dd>
        <dt>Type = 23:</dt><dd>Number of routes currently in the per-AFI/SAFI
        post-policy Adj-RIB-In accepted by an inbound policy.</dd>
        <dt>Type = 26:</dt><dd>Number of routes currently in the per-AFI/SAFI
        post-policy Adj-RIB-In or Loc-RIB suppressed by a configured route-damping policy.</dd>
        <dt>Type = 27:</dt><dd>Number of routes currently in the per-AFI/SAFI
        post-policy Adj-RIB-In or Loc-RIB marked as stale by GR events.</dd>
        <dt>Type = 28:</dt><dd>Number of routes currently in the per-AFI/SAFI
        post-policy Adj-RIB-In or Loc-RIB marked as stale by LLGR.</dd>
        <dt>Type = 29:</dt><dd>Number of routes currently in the post-policy
        Adj-RIB-In left before exceeding the received-route threshold.</dd>
        <dt>Type = 30:</dt><dd>Number of routes currently in the per-AFI/SAFI
        post-policy Adj-RIB-In left before exceeding the received-route
        threshold.</dd>
        <dt>Type = 31:</dt><dd>Number of routes currently in the post-policy
        Adj-RIB-In or Loc-RIB left before exceeding a license-customized route
        threshold.</dd>
        <dt>Type = 32:</dt><dd>Number of routes currently in the per-AFI/SAFI
        post-policy Adj-RIB-In or Loc-RIB left before exceeding a
        license-customized route threshold.</dd>
        <dt>Type = 33:</dt><dd>Number of routes currently in the pre-policy
        Adj-RIB-In rejected due to exceeding the locally configured maximum
        AS_PATH length.</dd>
        <dt>Type = 34:</dt><dd>Number of routes currently in the per-AFI/SAFI
        pre-policy Adj-RIB-In rejected due to exceeding the locally configured
        maximum AS_PATH length.</dd>
        <dt>Type = 35:</dt><dd>Number of routes currently in the per-AFI/SAFI
        post-policy Adj-RIB-In invalidated after verifying the route origin AS
        number through the ROA of RPKI.</dd>
        <dt>Type = 36:</dt><dd>Number of routes currently in the per-AFI/SAFI
        post-policy Adj-RIB-In validated after verifying the route origin AS
        number through the ROA of RPKI.</dd>
        <dt>Type = 37:</dt><dd>Number of routes currently in the per-AFI/SAFI
        post-policy Adj-RIB-In whose RPKI route origin validation state is
        NotFound.</dd>
        <dt>Type = 38:</dt><dd>Number of routes currently in the per-AFI/SAFI
        pre-policy Adj-RIB-Out rejected by an outbound policy.</dd>
        <dt>Type = 39:</dt><dd>Number of routes currently in the pre-policy
        Adj-RIB-Out filtered due to AS_PATH length exceeding the locally
        configured maximum.</dd>
        <dt>Type = 40:</dt><dd>Number of routes currently in the per-AFI/SAFI
        pre-policy Adj-RIB-Out filtered due to AS_PATH length exceeding the
        locally configured maximum.</dd>
        <dt>Type = 41:</dt><dd>Number of routes currently in the per-AFI/SAFI
        post-policy Adj-RIB-Out invalidated after verifying the route origin AS
        number through the ROA of RPKI.</dd>
        <dt>Type = 42:</dt><dd>Number of routes currently in the per-AFI/SAFI
        post-policy Adj-RIB-Out validated after verifying the route origin AS
        number through the ROA of RPKI.</dd>
        <dt>Type = 43:</dt><dd>Number of routes currently in the per-AFI/SAFI
        post-policy Adj-RIB-Out whose RPKI route origin validation state is
        NotFound.</dd>
      </dl>
<!--table update; remove the <dl> above.
<table anchor="tbl-iana-stats-types" align="center">
  <name>BMP Statistics Types</name>
  <thead>
    <tr>
      <th align="left">Stat Type</th>
      <th align="left">Description</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td align="center">18</td>
      <td>Number of routes currently in the pre-policy
      Adj-RIB-In.</td>
    </tr>
    <tr>
      <td align="center">19</td>
      <td>Number of routes currently in the per-AFI/SAFI
      pre-policy Adj-RIB-In.</td>
    </tr>
    <tr>
      <td align="center">20</td>
      <td>Number of routes currently in the post-policy
      Adj-RIB-In.</td>
    </tr>
    <tr>
      <td align="center">21</td>
      <td>Number of routes currently in the per-AFI/SAFI
      post-policy Adj-RIB-In.</td>
    </tr>
    <tr>
      <td align="center">22</td>
      <td>Number of routes currently in the per-AFI/SAFI
      pre-policy Adj-RIB-In rejected by an inbound policy.</td>
    </tr>
    <tr>
      <td align="center">23</td>
      <td>Number of routes currently in the per-AFI/SAFI
      post-policy Adj-RIB-In accepted by an inbound policy.</td>
    </tr>
    <tr>
      <td align="center">26</td>
      <td>Number of routes currently in the per-AFI/SAFI
      post-policy Adj-RIB-In or Loc-RIB suppressed by a
      configured route-damping policy.</td>
    </tr>
    <tr>
      <td align="center">27</td>
      <td>Number of routes currently in the per-AFI/SAFI
      post-policy Adj-RIB-In or Loc-RIB marked as stale by
      GR events.</td>
    </tr>
    <tr>
      <td align="center">28</td>
      <td>Number of routes currently in the per-AFI/SAFI
      post-policy Adj-RIB-In or Loc-RIB marked as stale by
      LLGR.</td>
    </tr>
    <tr>
      <td align="center">29</td>
      <td>Number of routes currently in the post-policy
      Adj-RIB-In left before exceeding the received-route
      threshold.</td>
    </tr>
    <tr>
      <td align="center">30</td>
      <td>Number of routes currently in the per-AFI/SAFI
      post-policy Adj-RIB-In left before exceeding the
      received-route threshold.</td>
    </tr>
    <tr>
      <td align="center">31</td>
      <td>Number of routes currently in the post-policy
      Adj-RIB-In or Loc-RIB left before exceeding a
      license-customized route threshold.</td>
    </tr>
    <tr>
      <td align="center">32</td>
      <td>Number of routes currently in the per-AFI/SAFI
      post-policy Adj-RIB-In or Loc-RIB left before exceeding
      a license-customized route threshold.</td>
    </tr>
    <tr>
      <td align="center">33</td>
      <td>Number of routes currently in the pre-policy
      Adj-RIB-In rejected due to exceeding the locally
      configured maximum AS_PATH length.</td>
    </tr>
    <tr>
      <td align="center">34</td>
      <td>Number of routes currently in the per-AFI/SAFI
      pre-policy Adj-RIB-In rejected due to exceeding the
      locally configured maximum AS_PATH length.</td>
    </tr>
    <tr>
      <td align="center">35</td>
      <td>Number of routes currently in the per-AFI/SAFI
      post-policy Adj-RIB-In invalidated after verifying the
      route origin AS number through the ROA of RPKI.</td>
    </tr>
    <tr>
      <td align="center">36</td>
      <td>Number of routes currently in the per-AFI/SAFI
      post-policy Adj-RIB-In validated after verifying the
      route origin AS number through the ROA of RPKI.</td>
    </tr>
    <tr>
      <td align="center">37</td>
      <td>Number of routes currently in the per-AFI/SAFI
      post-policy Adj-RIB-In whose RPKI route origin
      validation state is NotFound.</td>
    </tr>
    <tr>
      <td align="center">38</td>
      <td>Number of routes currently in the per-AFI/SAFI
      pre-policy Adj-RIB-Out rejected by an outbound
      policy.</td>
    </tr>
    <tr>
      <td align="center">39</td>
      <td>Number of routes currently in the pre-policy
      Adj-RIB-Out filtered due to AS_PATH length exceeding
      the locally configured maximum.</td>
    </tr>
    <tr>
      <td align="center">40</td>
      <td>Number of routes currently in the per-AFI/SAFI
      pre-policy Adj-RIB-Out filtered due to AS_PATH length
      exceeding the locally configured maximum.</td>
    </tr>
    <tr>
      <td align="center">41</td>
      <td>Number of routes currently in the per-AFI/SAFI
      post-policy Adj-RIB-Out invalidated after verifying the
      route origin AS number through the ROA of RPKI.</td>
    </tr>
    <tr>
      <td align="center">42</td>
      <td>Number of routes currently in the per-AFI/SAFI
      post-policy Adj-RIB-Out validated after verifying the
      route origin AS number through the ROA of RPKI.</td>
    </tr>
    <tr>
      <td align="center">43</td>
      <td>Number of routes currently in the per-AFI/SAFI
      post-policy Adj-RIB-Out whose RPKI route origin
      validation state is NotFound.</td>
    </tr>
  </tbody>
</table>
-->
      
    </section>

  </middle>

  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2439.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4271.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4724.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4760.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6811.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7854.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8671.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9069.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9494.xml"/>

        <reference anchor="IANA-AFI" target="https://www.iana.org/assignments/address-family-numbers">
          <front>
            <title>Address Family Numbers</title>
            <author>
              <organization>IANA</organization>
            </author>
          </front>
        </reference>
        <reference anchor="IANA-SAFI" target="https://www.iana.org/assignments/safi-namespace">
          <front>
            <title>Subsequent Address Family Identifiers (SAFI)
            Parameters</title>
            <author>
              <organization>IANA</organization>
            </author>
          </front>
        </reference>
      </references>

     
<!-- [rfced] Would you like the references to be alphabetized or left
     in their current order?
-->
    </references>

    <section anchor="Acknowledgements" numbered="false">
      <name>Acknowledgements</name>
      <t>The authors would like to thank <contact fullname="Jeff Haas"/>,
      <contact fullname="Mohamed Boucadair"/>, <contact fullname="Thomas
      Graf"/>, and <contact fullname="Prasad S. Narasimha"/> for their
      valuable input.</t>
      <t>Thanks to <contact fullname="Giuseppe Fioccola"/> for the OPSDIR,
      <contact fullname="Jouni Korhonen"/> for the GENART, and <contact
      fullname="Bruno Decraene"/> for the RTGDIR review.</t>
      <t>Thanks to <contact fullname="Gunter van de Velde"/>, <contact
      fullname="Éric Vyncke"/>, and <contact fullname="Ketan Talaulikar"/> for
      the IESG review.</t>
    </section>

<!--[rfced] We note that the following terms may be used inconsistently throughout the document.  Please review these terms and let us know if/how they may be made consistent.

Stat Type vs. stat type vs. stats type (note RFC 7854 does not use
stats type)

BMP Statistics Report Message vs. BMP statistics message

Statistic vs. statistic (when used by itself)

Gauge vs. gauge

Type vs. type (e.g., Type 27 vs. type 27)

statistic type vs. statistics types (various casing) - singular or
plural?

-->

<!--[rfced] We had the following questions related to abbreviation use throughout the document:

a) We see several instances of AS number.  May we make these ASN
instead (for Autonomous System Number)?

-->

<!-- [rfced] Please review the "Inclusive Language" portion of the
     online Style Guide
     <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
     and let us know if any changes are needed.  Updates of this
     nature typically result in more precise language, which is
     helpful for readers.

Note that our script did not flag any words in particular, but this
should still be reviewed as a best practice.
-->

    

  </back>
</rfc>
