BGP Message Counters for BGP Monitoring Protocol (BMP)
draft-choudhary-grow-bmp-bgp-msg-stats-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Aseem Choudhary , Narasimha Prasad | ||
| Last updated | 2026-10-29 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-choudhary-grow-bmp-bgp-msg-stats-00
GROW A. Choudhary
Internet-Draft N. Prasad S N
Intended status: Standards Track Cisco Systems
Expires: 29 April 2027 26 October 2026
BGP Message Counters for BGP Monitoring Protocol (BMP)
draft-choudhary-grow-bmp-bgp-msg-stats-00
Abstract
The BGP Monitoring Protocol (BMP) [RFC7854] Statistics Report
carries RIB occupancy, policy, and route-processing metrics.
Some existing types count UPDATE messages, but only as special
cases grouped by result (duplicates, loops, and errors). No
statistic gives a total count of each BGP message type.
This document defines those totals as new BMP Statistics Types
(UPDATE, KEEPALIVE, NOTIFICATION, ROUTE-REFRESH, and all BGP
PDUs in each direction), states the operational use cases that
motivate them, and records explicit non-goals so that last-error
content, negotiated timer values, and implementation-specific
internals remain out of scope.
Status of This Memo
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 29 April 2027.
Copyright Notice
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.
Table of Contents
1. Introduction
1.1. Requirements Language
1.2. Scope
2. Terminology
3. Use Cases
3.1. Why Existing BMP Is Not Sufficient
3.2. Use Case 1 (UC1): Hold-Timer Health without Relaying
KEEPALIVEs
3.3. Use Case 2 (UC2): Route Churn versus a Stable Adj-RIB
3.4. Use Case 3 (UC3): NOTIFICATION Count on the Neighbor
3.5. Use Case 4 (UC4): Route-Refresh Storms
3.6. Use Case 5 (UC5): Control-Plane Baseline, Asymmetry, and
Capacity
3.7. Use Case 6 (UC6): Unified Telemetry
3.8. Use Case 7 (UC7): Late-Joining or Restarted Monitoring
Station
3.9. Use Case 8 (UC8): Security and Anomaly Detection
3.10. Mapping Use Cases to Statistics
4. Non-Goals
5. Statistics Definition
5.1. Format
5.2. Per-Peer PDU Counters
5.3. Application Scope
5.4. BMPv3 and BMPv4 Applicability
5.5. Example
6. Relation to Existing Mechanisms
7. Implementation Considerations
8. Operational Considerations
9. Security Considerations
10. IANA Considerations
11. References
11.1. Normative References
11.2. Informative References
Appendix A. Open Issues
Authors' Addresses
1. Introduction
Section 4.8 of [RFC7854] defines the BMP Statistics Report.
Existing types in [RFC7854], [RFC8671], [RFC9069], and [RFC9972]
describe RIB occupancy, policy, and route-processing outcomes.
Some of those types already count UPDATE messages, but only as
special cases grouped by result. RFC 7854 types 3 to 6 count
UPDATEs rejected for AS_PATH or origin loops. Type 11 counts
UPDATEs treated as withdraw. Type 13 counts duplicate UPDATEs.
None of them is a total count of UPDATE, KEEPALIVE,
NOTIFICATION, or ROUTE-REFRESH PDUs, or of all BGP PDUs in each
direction.
BGP [RFC4271] exchanges those message types. A monitoring
station that already receives Route Monitoring and Peer Up/Down
therefore sees routing state and session lifecycle, but not the
total PDU volume while the session remains Established.
Section 7 of [RFC7854] already names route churn as a reason for
statistics.
This document defines new BMP Statistics Types TBD1-TBD10 for
those session-layer totals on the same BMP session, using the
Per-Peer Header already used for RIB statistics. No change to
BMP message framing is required. Generating a Peer Down message
MUST NOT, by itself, reset these counters (Section 7).
The types are:
TBD1 / TBD2 UPDATE received / sent 64-bit Counter
TBD3 / TBD4 KEEPALIVE received / sent 32-bit Counter
TBD5 / TBD6 NOTIFICATION received / sent 32-bit Counter
TBD7 / TBD8 ROUTE-REFRESH received / sent 32-bit Counter
TBD9 / TBD10 Total BGP PDUs received / sent 64-bit Counter
Section 3 explains the use cases. Section 5 defines the
encoding. The BGP MIB [RFC4273] defines per-connection
UPDATE and total message counters. BGP YANG
[I-D.ietf-idr-bgp-model] defines those and a NOTIFICATION
counter. Section 6 states where they differ from
TBD1-TBD10. Why the counters in this document also belong
on BMP is Use Case 6 (Section 3.7).
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP 14 [RFC2119] [RFC8174] when, and only when, they
appear in all capitals, as shown here.
1.2. Scope
This document defines only session-layer PDU counters:
* UPDATE messages sent and received
* KEEPALIVE messages sent and received
* NOTIFICATION messages sent and received
* ROUTE-REFRESH messages sent and received
* total BGP messages sent and received (all PDU types)
The counters in this document are session-global. KEEPALIVE,
NOTIFICATION, and total (TBD3 to TBD6, TBD9, TBD10) have no
AFI/SAFI in the PDU, so they cannot have a per-AFI/SAFI form.
UPDATE and ROUTE-REFRESH carry an AFI/SAFI. Per-AFI/SAFI
UPDATE and ROUTE-REFRESH counters are not defined here. The
authors intend to add them (Appendix A). FSM/session gauges
and a "seconds since last message received" gauge are also
listed in Appendix A.
Out of scope: last NOTIFICATION or last error code, hold time
and keepalive interval, NLRI or prefix counts, and
implementation-specific internals such as queue depth
(Section 4).
2. Terminology
This document uses terms from [RFC7854] and [RFC4271]. This
document uses "monitoring station" for the BMP receiver, as in
[RFC7854].
BMP: BGP Monitoring Protocol.
Monitoring station: The BMP receiver in [RFC7854].
PDU-level counter: A monotonically increasing count incremented
once per BGP message PDU, not once per NLRI. Size is 32-bit
or 64-bit as specified for each type (Section 5.1).
32-bit Counter: The Counter defined in Section 4.8 of
[RFC7854]. Stat Len is 4. The value increases until it
reaches 2^32-1 and then wraps to 0.
64-bit Counter: A non-negative integer that increases until it
reaches 2^64-1 and then wraps to 0. This extends the 32-bit
Counter of Section 4.8 of [RFC7854] to 64 bits, in the same
way as Counter64 in [RFC2578]. Stat Len is 8. A single
sample has no meaning by itself. Only the difference between
two samples of the same counter is meaningful. A 64-bit
Counter can have discontinuities (Section 7).
[Editor's note: BMP does not yet define a 64-bit Counter.
The working group can decide whether this definition stays
in this document or moves to a document that updates
RFC 7854, and whether all ten types should use it.]
Counter: Unless qualified, a 32-bit Counter or a 64-bit
Counter as specified for the type. These counters are
cumulative across BGP session establishments. They reset
when the speaker resets them (process restart, neighbor
removal, operator clear, or RP failover). Peer Down does
not clear them. A monitoring station MUST track
discontinuities (Section 7).
Total messages: Count of all BGP PDUs in one direction (OPEN,
UPDATE, NOTIFICATION, KEEPALIVE, ROUTE-REFRESH, and any other
types the speaker supports). It is not required to equal the
sum of the per-type counters in this document, because OPEN
and other types are included in the total but are not given
their own Stat Types here.
3. Use Cases
These counters exist so that a monitoring station that already
has RIBs and Peer Up/Down can also see session-layer load and
liveness on that same feed. Core cases are churn that prefix
gauges hide (UC2), NOTIFICATION rate across flaps (UC3),
ROUTE-REFRESH storms (UC4), and the same BMP session as routes
(UC6). Other uses are hold-timer context (UC1), a PDU baseline
(UC5), a late-joining monitoring station (UC7), and an anomaly
signal (UC8).
3.1. Why Existing BMP Is Not Sufficient
Route Monitoring [RFC7854] is not a PDU counter.
* One UPDATE PDU may contain many NLRIs, producing one or many
Route Monitoring messages depending on the speaker.
* One NLRI change may be exported on several RIB views (pre-
policy, post-policy, Loc-RIB, Adj-RIB-Out).
* Treat-as-withdraw [RFC7606] and locally discarded UPDATEs may
increment the speaker's PDU counter without a Route Monitoring
export.
* BMP filtering [I-D.ietf-grow-bmp-adj-ribs-filtered] can
suppress routes that still arrived as PDUs on the BGP session.
Existing Statistics Types also do not provide a total per
message type. RFC 7854 types 3 to 6, 11, and 13 count UPDATE
outcomes (loops, treat-as-withdraw, duplicates). They are a
subset of UPDATE PDUs. Types 7 to 10 and later RIB gauges
[RFC8671] [RFC9069] [RFC9972] are occupancy, not PDU volume.
No existing BMP Stat Type counts all UPDATEs, KEEPALIVEs,
NOTIFICATIONs, ROUTE-REFRESH PDUs, or total BGP PDUs.
Peer Up and Peer Down are lifecycle events. Peer Up carries OPEN
PDUs and negotiated parameters (hold time, capabilities). Peer
Down may carry a NOTIFICATION PDU and a reason code. They answer
what happened at that transition. They do not give KEEPALIVE or
UPDATE rates while the session remains Established.
RIB Statistics (RFC 7854 types 7 and 8, Adj-RIB-Out types in
[RFC8671], Loc-RIB in [RFC9069], and [RFC9972]) are gauges of
table occupancy. A Loc-RIB of N prefixes can be unchanged in
size while UPDATE PDUs continue. A PDU counter distinguishes
those cases. Section 7 of [RFC7854] names route churn as a
reason for statistics.
The BGP MIB [RFC4273] defines per-connection UPDATE and total
message counters for SNMP. The IETF BGP YANG model
[I-D.ietf-idr-bgp-model] defines those and a NOTIFICATION
counter for NETCONF or gNMI. Neither defines a KEEPALIVE
counter. The BMP YANG model
[I-D.ietf-grow-bmp-yang] "session-stats" leaves count BMP
messages on the BMP session, not BGP PDUs with a peer. Why
the BGP PDU counts still belong on BMP is Use Case 6
(Section 3.7).
3.2. Use Case 1 (UC1): Hold-Timer Health without Relaying
KEEPALIVEs
Problem: Operators need a view of whether an Established
session is still receiving hold-timer-resetting PDUs. A BGP
speaker restarts its Hold Timer when it receives a KEEPALIVE
or an UPDATE [RFC4271], not only a KEEPALIVE. The Send Hold
Timer [RFC9687] covers the sending side.
Today: BMP does not relay KEEPALIVE PDUs (they have no routing
content and would dominate BMP bandwidth). Negotiated hold
time in Peer Up does not say whether hold-timer-resetting
PDUs are arriving now.
With these stats: The monitoring station watches inbound
KEEPALIVE (TBD3) and inbound UPDATE (TBD1). A flattening
KEEPALIVE counter is not a stall if UPDATE is still
incrementing.
Counters show whether inbound KEEPALIVE or UPDATE PDUs are still
arriving, without exporting those KEEPALIVEs on BMP. They do
not define an alarm threshold. In common deployments the
Statistics Report interval is several minutes, while the
negotiated Hold Time is often 90 to 180 seconds. Peer Down
may therefore arrive before two reports show a stall. UC1 is
still useful as context next to Peer Down and as a liveness
input when the interval is shorter than Hold Time. A "seconds
since last message received" gauge, in the spirit of
bgpPeerInUpdateElapsedTime [RFC4273], is listed in Appendix A.
3.3. Use Case 2 (UC2): Route Churn versus a Stable Adj-RIB
Problem: Two sessions can advertise the same number of prefixes
while exchanging very different numbers of UPDATE PDUs. For
example, withdraw and re-advertise of the same prefix leaves
Adj-RIB size unchanged. Operators need that churn to size
control-plane load and to see instability that occupancy
hides. Section 7 of [RFC7854] already names this reason.
Today: Adj-RIB gauges and Route Monitoring show current routes,
not how many UPDATE PDUs were exchanged to reach that state.
RFC 7854 types 1 and 2 count duplicate prefix advertisements
and duplicate withdrawals. Type 13 counts duplicate UPDATE
messages. Those types count only wasted churn. They do not
count every UPDATE. Real churn that is not a duplicate, such
as a withdrawal followed by a new attribute, does not change
them.
With these stats: Inbound and outbound UPDATE PDU counters
(TBD1 / TBD2) measure UPDATE message volume, not NLRI count
or RIB size. Type 13 divided by TBD1, when both are present,
is the share of received UPDATEs that are duplicates.
A session with a large but stable RIB can have a very different
control-plane profile from a session with the same RIB size and
high UPDATE churn. Differences between inbound and outbound
UPDATE counts are a signal of directional asymmetry. They are
not necessarily anomalous and should be correlated with routing
policy and RIB state.
3.4. Use Case 3 (UC3): NOTIFICATION Count on the Neighbor
Problem: Operators need a count of BGP NOTIFICATION PDUs for a
neighbor over time (error and administrative closes), not
only the last close, so they can see a flapping peer after
the session is back up.
Today: Peer Down [RFC7854] records one teardown. It does not
accumulate. A monitoring station that missed that Peer Down
has no remaining event. The speaker may already keep a
NOTIFICATION counter on the neighbor. That value is not in
the Statistics Report.
IETF BGP YANG [I-D.ietf-idr-bgp-model] "notifications" typically
counts NOTIFICATIONs that report an error. TBD6 also counts
administrative Cease, including Graceful Shutdown [RFC8326].
With these stats: TBD5 and TBD6 increment once per NOTIFICATION
PDU and are not cleared by Peer Down (Section 7). After the
session is Established again, a Statistics Report can still
show the incremented value. If the speaker sends Statistics
Reports only after Peer Up, a NOTIFICATION that closes the
session appears in the count after the next Peer Up.
The counters provide historical context that an individual
Peer Down event does not provide. They can help distinguish
an isolated administrative shutdown from a neighbor that
repeatedly sends or receives NOTIFICATIONs.
These counters do not replace Peer Down. Peer Down remains the
mechanism for identifying the individual teardown and its
associated reason. The counters provide an aggregate signal
suitable for trending and anomaly detection.
3.5. Use Case 4 (UC4): Route-Refresh Storms
Problem: A ROUTE-REFRESH [RFC2918] asks the recipient to
re-advertise its Adj-RIB-Out for an AFI/SAFI. A ROUTE-REFRESH
sent by the monitored router requests the peer's Adj-RIB-Out
(inbound UPDATE load). A ROUTE-REFRESH received by the
monitored router requires it to send its own Adj-RIB-Out
(outbound UPDATE load). A storm (buggy peer, orchestrator
loop) is control-plane load that RIB size will not show.
Today: Some refreshes produce a Route Monitoring burst.
Filtered AFIs may produce none.
With these stats: TBD7 (received) and TBD8 (sent) count
ROUTE-REFRESH PDUs independently of BMP route export policy.
The operator can see the request rate and correlate it with
subsequent UPDATE load. Counting is at the message layer.
Whether processing succeeds is separate from whether the PDU
was sent or received. Enhanced Route Refresh [RFC7313] begin
and end markers are also ROUTE-REFRESH PDUs. TBD7 and TBD8
count them (Section 5.2).
3.6. Use Case 5 (UC5): Control-Plane Baseline, Asymmetry, and
Capacity
Problem: Capacity planning needs a PDU-rate baseline, not only
prefix counts, so operators can tell keepalive load from
routing-change load.
Today: Prefix gauges answer table size. They do not separate
KEEPALIVE from UPDATE or give a PDU-rate baseline.
With these stats: Totals plus UPDATE in/out, and ROUTE-REFRESH
when enabled, give a PDU-rate baseline on BMP. On a quiet
session the total is dominated by KEEPALIVEs (UC1). On a
busy session TBD1/TBD2 versus TBD7/TBD8 separate routing
change from refresh from keepalives.
These measurements are a baseline for abnormal change and one
input to control-plane capacity planning. PDU rate is not
itself CPU or overall control-plane cost. It is one observable
to correlate with RIB and processing statistics.
3.7. Use Case 6 (UC6): Unified Telemetry
Problem: Operators already run BMP for RIBs and session
lifecycle. They need session PDU counts on that same
session and peer key.
Today: RIB data arrives on the BMP session. PDU counts, if
collected, often come from YANG/gNMI or other device
telemetry. The BGP MIB [RFC4273] defines UPDATE and total
counters. IETF BGP YANG [I-D.ietf-idr-bgp-model] defines
those and NOTIFICATION counters (Section 6).
With these stats: PDU counters appear in the same Statistics
Report as RIB occupancy, using the same Per-Peer Header.
Operators already collect some of these counts with YANG/gNMI
or other device telemetry. The operator benefit of these types is
having BGP routes, peer events, RIB statistics, and session
PDU counters on the same BMP session, using the same Per-Peer
Header.
This document does not replace YANG/gNMI. CPU, interface, and
platform metrics remain general device telemetry. These
counters belong on BMP because they are BGP session-layer
activity for a peer that BMP already exports.
High UPDATE activity with little RIB change is a different
condition from high UPDATE activity with substantial RIB churn.
PDU activity and routing outcome share the same peer-scoped
monitoring context.
3.8. Use Case 7 (UC7): Late-Joining or Restarted Monitoring
Station
Problem: A new or restarted monitoring station cannot replay
missed Peer Up/Down events.
Today: After reconnect it may have current RIB state but no
record of PDU activity before it joined.
With these stats: The counters are the speaker's current
per-peer values (Section 7), including activity from
previous sessions since the last discontinuity.
Cumulative counters make monitoring less dependent on
continuous availability of the monitoring station. They do
not replay Peer Down content and are not an event history.
They cannot identify the time or reason of an individual
historical session transition. Session-state gauges that would
help a restarted monitoring station further are listed in
Appendix A.
3.9. Use Case 8 (UC8): Security and Anomaly Detection
Problem: A sudden rise in UPDATE or NOTIFICATION counts, or
hold-timer PDUs (KEEPALIVE and UPDATE) both flattening, can
indicate a fault or an attack.
Today: Detection often waits for Peer Down or depends on
syslog. Exporting every UPDATE via Route Monitoring during a
flood can be too large for the monitoring station.
With these stats: Statistics Reports carry only counters.
Alerting on the change in those counters does not require
mirroring BGP PDUs.
That is a scalable signal for unusual BGP activity. The
statistics do not identify the cause or whether the activity
is an attack. A high PDU rate may be legitimate routing
activity. A low rate does not by itself indicate a healthy
session. They are correlated with Peer Up/Down, Route
Monitoring, RIB statistics, and other telemetry.
3.10. Mapping Use Cases to Statistics
+------+----------------------------------+------------------+
| Use | Operator question | Statistic |
+------+----------------------------------+------------------+
| UC1 | Are hold-timer PDUs still | TBD3 / TBD1 |
| | arriving (KA or UPDATE)? | |
| UC2 | Is the session churning? | TBD1 / TBD2 |
| | (compare with types 1, 2, 13) | |
| UC3 | How many NOTIFICATIONs has this | TBD5 / TBD6 |
| | neighbor sent or received? | |
| UC4 | Is Adj-RIB-Out being requested | TBD7 / TBD8 |
| | for replay? | |
| UC5 | What is the PDU baseline? | TBD9 / TBD10, |
| | | TBD1 / TBD2, |
| | | TBD7 / TBD8 |
| UC6 | Can session PDUs ride the same | Types in |
| | BMP feed as RIBs? | Section 5 |
| UC7 | How much PDU activity since the | All of the above |
| | last discontinuity? | |
| UC8 | Did PDU rates change suddenly? | TBD1-TBD10 |
+------+----------------------------------+------------------+
4. Non-Goals
The following are out of scope of this document:
* Last NOTIFICATION sent or received, and last error code.
Peer Down [RFC7854] already carries the termination reason
and, when applicable, the NOTIFICATION PDU.
* Hold time and keepalive interval. These are negotiated in
OPEN and present in Peer Up. They are configuration, not
periodic PDU statistics.
* NLRI or prefix counts (Appendix A).
* CPU utilization or other platform metrics.
* Implementation-specific internals (queue depth, buffer high-
water, scheduler delay).
* Relaying KEEPALIVE PDUs via Route Monitoring.
5. Statistics Definition
5.1. Format
Encoding follows Section 4.8 of [RFC7854]. Each statistic is
Stat Type (2 octets), Stat Len (2 octets), and Stat Data
(Stat Len octets), all in network byte order.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stat Type | Stat Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stat Data |
~ (Stat Len octets) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TBD1, TBD2, TBD9, and TBD10 are 64-bit Counters (Section 2).
Stat Len MUST be 8. TBD3 to TBD8 are 32-bit Counters as defined
in Section 4.8 of [RFC7854]. Stat Len MUST be 4.
All statistics are session-global (not per-AFI/SAFI). They are
per-peer, scoped by the Per-Peer Header of the Statistics
Report.
Each type MUST appear at most once in a given Statistics Report.
The Per-Peer Header timestamp MUST be the time the counters were
read. In BMPv4, a Timestamp TLV [I-D.ietf-grow-bmp-tlv] MAY
carry the same time and does not change the meaning of
TBD1-TBD10.
If a type is included in a report, a value of zero is valid and
MUST be encoded as zero. A speaker that does not implement a
type MUST omit it. A speaker MAY omit a type it implements if
that type is not enabled (Section 7). A monitoring station MUST
treat an absent type as not present in that report, not as
zero.
5.2. Per-Peer PDU Counters
A received counter is incremented when the BGP message header
has been received and validated (marker and length) and the
Message Type identified. The remainder of the PDU need not
have been read. A PDU that is later rejected, discarded, or
answered with NOTIFICATION is still counted.
A PDU with a framing error (Connection Not Synchronized or
Bad Message Length, Section 6.1 of [RFC4271]) is not counted.
A PDU with an unrecognized Message Type is counted in TBD9
only. A recognized message type that has no type-specific
counter in this document, such as OPEN, is counted only in
TBD9 or TBD10.
A sent counter is incremented when the complete BGP PDU is
passed to the transport for transmission (for example, written
to TCP).
PDUs on a connection that is closed during collision handling
are counted if they were received or sent on that connection.
OPEN and other pre-Established PDUs that are identified still
increment TBD9 or TBD10.
Type = TBD1: (64-bit Counter) BGP UPDATE messages received from
this peer. Increment once per UPDATE PDU, regardless of the
number of NLRIs.
Type = TBD2: (64-bit Counter) BGP UPDATE messages sent to this
peer. Increment once per UPDATE PDU sent.
Type = TBD3: (32-bit Counter) BGP KEEPALIVE messages received
from this peer.
Type = TBD4: (32-bit Counter) BGP KEEPALIVE messages sent to
this peer.
Type = TBD5: (32-bit Counter) BGP NOTIFICATION messages
received from this peer. Increment for each NOTIFICATION
received, including those that cause teardown. Peer Down
does not clear this counter (Section 7). Zero means none
since the last discontinuity, not that the last close was
silent. Last-error content and whether a given teardown
carried a NOTIFICATION remain in Peer Down.
Type = TBD6: (32-bit Counter) BGP NOTIFICATION messages sent to
this peer, including error and administrative Cease (for
example Graceful Shutdown [RFC8326]). This is broader than
IETF BGP YANG "notifications", which typically counts only
error NOTIFICATIONs [I-D.ietf-idr-bgp-model]. The same Peer
Down and zero rules as TBD5 apply.
Type = TBD7: (32-bit Counter) BGP ROUTE-REFRESH messages
[RFC2918] received from this peer. Increment once per
ROUTE-REFRESH PDU received, whether or not the Route Refresh
capability was negotiated, including Enhanced Route Refresh
begin and end markers [RFC7313]. A PDU may still arrive
without that capability. Forcing the counter to zero would
hide it. If the speaker does not implement this type, it
MUST omit it (Section 5.1).
Type = TBD8: (32-bit Counter) BGP ROUTE-REFRESH messages sent
to this peer. Increment once per ROUTE-REFRESH PDU sent,
including Enhanced Route Refresh begin and end markers
[RFC7313] when sent. [RFC2918] does not permit sending
ROUTE-REFRESH unless the neighbor supports the capability.
The same omit rule as TBD7 applies.
Type = TBD9: (64-bit Counter) Total BGP messages of all types
received from this peer. Includes OPEN, UPDATE,
NOTIFICATION, KEEPALIVE, ROUTE-REFRESH, and any other types
the speaker supports. TBD9 is not required to equal the sum
of TBD1, TBD3, TBD5, and TBD7.
Type = TBD10: (64-bit Counter) Total BGP messages of all types
sent to this peer. TBD10 is not required to equal the sum of
TBD2, TBD4, TBD6, and TBD8.
+=======+===========================================+=========+
| Type | Description | Stat |
| | | Len |
+=======+===========================================+=========+
| TBD1 | UPDATE messages received | 8 |
| TBD2 | UPDATE messages sent | 8 |
| TBD3 | KEEPALIVE messages received | 4 |
| TBD4 | KEEPALIVE messages sent | 4 |
| TBD5 | NOTIFICATION messages received | 4 |
| TBD6 | NOTIFICATION messages sent | 4 |
| TBD7 | ROUTE-REFRESH messages received | 4 |
| TBD8 | ROUTE-REFRESH messages sent | 4 |
| TBD9 | Total BGP messages received | 8 |
| TBD10 | Total BGP messages sent | 8 |
+-------+-------------------------------------------+---------+
Table 1: BGP Session PDU Counter Statistics Types
5.3. Application Scope
These statistics MUST NOT be sent for the Loc-RIB peer (Peer
Type 3) [RFC9069]. That peer is the speaker's local RIB, not a
BGP neighbor.
The O flag in the Per-Peer Header MUST be 0, as required for
Statistics Reports [RFC8671].
A speaker MUST NOT send these statistics for a peer until it
has sent Peer Up for that peer. A monitoring station then has a
peer context for the report. A NOTIFICATION that closes the
session is reflected in TBD5 or TBD6 after the next Peer Up.
5.4. BMPv3 and BMPv4 Applicability
These statistics are BMP Statistics Types. They do not require
a new BMP version.
In BMPv3 [RFC7854], each type is encoded as in Section 5.1 and
carried in the stats data of a Statistics Report (Section 4.8
of [RFC7854]).
In BMPv4 [I-D.ietf-grow-bmp-tlv], the same Stat Type, Stat Len,
and Stat Data are enclosed in the mandatory Stats TLV (type 1)
of the Statistics Report. Optional TLVs defined there (for
example Sequence or Timestamp) MAY follow. They do not change
the meaning of TBD1-TBD10. This document does not define new
Stats Reports TLV types.
The Statistics Information TLV
[I-D.ietf-grow-bmp-stats-informational-tlv] applies to gauge
statistics. The types in this document are counters, not
gauges, and do not use that TLV.
IANA is requested to assign type values in the range 0 to 32767
(Section 10). In BMPv4 the most significant bit of the type
marks a vendor-specific statistic, so values of 32768 and above
MUST NOT be used for these types.
5.5. Example
Consider a Statistics Report for one eBGP peer after Peer Up.
The Per-Peer Header O flag is 0. The timestamp is the time the
speaker read the counters. The stats data includes:
* TBD1, Stat Len 8, Stat Data 1000 (UPDATE received)
* TBD3, Stat Len 4, Stat Data 50 (KEEPALIVE received)
* TBD9, Stat Len 8, Stat Data 1060 (total received)
A later report with TBD1 equal to 1200 and the same timestamp
rules gives 200 new UPDATE PDUs in the interval, unless a
discontinuity occurred (Section 7). Type 13, if also present,
can be compared with TBD1 as in Section 3.3.
6. Relation to Existing Mechanisms
These counters complement existing BMP messages. They do not
replace them.
* Peer Up [RFC7854] carries OPEN PDUs and negotiated hold time /
capabilities. This document does not define OPEN counters or
export hold/keepalive interval as statistics.
* Peer Down [RFC7854] carries the teardown reason and, when
applicable, the NOTIFICATION PDU. That is the BMP record of
how that session ended. TBD5 and TBD6 are the speaker's
NOTIFICATION counts for the neighbor (Section 3.4). They do
not replace Peer Down. Peer Down does not clear them.
* Route Monitoring [RFC7854] carries route content. TBD1/TBD2
count UPDATE PDUs. The two numbers need not match the number
of Route Monitoring messages.
* RFC 7854 types 1, 2, and 13 count duplicate advertisements,
duplicate withdrawals, and duplicate UPDATE messages. They
count wasted churn. TBD1 is the total UPDATE received count
they can be compared with (Section 3.3).
* The BGP MIB [RFC4273] defines bgpPeerInUpdates,
bgpPeerOutUpdates, bgpPeerInTotalMessages, and
bgpPeerOutTotalMessages. The IETF BGP YANG model
[I-D.ietf-idr-bgp-model] defines total, updates, and
notifications, and per-AFI/SAFI updates and route-refresh.
Those objects are the same class of counter on a different
protocol. Use Case 6 (Section 3.7) is why they are also
defined as BMP Statistics Types.
* The BMP YANG model [I-D.ietf-grow-bmp-yang] "session-stats"
leaves count BMP messages sent to the monitoring station.
They do not
overlap with TBD1-TBD10.
7. Implementation Considerations
Counters MUST be incremented as specified in Section 5.2.
A speaker MUST NOT send a 64-bit Counter whose value wraps at
2^32. A speaker that keeps a 32-bit internal count for TBD1,
TBD2, TBD9, or TBD10 MUST extend it to 64 bits before encoding,
for example by adding each increase into a 64-bit total at an
interval shorter than a 32-bit wrap. If the speaker cannot
extend the count, it MUST NOT send that type.
These counters are cumulative across BGP session
establishments. Generating a Peer Down message MUST NOT, by
itself, reset them. They reset when the speaker resets them.
That includes process restart, deletion of the neighbor, an
operator clear, and RP failover. Alternative reset models are
listed in Appendix A.
A monitoring station MUST NOT rely only on a decrease in value
to detect a reset. After a restart or clear, the counter may
return to zero and increase again past the last observed value,
which is not a decrease. For a 32-bit Counter, wrap at 2^32 is
also a decrease. For a 64-bit Counter, wrap is not a practical
explanation of a decrease. A monitoring station MUST treat as
a discontinuity at least: a decrease other than 32-bit wrap for
TBD3-TBD8; any decrease of TBD1, TBD2, TBD9, or TBD10; the
start of a new BMP session (a new Initiation message), because
that session may follow a speaker restart; and deletion and
re-creation of the peer. Initiation does not say why it was
sent [RFC7854]. Peer Down followed by Peer Up is not, by
itself, a counter discontinuity.
This document does not define a "counter discontinuity time"
statistic. Without that type (Appendix A), a monitoring
station cannot detect an operator clear or an RP failover from
the Statistics Report. Those events are discontinuities only
when known by other means.
Speakers SHOULD make inclusion of each type configurable. They
are not required to send every supported type in every
Statistics Report. Sending all types at a short interval for a
large number of peers can impose unnecessary load. The BMP YANG
model [I-D.ietf-grow-bmp-yang] currently configures the report
interval, not per-type enablement. A later YANG revision, or
a Monitoring Options message
[I-D.geng-grow-bmp-monitor-options], may fill that gap. A
monitoring station MUST treat an omitted type as not present in
that report, not as zero. Interaction with BMP route filtering:
PDU counters reflect the BGP session, not the subset of routes
exported to the monitoring station.
8. Operational Considerations
Reporting interval SHOULD be configurable, as for other BMP
Statistics. Operators SHOULD enable only the types they need.
A monitoring station derives a rate from successive
observations. If C1 and C2 are consecutive counter values and
T1 and T2 are the corresponding Per-Peer Header timestamps, the
rate is (C2-C1)/(T2-T1), subject to wrap and discontinuity
handling (Section 7).
For UC1, an interval shorter than the negotiated Hold Time is
needed if the operator wants two reports before hold expiry.
That interval is often not practical at large peer scale. The
common default (for example 600 seconds in BMP YANG examples) is
longer than a typical 90 to 180 second Hold Time. UC1 does not
require every type in this document on a short interval.
Flattening inbound KEEPALIVE while inbound UPDATE is still
incrementing is not a hold-timer stall [RFC4271]. Both
flattening while the peer remains Established may indicate a
stall, subject to the reporting interval. TBD5 and TBD6 are a
neighbor-level NOTIFICATION count, not a substitute for Peer
Down on a given teardown. UPDATE rate thresholds are local
operational policy, not values defined in this document.
In BMPv3 these types use the Statistics Report encoding in
Section 4.8 of [RFC7854]. In BMPv4 they are carried inside the
Stats TLV (Section 5.4). They do not require a new BMP message
type.
9. Security Considerations
PDU counters show session activity volume. They may reveal
operational characteristics such as routing activity level or
neighbor instability. Section 11 of [RFC7854] applies.
Implementations SHOULD require manual configuration of BMP
sessions, as recommended there, and SHOULD use IPsec as
recommended there. BMP over TCP-AO [I-D.ietf-grow-bmp-tcp-ao]
or TLS [I-D.hmntsharma-grow-bmp-over-tls] may also be used where
available.
These counters are not a complete view of session integrity.
A high message rate may be legitimate routing activity. A low
message rate does not by itself indicate a secure or healthy
session. Operators SHOULD correlate them with Peer Up/Down and,
where needed, Route Monitoring.
10. IANA Considerations
IANA is requested to assign the following entries in the "BMP
Statistics Types" registry
(https://www.iana.org/assignments/bmp-parameters/). That
registry is defined in [RFC7854]. [RFC9515] updates its
registration procedures. Assignments are requested in the
range 0 to 32767 (Standards Action). After working group
adoption, early allocation under [RFC7120] is expected.
+-------+--------------------------------------------------+
| Type | Description |
+-------+--------------------------------------------------+
| TBD1 | Number of BGP UPDATE messages received |
| TBD2 | Number of BGP UPDATE messages sent |
| TBD3 | Number of BGP KEEPALIVE messages received |
| TBD4 | Number of BGP KEEPALIVE messages sent |
| TBD5 | Number of BGP NOTIFICATION messages received |
| TBD6 | Number of BGP NOTIFICATION messages sent |
| TBD7 | Number of BGP ROUTE-REFRESH messages received |
| TBD8 | Number of BGP ROUTE-REFRESH messages sent |
| TBD9 | Total number of BGP messages received |
| TBD10 | Total number of BGP messages sent |
+-------+--------------------------------------------------+
Table 2: Requested IANA BMP Statistics Type Assignments
The Reference field for each assignment is this document.
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC2918] Chen, E., "Route Refresh Capability for BGP-4",
RFC 2918, DOI 10.17487/RFC2918, September 2000,
<https://www.rfc-editor.org/info/rfc2918>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/info/rfc4271>.
[RFC7854] Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP
Monitoring Protocol (BMP)", RFC 7854,
DOI 10.17487/RFC7854, June 2016,
<https://www.rfc-editor.org/info/rfc7854>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in
RFC 2119 Key Words", BCP 14, RFC 8174,
DOI 10.17487/RFC8174, May 2017,
<https://www.rfc-editor.org/info/rfc8174>.
[RFC8671] Evens, T., Bayraktar, S., Lucente, P., Mi, P., and
S. Zhuang, "Support for Adj-RIB-Out in the BGP
Monitoring Protocol (BMP)", RFC 8671,
DOI 10.17487/RFC8671, November 2019,
<https://www.rfc-editor.org/info/rfc8671>.
[RFC9069] Evens, T., Bayraktar, S., Bhardwaj, M., and
P. Lucente, "Support for Local RIB in the BGP
Monitoring Protocol (BMP)", RFC 9069,
DOI 10.17487/RFC9069, February 2022,
<https://www.rfc-editor.org/info/rfc9069>.
11.2. Informative References
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Structure of Management
Information Version 2 (SMIv2)", STD 58, RFC 2578,
DOI 10.17487/RFC2578, April 1999,
<https://www.rfc-editor.org/info/rfc2578>.
[RFC4273] Haas, J., Ed. and S. Hares, Ed., "Definitions of
Managed Objects for BGP-4", RFC 4273,
DOI 10.17487/RFC4273, January 2006,
<https://www.rfc-editor.org/info/rfc4273>.
[RFC7120] Cotton, M., "Early IANA Allocation of Standards Track
Code Points", BCP 100, RFC 7120,
DOI 10.17487/RFC7120, January 2014,
<https://www.rfc-editor.org/info/rfc7120>.
[RFC7313] Patel, K., Chen, E., and B. Venkatachalapathy,
"Enhanced Route Refresh Capability for BGP-4",
RFC 7313, DOI 10.17487/RFC7313, July 2014,
<https://www.rfc-editor.org/info/rfc7313>.
[RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and
K. Patel, "Revised Error Handling for BGP UPDATE
Messages", RFC 7606, DOI 10.17487/RFC7606, August
2015, <https://www.rfc-editor.org/info/rfc7606>.
[RFC8326] Francois, P., Ed., Decraene, B., Ed., Pelsser, C.,
Patel, K., and C. Filsfils, "Graceful BGP Session
Shutdown", RFC 8326, DOI 10.17487/RFC8326, March
2018, <https://www.rfc-editor.org/info/rfc8326>.
[RFC9515] Scudder, J., "Revision to Registration Procedures for
Multiple BMP Registries", RFC 9515,
DOI 10.17487/RFC9515, December 2023,
<https://www.rfc-editor.org/info/rfc9515>.
[RFC9687] Snijders, J., Cartwright-Cox, B., and Y. Qu,
"Border Gateway Protocol 4 (BGP-4) Send Hold Timer",
RFC 9687, DOI 10.17487/RFC9687, November 2024,
<https://www.rfc-editor.org/info/rfc9687>.
[RFC9972] Srivastava, M., Ed., Liu, Y., Lin, C., Ed., and
J. Li, "Advanced BGP Monitoring Protocol (BMP)
Statistics Types", RFC 9972, DOI 10.17487/RFC9972,
May 2026, <https://www.rfc-editor.org/info/rfc9972>.
[I-D.ietf-idr-bgp-model]
Jethanandani, M., Patel, K., Zheng, L., and
P. Lucente, "YANG Model for Border Gateway Protocol
(BGP-4)", Work in Progress, Internet-Draft,
draft-ietf-idr-bgp-model,
<https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-model/>.
[I-D.ietf-grow-bmp-yang]
Cardona, C., Lucente, P., and T. Graf, "YANG data
model for BGP Monitoring Protocol", Work in
Progress, Internet-Draft, draft-ietf-grow-bmp-yang,
<https://datatracker.ietf.org/doc/draft-ietf-grow-bmp-yang/>.
[I-D.ietf-grow-bmp-adj-ribs-filtered]
Lucente, P., Cardona, C., and M. Srivastava,
"Filtering Adj-RIB-In and Adj-RIB-Out to BMP
Receivers", Work in Progress, Internet-Draft,
draft-ietf-grow-bmp-adj-ribs-filtered-01,
<https://datatracker.ietf.org/doc/
draft-ietf-grow-bmp-adj-ribs-filtered/>.
[I-D.ietf-grow-bmp-tlv]
Lucente, P., Gu, Y., Younsi, M., and P. Francois,
"BMP v4: Extended TLV Support for BGP Monitoring
Protocol (BMP)", Work in Progress, Internet-Draft,
draft-ietf-grow-bmp-tlv-21, 21 July 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-grow-bmp-tlv-21>.
[I-D.ietf-grow-bmp-stats-informational-tlv]
Srivastava, M., Kolenchery, S., and C. Lin, "BMP
Statistics Information TLV", Work in Progress,
Internet-Draft,
draft-ietf-grow-bmp-stats-informational-tlv,
<https://datatracker.ietf.org/doc/
draft-ietf-grow-bmp-stats-informational-tlv/>.
[I-D.ietf-grow-bmp-tcp-ao]
"TCP-AO Protection for BGP Monitoring Protocol
(BMP)", Work in Progress, Internet-Draft,
draft-ietf-grow-bmp-tcp-ao,
<https://datatracker.ietf.org/doc/draft-ietf-grow-bmp-tcp-ao/>.
[I-D.hmntsharma-grow-bmp-over-tls]
"BMP over TLS", Work in Progress, Internet-Draft,
draft-hmntsharma-grow-bmp-over-tls,
<https://datatracker.ietf.org/doc/draft-hmntsharma-grow-bmp-over-tls/>.
[I-D.geng-grow-bmp-monitor-options]
"BMP Monitoring Options", Work in Progress,
Internet-Draft,
draft-geng-grow-bmp-monitor-options,
<https://datatracker.ietf.org/doc/draft-geng-grow-bmp-monitor-options/>.
Appendix A. Open Issues
The following items are left for working group discussion.
* Counter reset model. This document specifies option B
(cumulative across session establishments, Section 7).
Option B is incomplete without a "counter discontinuity
time" 64-bit Gauge (seconds since 1970), in the spirit of
ifCounterDiscontinuityTime. This document does not define
that type. Without it, a monitoring station cannot detect
an operator clear or an RP failover from the Statistics
Report (Section 7). Option A resets to zero each time the
session reaches Established, matching the BGP MIB "on this
connection" model, and uses Peer Up as the reset signal.
Option C defines both per-session and cumulative types.
Option A would weaken UC3 and UC7.
* Whether the 64-bit Counter definition belongs in this
document or in a document that updates RFC 7854, and whether
all ten types should use 64-bit Counters.
* A "seconds since last message received" 64-bit Gauge, in the
spirit of bgpPeerInUpdateElapsedTime [RFC4273], as a
complement or alternative to UC1 KEEPALIVE counters.
* Session-state statistics (current session uptime,
Established enter/leave counts, connect-retry count) for a
restarted monitoring station. They are FSM gauges, not PDU
counters.
* Whether TBD7 and TBD8 should count only ROUTE-REFRESH
subtype 0, matching IETF BGP YANG, or all subtypes including
Enhanced Route Refresh markers (this document counts all
ROUTE-REFRESH PDUs).
* Per-AFI/SAFI UPDATE and ROUTE-REFRESH counters, using the
AFI/SAFI layout of RFC 7854 types 9 and 10. The authors
intend to add these. KEEPALIVE, NOTIFICATION, and total
remain session-global.
* Counters for prefixes advertised and withdrawn. An UPDATE
PDU count is not a prefix count.
Authors' Addresses
Aseem Choudhary
Cisco Systems
Email: asechoud@cisco.com
Narasimha Prasad S N
Cisco Systems
Email: snprasad@cisco.com
Choudhary, et al. Expires 29 April 2027 [Page 1]