<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
     There has to be one entity for each item to be referenced. 
     An alternate method (rfc include) is described in the references. -->

<!ENTITY RFC2119 SYSTEM 
  "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC1155 SYSTEM 
  "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1155.xml">
<!ENTITY RFC2856 SYSTEM 
  "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2856.xml">
<!ENTITY RFC5226 SYSTEM 
  "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml">
<!ENTITY RFC7854 SYSTEM 
  "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7854.xml">
<!ENTITY RFC8174 SYSTEM 
  "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml">

]>

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), 
     please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that 
     most I-Ds might want to use.
     (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space 
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-msri-grow-bmp-stats-informational-tlv-01"
 ipr="trust200902">
  <!-- category values: std, bcp, info, exp, and historic
     ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902,
        or pre5378Trust200902
     you can add the attributes updates="NNNN" and obsoletes="NNNN" 
     they will automatically be output with "(if approved)" -->

  <!-- ***** FRONT MATTER ***** -->
  <front>

    <title abbrev="BMP Stats Info TLV">
    BMP Statistics Information TLV</title>

    <author fullname="Mukul Srivastava" initials="M"
            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="Santosh Kolenchery" initials="S"
            surname="Kolenchery">
      <organization>Hewlett Packard Enterprise</organization>

      <address>
        <postal>
          <country>United States of America</country>
        </postal>

        <email>santosh.kolenchery@hpe.com</email>

      </address>
    </author>

    <author fullname="Changwang Lin" initials="C." surname="Lin">
      <organization>New H3C Technologies</organization>
      <address>
        <postal>
          <!-- Reorder these if your country does things differently -->
          <city>Beijing</city>
          <country>China</country>
        </postal>
        <email>linchangwang.04414@h3c.com</email>
        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>

    <date year="2026" />

    <!-- If the month and year are both specified and are the current ones,
         xml2rfc will fill in the current day for you. If only the current
         year is specified, xml2rfc will fill in the current day and month
         for you. If the year is not the current one, it is necessary to
         specify at least a month (xml2rfc assumes day="1" if not specified
         for the purpose of calculating the expiry date).  With drafts it is
         normally sufficient to specify just the year. -->

    <!-- Meta-data Declarations -->

    <area>General</area>

    <workgroup>Network Working Group</workgroup>

    <keyword>BMP</keyword>
    <keyword>BGP</keyword>
    <keyword>Monitoring</keyword>
    <keyword>Statistics</keyword>

    <abstract>
<t>
   The BGP Monitoring Protocol (BMP) defines statistics reports that
   provide periodic snapshots of various BGP-related metrics. When
   statistics are reported periodically, the snapshot values may not
   reflect the variations that occurred between reporting intervals.
   This document defines a Statistics Information TLV that can be
   used to convey additional statistical information about BMP
   gauge-type statistics during the reporting period. This TLV reports
   the minimum and maximum values observed (with timestamps indicating
   when they occurred), along with additional statistical measures such
   as average, median, or snapshot values. This enables BMP collectors
   to better understand the dynamics of monitored statistics even
   when the reported snapshot values appear constant.
</t>
</abstract>

  </front>

  <middle>

<section anchor="Introduction" title="Introduction">
<t>
   The BGP Monitoring Protocol (BMP) <xref target="RFC7854">
   </xref> provides a mechanism for monitoring BGP sessions. BMP defines
   Statistics Reports (SR) messages that routers can send to monitoring
   stations to report various statistics related to BGP operations.
   These statistics are categorized as either counters (monotonically
   increasing values) or gauges (values that may increase or decrease
   within a defined range).
</t>
<t>
   Statistics Reports are typically transmitted on a periodic basis (e.g.,
   every 15 minutes) or triggered by specific events or thresholds. When
   transmitted periodically, each SR message contains snapshot values of
   the statistics at the time of collection. This snapshot approach has a
   limitation: it does not capture the variations that may have occurred
   during the reporting period, which can be important for capacity planning,
   anomaly detection, and understanding system dynamics.
</t>
<t>
   This document defines a Statistics Information TLV that can accompany
   BMP statistics to report additional distributional information about a
   statistic's behavior during the reporting period. The TLV conveys the
   minimum and maximum values observed (with timestamps indicating when
   they occurred), along with additional statistical measures such as
   average, median, or snapshot values.
</t>

      <section title="Requirements Language">
        <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 <xref
        target="RFC2119">RFC 2119</xref> and <xref target="RFC8174">RFC 8174
        </xref>.</t>
      </section>
</section> <!-- Introduction -->

<section anchor="motivation" title="Motivation and Use Cases">
<t>
   Currently, BMP statistics reports stream only the snapshot value of
   each metric at each reporting interval. This approach has a significant
   limitation: it does not capture the variations that may have occurred
   during the reporting period. Any analytic task that requires insight into the
   statistical distribution of these metrics is limited by the granularity
   of the reporting interval.
</t>
<t>
   Furthermore, there are competing operational requirements in statistics
   collection. Analytics services require high temporal resolution data,
   which necessitates shorter reporting intervals (higher reporting frequency).
   Conversely, operational constraints favor longer reporting intervals (lower
   reporting frequency) to reduce the volume of statistics messages transmitted
   across the network and minimize the processing overhead on collection
   infrastructure. By augmenting statistics reports with distributional
   information (minimum, maximum, and other statistical measures) over the
   reporting interval, this specification enables longer reporting intervals
   while preserving the statistical insights required by analytics applications,
   thereby reducing network overhead without sacrificing data fidelity.
</t>
<t>
   To illustrate this problem more concretely, consider the following scenario:
   A router is configured to report BMP statistics every 15 minutes. Suppose
   Stat Type 7 (Number of routes in Adj-RIB-In) has a value of 10,000 at time
   T0, T15, T30, and T45 minutes. The BMP collector receives a constant value
   of 10,000 at each reporting interval. Based on this data, the collector might
   conclude that the Adj-RIB-In size remained stable throughout this period.
</t>
<t>
   However, the reality could be quite different. Between T0 and T15, the
   route count might have fluctuated significantly - perhaps reaching a
   peak of 15,000 routes and a minimum of 8,000 routes before settling
   back to 10,000. This variation could be important for any analysis task
   for understanding the dynamics of the BGP system.
   With only snapshot values, the collector has no visibility into these
   fluctuations.
</t>
<t>
   The Statistics Information TLV addresses this limitation by providing
   a flexible format that can convey the minimum and maximum values observed
   (with timestamps indicating when they occurred), along with additional
   statistical measures such as the arithmetic mean (average), median, or
   current snapshot value. This approach enables enhanced temporal
   characterization of metric behavior within the reporting interval and
   decouples the analytical utility of the reported data from the reporting
   interval duration and the underlying temporal distribution characteristics
   of the metric.
</t>
<t>
   Here it is important to distinguish between the sampling interval and the
   reporting interval. The sampling interval refers to the frequency at
   which the implementation collects metric samples internally, while the
   reporting interval refers to the frequency at which Statistics Report
   messages are transmitted to the BMP collector. The sampling interval
   is typically significantly shorter than the reporting interval, enabling
   the implementation to collect multiple samples during each reporting
   period. These samples are then aggregated to compute the distributional
   statistics (minimum, maximum, median, average) conveyed in the Statistics
   Information TLV. The Statistics Information TLV mechanism allows the 
   reporting interval to be made substantially longer, thereby reducing the 
   volume of Statistics Report messages transmitted across the network and 
   minimizing processing overhead on collection infrastructure, while 
   maintaining the internal sampling rate necessary to capture metric 
   variations. In fact, it is preferred that the reporting interval be 
   selected such that distributional statistics computed from numerous 
   samples provide meaningful insights into metric behavior.
</t>
</section> <!-- Motivation and Use Cases -->

<section title="Statistics Information TLV">
<t>
   The Statistics Information TLV is a new type of statistic that can
   be included in BMP Statistics Reports messages. It provides distributional
   information about a referenced statistic during the reporting period.
</t>
<t>
   The Statistics Information TLV follows the counter encoding format
   defined for statistics in Section 4.8 of <xref target="RFC7854">
   </xref>. This TLV is counted in the Stats Count field and MAY appear multiple
   times in a single Statistics Report message - once for each statistic type
   for which supplementary information is being reported.
</t>

<section title="Format">
<t>
   The Statistics Information TLV follows the standard BMP statistics
   TLV structure:
</t>
      <figure align="center">
        <artwork align="center"><![CDATA[
0 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Stat Type             |          Stat Len             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Stat Data                              |
~                                                               ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            ]]></artwork>
      </figure>
<t>
   Where:
</t>
<t>
<list style="symbols">
<t>
   Stat Type (2 bytes): Set to TBD1 (to be assigned by IANA from the
   new "BMP Statistics Information TLV Types" registry). This identifies
   the TLV as a Statistics Information TLV.
</t>
<t>
   Stat Len (2 bytes): The length of the Stat Data field in bytes.
   This value is variable and depends on the number of entries included
   (4 bytes for the header + variable length for each entry).
</t>
<t>
   Stat Data (variable): Contains the information payload, structured
   as described below.
</t>
</list>
</t>

<t>
   The Stat Data field is structured as follows:
</t>
      <figure align="center">
        <artwork align="center"><![CDATA[
0 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Reference Stat Type      |  Num Entries  |   Reserved    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                    Entry List (variable)                      ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            ]]></artwork>
      </figure>

<t>
<list style="symbols">
<t>
   Reference Stat Type (2 bytes): The BMP Stat Type for which this
   information is being provided. This value MUST correspond to a valid
   Stat Type from the "BMP Statistics Types" registry defined in
   <xref target="RFC7854"></xref>.
</t>
<t>
   Num Entries (1 byte): The number of statistical entries that follow
   in the Entry List. This value MUST be at least 1 and SHOULD typically
   be 3 (minimum, maximum, and one additional metric).
</t>
<t>
   Reserved (1 byte): Reserved for future use. MUST be set to zero on
   transmission and MUST be ignored on receipt.
</t>
<t>
   Entry List (variable): A sequence of statistical entries, each
   providing information about the referenced statistic. The number
   of entries is specified by the Num Entries field. Each entry
   is structured as described below.
</t>
</list>
</t>

<t>
   Each entry in the Entry List has the following format:
</t>
      <figure align="center">
        <artwork align="center"><![CDATA[
0 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Entry Type  |   Reserved    |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
|                                                               |
+                        Value (64 bits)                        +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Timestamp (32 bits)                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            ]]></artwork>
      </figure>

<t>
<list style="symbols">
<t>
   Entry Type (1 byte): Identifies the type of statistical value
   reported in this entry. Valid values are defined in the "BMP Statistics
   Information Entry Types" registry (see <xref target="iana_considerations"></xref>).
   The following entry types are initially defined:
   <list style="symbols">
   <t>1: Minimum - The minimum value observed during the reporting period.
      This entry type REQUIRES the Timestamp field to be present.</t>
   <t>2: Maximum - The maximum value observed during the reporting period.
      This entry type REQUIRES the Timestamp field to be present.</t>
   <t>3: Snapshot - The current value at the time of report generation.
      This entry type MUST NOT include the Timestamp field. When implementations
      send both the regular statistic TLV and the Statistics Information TLV,
      the snapshot value is redundant and may be omitted from the Information TLV.
      However, when only the Statistics Information TLV is sent, this entry type
      provides the current snapshot value alongside the distributional statistics.</t>
   <t>4: Average - The arithmetic mean of all sampled values during the
      reporting period. This entry type MUST NOT include the Timestamp field.</t>
   <t>5: Median (P50) - The median value (50th percentile) of all sampled
      values during the reporting period. This entry type MUST NOT include
      the Timestamp field.</t>
   </list>
</t>
<t>
   Reserved (1 byte): Reserved for future use. MUST be set to zero on
   transmission and MUST be ignored on receipt.
</t>
<t>
   Value (8 bytes): A 64-bit unsigned integer representing the statistical
   gauge value. The semantics correspond to the semantics of the referenced
   Stat Type, which MUST be a gauge-type statistic.
</t>
<t>
   Timestamp (4 bytes): A 32-bit unsigned integer representing the time
   when this value was observed, expressed in seconds since midnight
   (zero hour), January 1, 1970 (UTC). This field is REQUIRED for Entry
   Types 1 (Minimum) and 2 (Maximum), and MUST NOT be present for Entry
   Types 3 (Snapshot), 4 (Average), and 5 (Median). The presence or
   absence of this field affects the total length of the entry:
   <list style="symbols">
   <t>Entries with timestamps (Types 1-2): 14 bytes (1 + 1 + 8 + 4)</t>
   <t>Entries without timestamps (Types 3-5): 10 bytes (1 + 1 + 8)</t>
   </list>
</t>
</list>
</t>
</section>

<section title="Semantics and Usage">
<t>
   The Statistics Information TLV is OPTIONAL. Implementations that do
   not support this TLV or choose not to send it for a particular statistic
   simply omit it from the Statistics Report message.
</t>
<t>
   The Statistics Information TLV can be used with any existing or future
   gauge-type BMP Stat Type. The values reflect the gauge's value at different
   sample points during the reporting period. This TLV is not applicable to
   counter-type statistics, which are monotonically increasing and do not
   exhibit the temporal variations that distributional statistics are designed
   to capture.
</t>
<t>
   A single Statistics Report message MAY contain multiple Statistics
   Information TLVs, each referring to a different BMP Stat Type. Each
   Statistics Information TLV is counted independently in the Stats Count
   field.
</t>
<t>
   Implementations MAY choose to send either the regular statistic TLV,
   the Statistics Information TLV, or both for a given Stat Type in the
   same Statistics Report message. When both are present, the value in the
   regular statistic TLV represents the snapshot value at the time of
   report generation and SHOULD be consistent with being within the range
   [Minimum Value, Maximum Value] reported in the Statistics Information
   TLV. When only the Statistics Information TLV is sent, implementations
   SHOULD include the Snapshot entry (Entry Type 3) to provide the current
   value alongside the distributional statistics. Implementations MUST NOT
   reject or ignore a Statistics Information TLV solely because the
   corresponding regular statistic TLV is absent, or vice versa.
</t>
<t>
   The time period over which the distributional statistics are computed
   is implementation-dependent. Typically, it corresponds to the interval
   since the last Statistics Report message was sent for this peer, but
   implementations MAY use different windowing strategies. When a BMP
   session is first established or after a peer transitions to Established
   state, the first Statistics Report for that peer MAY omit Statistics
   Information TLVs or MAY report values based on whatever partial data
   is available.
</t>
</section>

<section title="Example">
<t>
   Consider a router configured to send Statistics Reports every 15 minutes
   for a particular BGP peer. The router tracks the number of routes in
   Adj-RIB-In (Stat Type 7) and samples this value every 60 seconds.
</t>
<t>
   During a particular 15-minute period:
<list style="symbols">
<t>
   The minimum observed value is 95,000 routes, observed at timestamp 1704067200
   (January 1, 2024, 00:00:00 UTC)
</t>
<t>
   The maximum observed value is 105,000 routes, observed at timestamp 1704067680
   (January 1, 2024, 00:08:00 UTC)
</t>
<t>
   The average of all 15 samples (15 minutes / 60 seconds) is 100,250 routes
</t>
<t>
   The value at the end of the 15-minute period (snapshot value) is 100,000 routes
</t>
</list>
</t>
<t>
   The Statistics Report message would include (among possibly other statistics):
</t>
<t>
<list style="numbers">
<t>
   A regular Stat Type 7 TLV with value 100,000
</t>
<t>
   A Statistics Information TLV (Stat Type TBD1) with:
   <list style="symbols">
   <t>Reference Stat Type = 7</t>
   <t>Num Entries = 3</t>
   <t>Entry 1: Entry Type = 1 (Minimum), Value = 95,000, Timestamp = 1704067200</t>
   <t>Entry 2: Entry Type = 2 (Maximum), Value = 105,000, Timestamp = 1704067680</t>
   <t>Entry 3: Entry Type = 4 (Average), Value = 100,250 (no timestamp)</t>
   </list>
   Total Stat Data length: 4 (header) + 14 (min with timestamp) + 14 (max with timestamp) + 10 (average) = 42 bytes
</t>
</list>
</t>
<t>
   This allows the BMP collector to understand that while the snapshot
   value was 100,000, the actual route count varied between 95,000 and
   105,000 during the reporting period, with an average of 100,250. The
   timestamps indicate when the minimum and maximum values were observed,
   providing temporal context for these extremes.
</t>
</section>

</section>

<section title="Implementation Considerations">
<t>
   Implementations that support the Statistics Information TLV should
   provide configuration options to:
<list style="symbols">
<t>
   Enable or disable the generation of Statistics Information TLVs
   globally or on a per-peer basis
</t>
<t>
   Select which Stat Types should have accompanying Statistics Information
   TLVs
</t>
<t>
   Configure the sampling rate for computing the distributional statistics
</t>
</list>
</t>
<t>
   The computation and reporting of Statistics Information TLVs adds some
   processing and memory overhead to the monitored router, as it must
   track additional state for each monitored statistic. Implementations
   SHOULD be mindful of these resource implications and MAY choose to
   support Statistics Information TLVs only for a subset of statistics
   or only when explicitly configured.
</t>
<t>
   While this TLV does enable us to make the data independent of the
   choice of reporting interval and thereby enable scalability of
   collection, the analytics tasks relying on this data will have to
   consider the latency introduced by such aggregation over the reporting
   interval. The temporal resolution of anomaly detection and trend
   analysis will be limited by the reporting interval, as the aggregated
   statistics only provide visibility into what happened during that
   interval without precise timing information (except for the timestamps
   associated with entry types that require them, such as minimum and
   maximum values).
</t>
<t>
   BMP collectors that receive Statistics Information TLVs MUST be prepared
   to handle Statistics Report messages that may contain the Statistics
   Information TLV with or without the corresponding regular statistic TLV.
   When a Statistics Information TLV (Stat Type TBD1) is encountered, the
   collector MUST examine the Reference Stat Type field within the TLV's
   data to determine which statistic the distributional information pertains
   to. A BMP collector that does not recognize or does not wish to process
   Statistics Information TLVs MUST ignore them, as specified in
   <xref target="RFC7854"></xref> for unrecognized statistic types.
</t>
<t>
   For statistics with per-AFI/SAFI granularity (such as Stat Type 9 and 10),
   the Statistics Information TLV's Reference Stat Type field identifies
   the base Stat Type (9 or 10). The regular Stat Type 9 or 10 TLV
   includes the AFI/SAFI information in its Stat Data field. For these
   per-AFI/SAFI statistics, implementations MUST include the corresponding
   regular statistic TLV with the same AFI/SAFI in the same Statistics Report
   message when sending a Statistics Information TLV. Without the regular
   statistic TLV, the collector cannot determine which AFI/SAFI the
   distributional information applies to, rendering the Statistics Information
   TLV unusable.
</t>
</section>

<section title="IANA Considerations" anchor="iana_considerations">

<section title="BMP Statistics Information Entry Types Registry">
<t>
   IANA is requested to create a new registry called "BMP Statistics
   Information Entry Types" within the "BGP Monitoring Protocol (BMP)
   Parameters" registry group.
</t>
<t>
   This registry contains values for the Entry Type field used within
   Statistics Information TLVs to identify the type of statistical value
   being reported (minimum, maximum, snapshot, average, median, etc.).
</t>
<t>
   Registration procedures for this registry are:
<list style="symbols">
<t>
   Values 0-127: Standards Action
</t>
<t>
   Values 128-254: First Come First Served
</t>
<t>
   Value 255: Reserved
</t>
</list>
</t>
<t>
   Initial values for this registry are:
</t>
<texttable>
<ttcol>Value</ttcol>
<ttcol>Description</ttcol>
<ttcol>Timestamp Required</ttcol>
<ttcol>Reference</ttcol>
<c>0</c>
<c>Reserved</c>
<c>N/A</c>
<c>This document</c>
<c>1</c>
<c>Minimum</c>
<c>Yes</c>
<c>This document</c>
<c>2</c>
<c>Maximum</c>
<c>Yes</c>
<c>This document</c>
<c>3</c>
<c>Snapshot</c>
<c>No</c>
<c>This document</c>
<c>4</c>
<c>Average</c>
<c>No</c>
<c>This document</c>
<c>5</c>
<c>Median (P50)</c>
<c>No</c>
<c>This document</c>
<c>6-127</c>
<c>Unassigned (Standards Action)</c>
<c></c>
<c></c>
<c>128-254</c>
<c>Unassigned (First Come First Served)</c>
<c></c>
<c></c>
<c>255</c>
<c>Reserved</c>
<c>N/A</c>
<c>This document</c>
</texttable>
</section>

<section title="BMP Statistics Information TLV Types Registry">
<t>
   IANA is requested to create a new registry called "BMP Statistics
   Information TLV Types" within the "BGP Monitoring Protocol (BMP)
   Parameters" registry group.
</t>
<t>
   This registry contains values for the Stat Type field when used to
   identify Statistics Information TLVs (as opposed to regular statistics).
   These TLVs provide meta-information about other BMP statistics rather
   than representing standalone statistics themselves.
</t>
<t>
   Registration procedures for this registry are:
<list style="symbols">
<t>
   Values 0-32767: Standards Action
</t>
<t>
   Values 32768-65534: First Come First Served
</t>
<t>
   Value 65535: Reserved
</t>
</list>
</t>
<t>
   Initial values for this registry are:
</t>
<texttable>
<ttcol>Value</ttcol>
<ttcol>Description</ttcol>
<ttcol>Reference</ttcol>
<c>0</c>
<c>Reserved</c>
<c>This document</c>
<c>TBD1</c>
<c>Statistics Information: Min/Avg/Max</c>
<c>This document</c>
<c>1-32767</c>
<c>Unassigned (Standards Action)</c>
<c></c>
<c>32768-65534</c>
<c>Unassigned (First Come First Served)</c>
<c></c>
<c>65535</c>
<c>Reserved</c>
<c>This document</c>
</texttable>
</section>

<section title="Addition to BMP Statistics Types Registry">
<t>
   IANA is requested to add the following note to the "BMP Statistics Types"
   registry defined in <xref target="RFC7854"></xref>:
</t>
<t>
   "Note: Stat Types from the 'BMP Statistics Information TLV Types'
   registry may also appear in Statistics Reports messages. These special
   Stat Types contain meta-information about other statistics and are
   distinguished by their type values, which are allocated from a separate
   registry."
</t>
</section>

</section>

<section title="Security Considerations" anchor="security_considerations">
<t>
   This document defines an extension to the BGP Monitoring Protocol (BMP)
   <xref target="RFC7854"></xref>. The security considerations
   discussed in that document apply to this document as well.
</t>
<t>
   The Statistics Information TLV does not introduce any new security
   vulnerabilities beyond those inherent in the base BMP specification.
   It provides additional statistical information but does not change
   the fundamental security model of BMP.
</t>
<t>
   Implementations should be aware that the Statistics Information TLV
   increases the size of Statistics Report messages. An attacker who has
   compromised a monitored router could potentially use this to amplify
   a denial-of-service attack against the BMP collector by generating
   excessive Statistics Report messages with many Statistics Information
   TLVs. However, this is not fundamentally different from the existing
   ability to send large Statistics Reports with many regular statistics.
   BMP implementations SHOULD implement rate limiting and resource management
   as discussed in <xref target="RFC7854"></xref>.
</t>
<t>
   The minimum, average, and maximum values reported in the Statistics
   Information TLV could potentially reveal information about the dynamics
   of BGP operations that is not visible from snapshot values alone. This
   information is not considered sensitive in typical deployment scenarios,
   as it represents aggregated statistical trends rather than detailed
   routing information. However, operators should be aware that this
   information will be transmitted to BMP collectors and should ensure
   appropriate access controls are in place for those collectors.
</t>
<t>
   As with all BMP statistics, the accuracy and integrity of Statistics
   Information TLVs depends on the trustworthiness of the monitored router.
   BMP does not include mechanisms for cryptographic authentication of
   the statistics themselves. Deployments that require strong assurance
   of data integrity should use transport-layer security mechanisms such
   as TLS or IPsec to protect the BMP session, and should implement
   appropriate authentication and authorization for BMP connections.
</t>
</section>

  </middle>

  <back>
    <references title="Normative References">
      &RFC2119;
      &RFC7854;
      &RFC8174;

    </references>

    <references title="Informative References">
      &RFC1155;
      &RFC2856;
      &RFC5226;
    </references>

  </back>
</rfc>
