| Internet-Draft | BMP Multi-Peer Header | July 2026 |
| Liu, et al. | Expires 7 January 2027 | [Page] |
This document proposes a format of multiple peer header for aggregating BMP messages. It can be used to compress multiple BMP messages with per-peer header into one aggregated BMP message, which could reduce the amount of reported BMP messages and reduce network overhead.¶
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 7 January 2027.¶
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.¶
[RFC7854] defines the format of BMP messages including Initiation message, Termination message, Route Monitoring message, Route Mirroring message, Stats Reports message, and Peer Down/Up Notification message. Except Initiation and Termination message, all other BMP messages contain a Per-Peer Header. For BMP messages that include a Per-Peer Header, referred to as BMP Per-Peer message, a common format is defined as shown in Figure 1.¶
+------------------------------+
| Common Header |
+------------------------------+
| Per-Peer Header |
+------------------------------+
| BMP TLV |
+------------------------------+
Depending on the BMP message type in Common Header, the BMP TLV represents the corresponding BMP information.¶
For multiple BMP Per-Peer messages, their BMP TLV may have both identical and differing parts. When transmitting BMP Per-Peer messages of the same type, these messages can be consolidated into a single message, retaining only one copy of the identical parts to reduce the message size, network overhead and improve overall network performance.¶
This document defines a new BMP message type, referred to as Multi-Peer Header message. It can be used to compress multiple BMP messages of same type, each with a per-peer header, into a single aggregated BMP message, which could reduce the amount of reported BMP messages and reduce network overhead.¶
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.¶
This section adds a new BMP message type for Multi-Peer Header, which is populated in the message type field of the Common Header.¶
Message Type = TBD: Multi-Peer Header, Recommended value 7.¶
The Multi-Peer Header mechanism defined in this document serves as a general framework for aggregating any BMP message type that includes a Per-Peer Header. While specific optimizations and detailed formats for particular message types (such as Statistics Reports) may be defined in future extensions, this document establishes the foundational structure that enables such optimizations.¶
This section defines the BMP Multi-Peer Header message format, as shown in Figure 2.¶
+-------------------------------------+
| Common Header (Type = TBD) |
+-------------------------------------+
| Common Multi-Peer Header |
~ ~
+-------------------------------------+
| Common Information |
~ ~
+-------------------------------------+
In the BMP Multi-Peer Header message format, the Common Header is the same as that defined in Section 4.1 of [RFC7854], the Common Multi-Peer Header carries the distinct Per-Peer Information of the corresponding BMP Per-Peer message, and the Common Information comprises the identical part of the corresponding BMP Per-Peer message.¶
The Common Multi-Peer Header format is defined in Section 5. The Common Information format is defined differently based on various Message Types in the Common Multi-Peer Header.¶
This section defines the format of the Common Multi-Peer Header in BMP Multi-Peer Header message, as shown in Figure 3. The Multi-Peer Message Type maps to existing BMP message types that include a Per-Peer Header, as defined in [RFC7854] (such as Route Monitoring, Peer Down Notification and Peer Up Notification).¶
The Common Multi-Peer Header can be used to construct a BMP Multi-Peer Header message with various Multi-Peer Message Type. The Wild Card Per-Peer Header is defined below and is similar to the Per-Peer Header defined in Section 4.2 of [RFC7854]. The Per-Peer Information is the different part of the corresponding BMP Per-Peer message.¶
+--------------------------------------------------------+
| Multi-Peer Message Type (1 byte) |
+--------------------------------------------------------+
| Multi-Peer Message Length (2 byte) |
+--------------------------------------------------------+
| Wild Card Per-Peer Header 1 |
+--------------------------------------------------------+
| Per-Peer Information Length 1 (2 bytes) |
+--------------------------------------------------------+
| Per-Peer Information 1 |
~ ~
+--------------------------------------------------------+
| Wild Card Per-Peer Header N |
+--------------------------------------------------------+
| Per-Peer Information Length N (2 bytes) |
+--------------------------------------------------------+
| Per-Peer Information N |
~ ~
+--------------------------------------------------------+
In the Common Multi-Peer Header format, The Multi-Peer Message Type definition is not included in this document, and it needs to be defined according to the specific application of BMP message type.¶
The Multi-Peer Message Length is the length of Common Multi-Peer Header in bytes (including all Wild Card Per-Peer Headers, Per-Peer Information Lengths, and Per-Peer Information).¶
The Per-Peer Information format can vary based on the various Multi-Peer Message Types. Each Wild Card Per-Peer Header could be followed by its unique/distinct Per-Peer Information corresponding the BMP Per-Peer Message. If no Per-Peer Information follows the Wild Card Per-Peer Header, the corresponding Per-Peer Information Length MUST be set to 0.¶
This document defines an Wild Card Per-Peer Header, that could be used to apply to multiple peers, if desired. It is defined according to Per-Peer Header of [RFC7854], as shown in Figure 4.¶
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer Type | Peer Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer Distinguisher (present based on peer type) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer Address (16 bytes) |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer Mask (16 bytes) |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer AS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer BGP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp (seconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp (microseconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Compared with Per-Peer Header define in Section 4.2 of [RFC7854], the Peer Mask is added to indicate the mask of Peer Address.¶
When Peer Mask is 32 for IPv4 and 128 for IPv6 - the Peer Address is used to indicate a specific peer (like the Peer Address of Per-Peer Header in RFC 7854).¶
When Peer Mask is 0 and Peer Address is 0 - the Wild Card Peer Header applies to for all peers.¶
Other non-zero values of Peer Mask - the Wild Card peer header applies to multiple peers matching 'peer address' AND 'peer mask' criteria.¶
The Multi-Peer Header mechanism defined in this document is designed to optimize the transmission efficiency of BMP [RFC7854] by aggregating messages that share common data across multiple peers. This section outlines several practical use cases where applying the Multi-Peer Header can significantly reduce network overhead and improve processing scalability at the monitoring station.¶
In scenarios where a monitoring router experiences a common failure event (e.g., a link failure, maintenance action, or local software restart) that causes simultaneous BGP session discontinuities with multiple peers, multiple Peer Down Notification messages would typically be generated. These Peer Down Notification messages can be aggregated by using the Multi-Peer Header mechanism.¶
How it works: The Common Information section of the Multi-Peer Header Message
would contain the common Reason code and any associated Reason TLVs
(e.g., descriptive text) that apply to all affected sessions. Each distinct peer
session is then represented by a Wild Card Per-Peer Header (with its specific Peer
Address, AS, etc.) in the Common Multi-Peer Header. The Per-Peer Information
for each may be empty or contain peer-specific details if needed.¶
Benefit: Instead of sending N individual Peer Down Notification messages (each with a full Per-Peer Header and repeated Reason information), a single aggregated message is transmitted. This drastically reduces the number of packets during failure storms, easing the load on the network and the collection system.¶
Route Monitoring and Route Mirroring messages are the core BMP message types that carry actual BGP UPDATE message. When similar BGP UPDATE messages affect multiple peers, aggregation using the Multi-Peer Header mechanism can significantly improve efficiency.¶
How it works: The identical parts of BGP UPDATE PDUs (Protocol Data Unit) form the Common Information section. The Common Multi-Peer Header then lists the different parts of the set of peers (identified by their Wild Card Per-Peer Headers) associated with these BGP UPDATE PDUs.¶
Benefit: Avoids transmitting multiple similar copies of the same, potentially large, BGP UPDATE payload. This is particularly useful for recording widespread routing events or anomalies in a bandwidth-efficient manner.¶
Notes:¶
Route Monitoring: This represents the most straightforward and efficient use case for aggregation. Since standard Route Monitoring messages primarily record which prefixes/paths were advertised or withdrawn by which peer, aggregation does not lose essential information.¶
Route Mirroring: Implementers should be aware that this aggregation loses the precise temporal ordering and per-peer context that might be critical for some debugging purposes. Its use should be configurable and appropriate to the troubleshooting scenario.¶
In scenarios where a monitoring router establishes BGP sessions with multiple peers that share common session parameters, Peer Up Notification messages can be efficiently aggregated using the Multi-Peer Header mechanism.¶
How it works: The 'Common Information' section would contain the shared parts of the Peer Up Notification, such as:¶
Identical local and remote capabilities (if negotiated to be the same across peers)¶
Any other TLVs that are identical across the peer sessions¶
Each distinct peer session is represented by a 'Wild Card Per-Peer Header' containing its specific addressing information (Peer Address, Peer AS, etc.). Peer-specific details, such as local address or unique TLVs, would be placed in the corresponding 'Per-Peer Information' section.¶
Benefit: When establishing sessions with a large group of similarly configured peers (e.g., route reflector clients or peers in a peer group), this aggregation avoids sending numerous nearly identical Peer Up Notification messages. This significantly reduces the initial message storm during network startup or maintenance operations.¶
Note: The effectiveness of this aggregation depends on the degree of commonality in session parameters. Peers within the same administrative group or those configured with identical templates are ideal candidates for this optimization.¶
Statistics Reports messages, which convey various counter values per peer, can also benefit from the Multi-Peer Header mechanism, albeit with different trade-offs.¶
How it works: The 'Common Information' would typically contain only the Stat Type field (identifying which counter is being reported). The actual counter values, which are almost always peer-specific, are placed in the individual 'Per-Peer Information' sections along with their respective 'Wild Card Per-Peer Headers'.¶
Benefit: The primary optimization comes from header compression. Instead of sending N separate BMP messages (each with its own Common Header and Per-Peer Header), a single aggregated message carries one Common Header and multiple concise Per-Peer entries. This reduces:¶
Notes:¶
The aggregated message may become quite large if reporting statistics for many peers, potentially exceeding the MTU and causing fragmentation. Implementations SHOULD provide mechanisms to limit the number of peers included in a single aggregated message or to split large reports appropriately.¶
Since counter values are rarely identical across peers, the compression ratio for Statistics Reports is generally lower than for other message types like Peer Down or Peer Up. However, the reduction in protocol overhead remains significant.¶
The timing of statistics collection and reporting should be considered. Aggregating near-simultaneous reports from multiple peers maintains temporal coherence while reducing message volume.¶
All security considerations for BMP [RFC7854]apply equally to messages using the Multi-Peer Header mechanism.¶
This document requests that IANA assign a following new message type in "BMP Message Types" registry of the BMP parameters namespace (https://www.iana.org/assignments/bmp-parameters/bmp-parameters.xhtml).¶
Type = TBD (recommended value: 7): Multi-Peer Header¶
Additionally, this document creates a new registry for "Multi-Peer Message Types" under the BMP parameters namespace. Future additions to this registry require either Standards Action or IESG Approval.¶