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, . [RFC2918] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918, DOI 10.17487/RFC2918, September 2000, . [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, . [RFC7854] Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP Monitoring Protocol (BMP)", RFC 7854, DOI 10.17487/RFC7854, June 2016, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [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, . [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, . 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, . [RFC4273] Haas, J., Ed. and S. Hares, Ed., "Definitions of Managed Objects for BGP-4", RFC 4273, DOI 10.17487/RFC4273, January 2006, . [RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January 2014, . [RFC7313] Patel, K., Chen, E., and B. Venkatachalapathy, "Enhanced Route Refresh Capability for BGP-4", RFC 7313, DOI 10.17487/RFC7313, July 2014, . [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, . [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, . [RFC9515] Scudder, J., "Revision to Registration Procedures for Multiple BMP Registries", RFC 9515, DOI 10.17487/RFC9515, December 2023, . [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, . [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, . [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, . [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, . [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, . [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, . [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, . [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, . [I-D.hmntsharma-grow-bmp-over-tls] "BMP over TLS", Work in Progress, Internet-Draft, 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, . 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]