Definition for Aggregated BMP Route Monitoring Message
draft-liu-grow-bmp-rm-aggregated-06
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 | Yisong Liu , Changwang Lin , Mukul Kumar Srivastava , Narasimha Prasad | ||
| Last updated | 2026-07-06 | ||
| 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-liu-grow-bmp-rm-aggregated-06
GROW Working Group Y. Liu
Internet-Draft China Mobile
Intended status: Standards Track C. Lin
Expires: 7 January 2027 New H3C Technologies
M. Srivastava
Hewlett Packard Enterprise
P. Narasimha
Cisco Systems, Inc.
6 July 2026
Definition for Aggregated BMP Route Monitoring Message
draft-liu-grow-bmp-rm-aggregated-06
Abstract
This document proposes an aggregated BMP Route Monitoring message
based on the BMP Multi-Peer Header message (draft-liu-grow-bmp-
multiple-peer-header). It can compress multiple BMP Route Monitoring
messages into one aggregated BMP Route Monitoring message to reduce
the amount of reported BMP Route Monitoring messages and reduce the
network overhead.
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 7 January 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.
Liu, et al. Expires 7 January 2027 [Page 1]
Internet-Draft Aggregated BMP Route Monitoring Message July 2026
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Current BGP Group Packaging . . . . . . . . . . . . . . . 4
2.2. BMP Send Batching Optimization . . . . . . . . . . . . . 6
3. Aggregated Route Monitoring Definition . . . . . . . . . . . 7
4. Aggregated Route Monitoring Message . . . . . . . . . . . . . 7
4.1. Message Format for BMPv3 and BMPv4 . . . . . . . . . . . 7
4.2. Route Monitoring Message . . . . . . . . . . . . . . . . 10
4.3. Support for various RIB-Views . . . . . . . . . . . . . . 10
4.4. Examples of Multiple Peers . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
7. Normative References . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction
[RFC7854] defines BMP Route Monitoring message, which is used to send
incremental routes advertised and withdrawn by peers to the
monitoring station. BMP Route Monitoring message consists of Common
Header, Per-Peer Header and BGP Update PDU. Among them, Common
Header and Per-Peer Header are defined in [RFC7854], and the BGP
Update PDU contains the BGP PATH attribute and prefix, as shown in
Figure 1.
+------------------------------+
| Common Header |
+------------------------------+
| Per-Peer Header |
+------------------------------+
| BGP Update PDU |
|+----------------------------+|
|| BGP PATH Attributes ||
|+----------------------------+|
|| Prefixes ||
|+----------------------------+|
+------------------------------+
Figure 1: BMP Route Monitoring Message Structure
Liu, et al. Expires 7 January 2027 [Page 2]
Internet-Draft Aggregated BMP Route Monitoring Message July 2026
[I-D.ietf-grow-bmp-tlv] changes the structure of BMP Route Monitoring
message where the Per-Peer Header is followed by one BGP Message TLV
and optional TLVs, as shown in Figure 2. The BGP Update PDU is
enclosed in the BGP Message TLV, and a Route Monitoring message MUST
contain one BGP Message TLV.
+------------------------------+
| Common Header |
+------------------------------+
| Per-Peer Header |
+------------------------------+
| BGP Message TLV |
|+----------------------------+|
|| BGP Update PDU ||
||+--------------------------+||
||| BGP PATH Attributes |||
||+--------------------------+||
||| Prefixes |||
||+--------------------------+||
|+----------------------------+|
+------------------------------+
| Optional TLVs |
+------------------------------+
Figure 2: BMPv4 Route Monitoring Message Structure
Currently, a piece of BMP Route Monitoring message can contain one
Common Header, one Per-Peer Header, and one BGP Update PDU or one BGP
Message TLV including one BGP Update PDU, and the BGP Update PDU can
contain multiple non-repeatable BGP PATH attributes and prefixes.
[I-D.liu-grow-bmp-multiple-peer-header] defines the Multi-Peer Header
Message to compress multiple BMP Per-Peer messages into one
aggregated BMP message for reducing the reported BMP messages and the
network overhead.
This document proposes an aggregated BMP Route Monitoring message
based on the Multi-Peer Header message. It can compress multiple BMP
Route Monitoring messages into one aggregated BMP Route Monitoring
message, which reduces the amount of reported BMP Route Monitoring
messages and also reduces the network overhead.
Liu, et al. Expires 7 January 2027 [Page 3]
Internet-Draft Aggregated BMP Route Monitoring Message July 2026
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.
2. Solution
2.1. Current BGP Group Packaging
The rapid growth of existing network routing tables and the
complexity of network topology have led to the need for BGP to
support more peers. In particular, in scenarios with a large number
of peers and a large amount of routes, the router needs to send
routes to a large number of BGP peers, and most of the peers have the
same configuration, which requires higher packaging and sending
performance.
The BGP group packaging technology treats all BGP peers with common
configurations as a packaging group. In this way, each route to be
sent is packaged only once and then sent to all neighbors in the
packaging group, which exponentially improves the packaging
efficiency.
Before the group packaging feature was supported, each route to be
sent had to be packaged separately for each peer. Group packaging
enables unified packaging and separate sending, that is, each route
to be sent is packaged only once and then sent to all peers in the
packaging group, which exponentially improves the efficiency of
packaging and sending. In scenarios with a large number of neighbors
and a large amount of routes, as shown in Figure 3, group packaging
greatly improves the performance of BGP packaging and sending.
Liu, et al. Expires 7 January 2027 [Page 4]
Internet-Draft Aggregated BMP Route Monitoring Message July 2026
+---------------------------------------------------------------+
| +----------+ AS |
| | RR1 | |
| +-+-+-+-+--+ |
| | | | | IBGP |
| | | | +---------------------------------------------+ |
| | | +------------------------------+ | |
| | +---------------+ | | |
| | | | | |
| +-+------+ +--+-----+ +--+-----+ +--+-----+ |
| | Client | ... | Client | ... | Client | ... | Client | |
| +-+------+ +--+-----+ +--+-----+ +--+-----+ |
| | | | | |
| | +---------------+ | | |
| | | +------------------------------+ | |
| | | | +---------------------------------------------+ |
| | | | | IBGP |
| +-+-+-+-+--+ |
| | RR2 | |
| +----------+ |
+---------------------------------------------------------------+
Figure 3: Typical Application Scenario for Group Packaging
Figure 3 is a typical network diagram of reflectors with multiple
clients, RR routers need to send routes to a large number of BGP
client peers, and most of the client peers have the same
configuration. Suppose an RR reflector has 100 clients and 100,000
routes to be reflected. If each neighbor is packaged separately,
when the reflector RR sends routes to 100 clients, the total number
of times all routes are packaged is 100,000 x 100. The group
packaging technology reduces this process to 100,000 x 1, which is
equivalent to a 100-fold improvement in performance.
The comparison of packet assembly by peer and peer packaging group is
shown in Figure 4. It can be clearly seen that assembling packets by
peer packaging group can greatly improve packet performance.
+----------------------------------------------------------------+
| Encapsulation by Peer | Encapsulation by Peer Packaging Group |
+----------------------------------------------------------------+
| N Peers | N Peers of Peer Packaging Group |
+----------------------------------------------------------------+
| N Times Packaging | 1 Times Packaging |
+----------------------------------------------------------------+
| N Times Sending | N Times Sending |
+----------------------------------------------------------------+
Liu, et al. Expires 7 January 2027 [Page 5]
Internet-Draft Aggregated BMP Route Monitoring Message July 2026
Figure 4: Comparison of Two Packaging Methods
2.2. BMP Send Batching Optimization
Currently, network devices have implemented BGP send batching
technology. This allows messages with the same attributes to be
batched together and sent to multiple neighbors simultaneously.
However, BMP Route Monitoring message is handled on a per-peer basis,
which means they cannot take advantage of the BGP send batching
functionality.
From the perspective of BMP Route Monitoring packet format, if BMP
Route Monitoring packets are also assembled according to peers, they
need to be assembled once for each peer, and the assembly performance
will also be limited. Moreover, the BMP Route Monitoring message
information may be different depending on the peer, and needs to be
sent to the monitoring server multiple times, which increases the
network overhead.
In multiple BMP Route Monitoring messages, if the prefixes are the
same but the Per-Peer Header and BGP PATH attributes are different,
according to the way of packet assembly by peer packaging group, the
different BGP attributes can be extracted, combined with the
corresponding Per-Peer Header, and reuse of the same BGP PATH
attributes, which together form a aggregated BMP Route Monitoring
message. See section 4 for detailed format of the aggregated BMP
Route Monitoring message. As shown in Figure 5 and Figure 6,
compared with the original multiple BMP Route Monitoring message, the
aggregated BMP Route Monitoring message exponentially reduces the
Common Header and the same BGP PATH attributes and prefixes, and is
only assembled once, which not only effectively the network overhead
is reduced and the assembly performance is further improved.
+--------+ +---------------------+ +-----------------+
| |----->|Packaging for Peer 1 |----->|Sending to Server|
| | +---------------------+ +-----------------+
| | ~
|Prefixes| ~
| | +---------------------+ +-----------------+
| |----->|Packaging for Peer N |----->|Sending to Server|
+--------+ +---------------------+ +-----------------+
Figure 5: BMP Encapsulation by Per-Peer
+--------+ +-------------------------+ +-----------------+
|Prefixes|--->|Packaging for Multi-Peers|--->|Sending to Server|
+--------+ +-------------------------+ +-----------------+
Liu, et al. Expires 7 January 2027 [Page 6]
Internet-Draft Aggregated BMP Route Monitoring Message July 2026
Figure 6: BMP Encapsulation by Multi-Peers
This document defines this aggregated BMP Route Monitoring message,
and its format has been defined based on the Multi-Peer Header
message format defined in Section 4 of
[I-D.liu-grow-bmp-multiple-peer-header], see Section 4 for its
detailed format.
3. Aggregated Route Monitoring Definition
This section adds a new BMP Multi-Peer Message Type for BMP Route
Monitoring, which is populated in the Multi-Peer Message Type field
of the BMP Common Multi-Peer Header defined in Section 5 of
[I-D.liu-grow-bmp-multiple-peer-header].
Multi-Peer Message Type = TBD: Aggregated Route Monitoring,
Recommended value 0.
4. Aggregated Route Monitoring Message
4.1. Message Format for BMPv3 and BMPv4
This section defines two aggregated BMP Route Monitoring message
formats, according to the Route Monitoring message format of
[RFC7854] and [I-D.ietf-grow-bmp-tlv].
Figure 7 shows one aggregated Route Monitoring message format, based
on the Route Monitoring message format of [RFC7854], including Common
Header, Common Multi-Peer Header, and BGP Update PDU. Among them,
the Common Header is the same as that defined in Section 4.1 of
[RFC7854], the BGP Update PDU contains the same BGP PATH attribute
and prefixes, and the Common Multi-Peer Header will be defined below.
+--------------------------------------------------+
| Common Header (Type = Multi-Peer Header) |
+--------------------------------------------------+
| Common Multi-Peer Header |
~ ~
+--------------------------------------------------+
| BGP Update PDU |
|+----------------------------+ |
|| BGP PATH Attributes | |
|+----------------------------+ |
|| Prefixes | |
|+----------------------------+ |
+--------------------------------------------------+
Figure 7: BMP Aggregated Route Monitoring Message Format
Liu, et al. Expires 7 January 2027 [Page 7]
Internet-Draft Aggregated BMP Route Monitoring Message July 2026
Figure 8 shows another aggregated Route Monitoring message format,
based on the BMPv4 Route Monitoring message format of
[I-D.ietf-grow-bmp-tlv], including Common Header, Common Multi-Peer
Header, BGP Message TLV including BGP Update PDU, and optional TLVs.
Among them, the Common Header and the Common Multi-Peer Header are
the same as the above, the BGP Update PDU of the BGP Message TLV also
contains the same BGP PATH attribute and prefixes, and the Optional
TLVs can be shared TLVs or TLVs specific to a particular prefix.
+--------------------------------------------------+
| Common Header (Type = Multi-Peer Header) |
+--------------------------------------------------+
| Common Multi-Peer Header |
~ ~
+--------------------------------------------------+
| BGP Message TLV |
++------------------------------------------+ |
|| BGP Update PDU | |
||+----------------------------+ | |
||| BGP PATH Attributes | | |
||+----------------------------+ | |
||| Prefixes | | |
||+----------------------------+ | |
|+------------------------------------------+ |
+--------------------------------------------------+
| Optional TLVs |
+--------------------------------------------------+
Figure 8: BMPv4 Aggregated Route Monitoring Message Format
As shown in Figure 9, the format of the Common Multi-Peer Header in
the aggregated Route Monitoring message is defined, which contains
multiple Wild Card Per-Peer Headers defined in Section 5 of
[I-D.liu-grow-bmp-multiple-peer-header]. 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 BGP PATH Attributes). Each Wild Card Per-Peer Header could
be followed by the unique Per-Peer BGP PATH attribute of the
corresponding peer route. If no Per-Peer BGP PATH attribute follows,
the corresponding Per-Peer Information length MUST be set to 0.
Liu, et al. Expires 7 January 2027 [Page 8]
Internet-Draft Aggregated BMP Route Monitoring Message July 2026
+--------------------------------------------------------+
| Multi-Peer Message Type (TBD) (1 byte) |
+--------------------------------------------------------+
| Multi-Peer Message Length (2 byte) |
+--------------------------------------------------------+
| Wild Card Per-Peer Header 1 |
+--------------------------------------------------------+
| Per-Peer Information Length 1 (2 bytes) |
+--------------------------------------------------------+
| Per-Peer BGP PATH Attributes 1 |
+--------------------------------------------------------+
~ ~
+--------------------------------------------------------+
| Wild Card Per-Peer Header N |
+--------------------------------------------------------+
| Per-Peer Information Length N (2 bytes) |
+--------------------------------------------------------+
| Per-Peer BGP PATH Attributes N |
+--------------------------------------------------------+
Figure 9: Common Multi-Peer Header Format for Route Monitoring
In the Common Multi-Peer Header format, the Wild Card Per-Peer Header
format is the same as that defined in
[I-D.liu-grow-bmp-multiple-peer-header].
Per-Peer Information Length (2 bytes) indicates the length of the
Per-Peer BGP PATH Attributes in the Common Multi-Peer Header.
The format of the Per-Peer BGP PATH Attribute in the Common Multi-
Peer Header is the same as BGP PATH Attribute in the BGP Update PDU.
The Per-Peer BGP PATH Attribute field does not need to be filled in
when the route attributes corresponding to each peer are exactly the
same. Only when the routing attributes corresponding to the peers
are different to a certain extent, different parts of the routing
attributes need to be filled in Per-Peer BGP PATH Attribute field
according to the peers. The same parts of the routing attributes are
filled in the BGP Update PDU. If the routing attributes
corresponding to each peer are completely different, the routing
attributes (BGP PATH Attribute) in the BGP Update PDU will be empty.
If the Per-Peer BGP PATH Attribute in Common Multi-Peer Header
exists, it means that the BGP PATH Attribute of the BGP Update PDU
needs to be integrated with the Per-Peer BGP PATH Attribute of Common
Multi-Peer Header to obtain the complete BGP PATH Attribute of BGP
UPDATE PDU sent or received to the corresponding peer. Otherwise,
the BGP PATH Attribute of the BGP UPDATE PDU is the complete BGP PATH
Attribute.
Liu, et al. Expires 7 January 2027 [Page 9]
Internet-Draft Aggregated BMP Route Monitoring Message July 2026
The Per-Peer BGP PATH Attributes in Common Multi-Peer Header is
optional. A Common Multi-Peer Header may just include the Per-Peer
Header(s) without any PATH attributes following them.
Multiple aggregated Route Monitoring messages can be used for same or
different set of BGP Update prefixes.
4.2. Route Monitoring Message
Sender MUST send either the Route Monitoring Message (type 0) as
defined in [RFC7854] OR the aggregated Route Monitoring Message and
MUST NOT combine the two message formats in the updates.
4.3. Support for various RIB-Views
Aggregated Route Monitoring messages can be used for any of the RIB-
views (Adj-RIB-In pre, Adj-RIB-In post, Adj-RIB-Out pre, Adj-RIB-Out
post & Local-RIB) when batching is feasible.
Batching across RIB-views with aggregated Route Monitoring Message
can be used leveraging methods defined in
[I-D.patki-grow-bmp-common-updates].
4.4. Examples of Multiple Peers
This Section lists some examples to show how to use the aggregated
Route Monitoring Message based on the Route Monitoring Message format
of [RFC7854].
For the BMPv4 aggregated Route Monitoring Message, its usage is
similar to these examples.
As shown in Figure 10, there are three peers with no per-peer BGP
PATH attributes along with all PATH attributes from BGP Update PDU
being shared.
Liu, et al. Expires 7 January 2027 [Page 10]
Internet-Draft Aggregated BMP Route Monitoring Message July 2026
+-----------------------------------------------+
| Multi-Peer Message Type (TBD) |
+-----------------------------------------------+
| Multi-Peer Message Length |
+-----------------------------------------------+
| Wild Card Per-Peer Header 1 |
+-----------------------------------------------+
| Per-Peer Information Length 1 (0) |
+-----------------------------------------------+
| Wild Card Per-Peer Header 2 |
+-----------------------------------------------+
| Per-Peer Information Length 2 (0) |
+-----------------------------------------------+
| Wild Card Per-Peer Header 3 |
+-----------------------------------------------+
| Per-Peer Information Length 3 (0) |
+-----------------------------------------------+
| BGP Update PDU |
|+----------------------------+ |
|| BGP PATH Attributes | |
|+----------------------------+ |
|| Prefixes | |
|+----------------------------+ |
+-----------------------------------------------+
Figure 10: Three Peers with No Per-Peer BGP PATH Attributes
As shown in Figure 11, there are three peers with one of the peers
having different PATH attribute along with shared PATH attributes in
the BGP Update PDU.
Liu, et al. Expires 7 January 2027 [Page 11]
Internet-Draft Aggregated BMP Route Monitoring Message July 2026
+-----------------------------------------------+
| Multi-Peer Message Type (TBD) |
+-----------------------------------------------+
| Multi-Peer Message Length |
+-----------------------------------------------+
| Wild Card Per-Peer Header 1 |
+-----------------------------------------------+
| Per-Peer Information Length 1 |
+-----------------------------------------------+
| Per-Peer BGP PATH Attributes 1 |
+-----------------------------------------------+
| Wild Card Per-Peer Header 2 |
+-----------------------------------------------+
| Per-Peer Information Length 2 (0) |
+-----------------------------------------------+
| Wild Card Per-Peer Header 3 |
+-----------------------------------------------+
| Per-Peer Information Length 3 (0) |
+-----------------------------------------------+
| BGP Update PDU |
|+----------------------------+ |
|| BGP PATH Attributes | |
|+----------------------------+ |
|| Prefixes | |
|+----------------------------+ |
+-----------------------------------------------+
Figure 11: Three Peers with One Peer Having Different PATH Attribute
As shown in Figure 12, there are three peers with all the peers
having different PATH attributes along with shared PATH attributes in
BGP Update PDU.
Liu, et al. Expires 7 January 2027 [Page 12]
Internet-Draft Aggregated BMP Route Monitoring Message July 2026
+-----------------------------------------------+
| Multi-Peer Message Type (TBD) |
+-----------------------------------------------+
| Multi-Peer Message Length |
+-----------------------------------------------+
| Wild Card Per-Peer Header 1 |
+-----------------------------------------------+
| Per-Peer Information Length 1 |
+-----------------------------------------------+
| Per-Peer BGP PATH Attributes 1 |
+-----------------------------------------------+
| Wild Card Per-Peer Header 2 |
+-----------------------------------------------+
| Per-Peer Information Length 2 |
+-----------------------------------------------+
| Per-Peer BGP PATH Attributes 2 |
+-----------------------------------------------+
| Wild Card Per-Peer Header 3 |
+-----------------------------------------------+
| Per-Peer Information Length 3 |
+-----------------------------------------------+
| Per-Peer BGP PATH Attributes 3 |
+-----------------------------------------------+
| BGP Update PDU |
|+----------------------------+ |
|| BGP PATH Attributes | |
|+----------------------------+ |
|| Prefixes | |
|+----------------------------+ |
+-----------------------------------------------+
Figure 12: Three Peers with All Having Different PATH Attributes
As shown in Figure 13, there are three peers with all the peers
having different PATH attributes along with no shared PATH attributes
in BGP Update PDU.
Liu, et al. Expires 7 January 2027 [Page 13]
Internet-Draft Aggregated BMP Route Monitoring Message July 2026
+-----------------------------------------------+
| Multi-Peer Message Type (TBD) |
+-----------------------------------------------+
| Multi-Peer Message Length |
+-----------------------------------------------+
| Wild Card Per-Peer Header 1 |
+-----------------------------------------------+
| Per-Peer Information Length 1 |
+-----------------------------------------------+
| Per-Peer BGP PATH Attributes 1 |
+-----------------------------------------------+
| Wild Card Per-Peer Header 2 |
+-----------------------------------------------+
| Per-Peer Information Length 2 |
+-----------------------------------------------+
| Per-Peer BGP PATH Attributes 2 |
+-----------------------------------------------+
| Wild Card Per-Peer Header 3 |
+-----------------------------------------------+
| Per-Peer Information Length 3 |
+-----------------------------------------------+
| Per-Peer BGP PATH Attributes 3 |
+-----------------------------------------------+
| BGP Update PDU |
|+----------------------------+ |
|| Prefixes | |
|+----------------------------+ |
+-----------------------------------------------+
Figure 13: Three Peers with All Having Different PATH Attributes
along without Shared Path Attributes
5. Security Considerations
The considerations in Section 11 of [RFC7854] apply to this document.
It is also believed that this document does not add any additional
security considerations.
6. IANA Considerations
This document requests IANA to define one new "BMP Multi-Peer Message
Type" registry to the BMP parameters name space
(https://www.iana.org/assignments/bmp-parameters/bmp-
parameters.xhtml).
The new "BMP Multi-Peer Message Type" registry is seeded with the
following new type (Section 3):
Liu, et al. Expires 7 January 2027 [Page 14]
Internet-Draft Aggregated BMP Route Monitoring Message July 2026
Type = TBD: Aggregated Route Monitoring
7. Normative References
[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-
20, 2 March 2026, <https://datatracker.ietf.org/doc/html/
draft-ietf-grow-bmp-tlv-20>.
[I-D.liu-grow-bmp-multiple-peer-header]
Liu, Y., Lin, C., Prasad, N., and M. K. Srivastava,
"Definition for BMP Multiple Peer Header", Work in
Progress, Internet-Draft, draft-liu-grow-bmp-multiple-
peer-header-01, 25 April 2026,
<https://datatracker.ietf.org/doc/html/draft-liu-grow-bmp-
multiple-peer-header-01>.
[I-D.patki-grow-bmp-common-updates]
Patki, D. and N. Prasad, "Common BMP Route-Monitoring
Messages for Routes Unchanged by Policy", Work in
Progress, Internet-Draft, draft-patki-grow-bmp-common-
updates-02, 20 October 2025,
<https://datatracker.ietf.org/doc/html/draft-patki-grow-
bmp-common-updates-02>.
[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>.
[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>.
Authors' Addresses
Yisong Liu
China Mobile
China
Email: liuyisong@chinamobile.com
Liu, et al. Expires 7 January 2027 [Page 15]
Internet-Draft Aggregated BMP Route Monitoring Message July 2026
Changwang Lin
New H3C Technologies
China
Email: linchangwang.04414@h3c.com
Mukul Srivastava
Hewlett Packard Enterprise
10 Technology Park Dr
Westford, MA 01886
United States of America
Email: mukul.srivastava@hpe.com
Prasad S. Narasimha
Cisco Systems, Inc.
Email: snprasad@cisco.com
Liu, et al. Expires 7 January 2027 [Page 16]