| Internet-Draft | BMP Stats Info TLV | January 2026 |
| Srivastava & Kolenchery | Expires 20 July 2026 | [Page] |
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.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 20 July 2026.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
The BGP Monitoring Protocol (BMP) [RFC7854] 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).¶
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.¶
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.¶
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 [RFC2119] and RFC 8174 [RFC8174].¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
The Statistics Information TLV follows the counter encoding format defined for statistics in Section 4.8 of [RFC7854]. 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.¶
The Statistics Information TLV follows the standard BMP statistics TLV structure:¶
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 | ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
Where:¶
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.¶
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).¶
Stat Data (variable): Contains the information payload, structured as described below.¶
The Stat Data field is structured as follows:¶
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) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
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 [RFC7854].¶
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).¶
Reserved (1 byte): Reserved for future use. MUST be set to zero on transmission and MUST be ignored on receipt.¶
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.¶
Each entry in the Entry List has the following format:¶
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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
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 Section 5). The following entry types are initially defined:¶
1: Minimum - The minimum value observed during the reporting period. This entry type REQUIRES the Timestamp field to be present.¶
2: Maximum - The maximum value observed during the reporting period. This entry type REQUIRES the Timestamp field to be present.¶
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.¶
4: Average - The arithmetic mean of all sampled values during the reporting period. This entry type MUST NOT include the Timestamp field.¶
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.¶
Reserved (1 byte): Reserved for future use. MUST be set to zero on transmission and MUST be ignored on receipt.¶
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.¶
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:¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
During a particular 15-minute period:¶
The minimum observed value is 95,000 routes, observed at timestamp 1704067200 (January 1, 2024, 00:00:00 UTC)¶
The maximum observed value is 105,000 routes, observed at timestamp 1704067680 (January 1, 2024, 00:08:00 UTC)¶
The average of all 15 samples (15 minutes / 60 seconds) is 100,250 routes¶
The value at the end of the 15-minute period (snapshot value) is 100,000 routes¶
The Statistics Report message would include (among possibly other statistics):¶
A regular Stat Type 7 TLV with value 100,000¶
A Statistics Information TLV (Stat Type TBD1) with:¶
Reference Stat Type = 7¶
Num Entries = 3¶
Entry 1: Entry Type = 1 (Minimum), Value = 95,000, Timestamp = 1704067200¶
Entry 2: Entry Type = 2 (Maximum), Value = 105,000, Timestamp = 1704067680¶
Entry 3: Entry Type = 4 (Average), Value = 100,250 (no timestamp)¶
Total Stat Data length: 4 (header) + 14 (min with timestamp) + 14 (max with timestamp) + 10 (average) = 42 bytes¶
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.¶
Implementations that support the Statistics Information TLV should provide configuration options to:¶
Enable or disable the generation of Statistics Information TLVs globally or on a per-peer basis¶
Select which Stat Types should have accompanying Statistics Information TLVs¶
Configure the sampling rate for computing the distributional statistics¶
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.¶
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).¶
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 [RFC7854] for unrecognized statistic types.¶
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.¶
IANA is requested to create a new registry called "BMP Statistics Information Entry Types" within the "BGP Monitoring Protocol (BMP) Parameters" registry group.¶
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.).¶
Registration procedures for this registry are:¶
Initial values for this registry are:¶
| Value | Description | Timestamp Required | Reference |
|---|---|---|---|
| 0 | Reserved | N/A | This document |
| 1 | Minimum | Yes | This document |
| 2 | Maximum | Yes | This document |
| 3 | Snapshot | No | This document |
| 4 | Average | No | This document |
| 5 | Median (P50) | No | This document |
| 6-127 | Unassigned (Standards Action) | ||
| 128-254 | Unassigned (First Come First Served) | ||
| 255 | Reserved | N/A | This document |
IANA is requested to create a new registry called "BMP Statistics Information TLV Types" within the "BGP Monitoring Protocol (BMP) Parameters" registry group.¶
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.¶
Registration procedures for this registry are:¶
Values 0-32767: Standards Action¶
Values 32768-65534: First Come First Served¶
Value 65535: Reserved¶
Initial values for this registry are:¶
| Value | Description | Reference |
|---|---|---|
| 0 | Reserved | This document |
| TBD1 | Statistics Information: Min/Avg/Max | This document |
| 1-32767 | Unassigned (Standards Action) | |
| 32768-65534 | Unassigned (First Come First Served) | |
| 65535 | Reserved | This document |
IANA is requested to add the following note to the "BMP Statistics Types" registry defined in [RFC7854]:¶
"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."¶
This document defines an extension to the BGP Monitoring Protocol (BMP) [RFC7854]. The security considerations discussed in that document apply to this document as well.¶
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.¶
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 [RFC7854].¶
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.¶
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.¶