Network Working Group Y. Liu
Internet Draft China Mobile
Updates: 7854 (if approved) C. Lin
Intended status: Standards Track New H3C Technologies
Expires: December 16, 2025 M. Srivastava
Juniper Networks
P. Narasimha
Cisco Systems, Inc.
June 16, 2025
Definition for Aggregated BMP Route Monitoring Message
draft-liu-grow-bmp-rm-aggregated-03
Abstract
This document proposes an aggregated BMP route monitoring message.
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 network overhead.
This document updates RFC 7854 by adding new BMP Messages type.
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 December 16, 2025.
Copyright Notice
Copyright (c) 2025 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
liu, et al. Expires December 16, 2025 [Page 1]
Internet-Draft Aggregated BMP Route Monitoring Message June 2025
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.....................................3
2. Solution.......................................................3
2.1. Current BGP Group Packaging...............................3
2.2. BMP send batching optimization............................4
3. Aggregated Route Monitoring Definition.........................6
4. Aggregated Route Monitoring Message Format.....................6
4.1. Route Monitoring Message..................................7
4.2. Support for various RIB-Views.............................8
4.3. Examples of multi-peer headers............................8
5. Security Considerations.......................................10
6. IANA Considerations...........................................10
7. Normative References..........................................11
Authors' Addresses...............................................12
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 December 16, 2025 [Page 2]
Internet-Draft Aggregated BMP Route Monitoring Message June 2025
Currently, a piece of BMP route monitoring message can only contain
one Common Header, one Per-Peer Header and one BGP Update PDU, and
the BGP Update PDU can contain multiple non-repeatable BGP PATH
attributes and prefixes.
This document proposes an aggregated BMP route monitoring message.
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 network overhead.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
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 2, group packaging
greatly improves the performance of BGP packaging and sending.
+---------------------------------------------------------------+
| +----------+ AS |
| | RR1 | |
| +-+-+-+-+--+ |
| | | | | IBGP |
liu, et al. Expires December 16, 2025 [Page 3]
Internet-Draft Aggregated BMP Route Monitoring Message June 2025
| | | | +---------------------------------------------+ |
| | | +------------------------------+ | |
| | +---------------+ | | |
| | | | | |
| +-+------+ +--+-----+ +--+-----+ +--+-----+ |
| | Client | ... | Client | ... | Client | ... | Client | |
| +-+------+ +--+-----+ +--+-----+ +--+-----+ |
| | | | | |
| | +---------------+ | | |
| | | +------------------------------+ | |
| | | | +---------------------------------------------+ |
| | | | | IBGP |
| +-+-+-+-+--+ |
| | RR2 | |
| +----------+ |
+---------------------------------------------------------------+
Figure 2: Typical application scenarios for group packaging
Figure 2 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 3. 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 |
+----------------------------------------------------------------+
Figure 3: 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.
liu, et al. Expires December 16, 2025 [Page 4]
Internet-Draft Aggregated BMP Route Monitoring Message June 2025
However, BMP messages are handled on a per-neighbor basis, which
means they cannot take advantage of the BGP send batching
functionality.
From the perspective of BMP packet format, if BMP 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 message information is different depending on the
peer, and needs to be sent to the monitoring server multiple times,
which increases 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 Figures 4 and 5, 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 4: BMP Encapsulation by Peer
+--------+ +-----------------------------+ +-----------------+
|Prefixes|--->|Packaging for Packaging Group|--->|Sending to Server|
+--------+ +-----------------------------+ +-----------------+
Figure 5: BMP Encapsulation by Peer packaging Group
This document defines this aggregated BMP routing monitoring
message, and its format has been greatly adjusted based on the
original BMP routing monitoring message format, see section 4 for
its detailed format.
liu, et al. Expires December 16, 2025 [Page 5]
Internet-Draft Aggregated BMP Route Monitoring Message June 2025
3. Aggregated Route Monitoring Definition
This section adds a new BMP message type for BMP route monitoring,
which is populated in the message type field of the Common Header.
Message Type = TBD: Aggregated Route Monitoring, Recommended value
7.
4. Aggregated Route Monitoring Message Format
This section defines the aggregated BMP route monitoring message
format, as shown in Figure 6, including Common Header, Multi-Peer
Header and BGP Update PDU. Among them, the Common Header is the same
as that defined in [RFC7854], the BGP Update PDU contains the same
BGP PATH attribute and prefixes, and the Multi-Peer Header will be
defined below.
+------------------------------+
| Common Header |
+------------------------------+
| Multi-Peer Header |
+------------------------------+
| BGP Update PDU |
|+----------------------------+|
|| BGP PATH Attributes ||
|+----------------------------+|
|| Prefixes ||
|+----------------------------+|
+------------------------------+
Figure 6: BMP Aggregated Route Monitoring Message Format
As shown in Figure 7, the format of the Multi-Peer Header in the BMP
aggregated route monitoring message is defined, which contains
multiple Per-Peer Headers. Each Per-Peer Header could carry the
unique BGP PATH attribute of the corresponding peer route. If no BGP
PATH attribute is carried, the corresponding BGP PATH attribute
length must be 0.
+-----------------------------------------------+
| Per-Peer Header 1 |
+-----------------------------------------------+
| BGP PATH Attribute Length 1 (2 bytes) |
+-----------------------------------------------+
| BGP PATH Attributes 1 |
+-----------------------------------------------+
~
+-----------------------------------------------+
| Per-Peer Header N |
liu, et al. Expires December 16, 2025 [Page 6]
Internet-Draft Aggregated BMP Route Monitoring Message June 2025
+-----------------------------------------------+
| BGP PATH Attribute Length N (2 bytes) |
+-----------------------------------------------+
| BGP PATH Attributes N |
+-----------------------------------------------+
Figure 7: Multi-Peer Header Format
In the Multi-Peer Header format, the Per-Peer Header format is the
same as that defined in [RFC7854].
BGP PATH Attribute Length (2 bytes) indicates the length of the BGP
PATH attribute in the Multi-Peer Header.
The format of the BGP PATH Attribute in the Multi-Peer Header is the
same as that in the BGP Update PDU. The BGP PATH Attribute area 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 BGP
PATH attribute area 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 in the BGP Update PDU will be empty.
If the BGP PATH Attribute in Multi-Peer Header exists, it means that
the BGP PATH Attribute of the BGP Update PDU needs to be integrated
with the BGP PATH Attribute of 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.
The BGP PATH Attributes in Multi-Peer Header is optional. A 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.1. Route Monitoring Message
Sender MUST send either the Route Monitoring Message (type 0) as
defined in [RFC7854] OR the Aggregate Route Monitoring Message and
MUST NOT combine the two message formats in the updates
liu, et al. Expires December 16, 2025 [Page 7]
Internet-Draft Aggregated BMP Route Monitoring Message June 2025
4.2. 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.3. Examples of multi-peer headers
Figure 8: Multiple peers (3) with no per-peer header PATH attributes
along with all PATH attributes from BGP Update PDU being shared.
+-----------------------------------------------+
| Per-Peer Header 1 |
+-----------------------------------------------+
| Per-Peer Header 2 |
+-----------------------------------------------+
| Per-Peer Header 3 |
+-----------------------------------------------+
| BGP Update PDU |
|+----------------------------+ |
|| BGP PATH Attributes | |
|+----------------------------+ |
|| Prefixes | |
|+----------------------------+ |
+-----------------------------------------------+
Figure 8: Multiple peers (3) with no per-peer header
Figure 9: Multiple peers (3) with one of the peers having different
PATH attribute along with shared PATH attributes in the BGP Update
PDU.
+-----------------------------------------------+
| Per-Peer Header 1 |
+-----------------------------------------------+
| BGP PATH Attribute 1 Length |
+-----------------------------------------------+
| BGP PATH Attribute 1 |
| |
+-----------------------------------------------+
| Per-Peer Header 2 |
+-----------------------------------------------+
liu, et al. Expires December 16, 2025 [Page 8]
Internet-Draft Aggregated BMP Route Monitoring Message June 2025
| Per-Peer Header 3 |
+-----------------------------------------------+
| BGP Update PDU |
|+----------------------------+ |
|| BGP PATH Attributes | |
|+----------------------------+ |
|| Prefixes | |
|+----------------------------+ |
+-----------------------------------------------+
Figure 9: Multiple peers (3) with one of the peers having different
PATH attribute
Figure 10: Multiple peers (3) with all the peers having different
PATH attributes along with shared PATH attributes in BGP Update PDU.
+-----------------------------------------------+
| Per-Peer Header 1
+-----------------------------------------------+
| BGP PATH Attribute Length 1 |
+-----------------------------------------------+
| BGP PATH Attributes 1 |
+-----------------------------------------------+
| Per-Peer Header 2 |
+-----------------------------------------------+
| BGP PATH Attribute 2 |
+-----------------------------------------------+
| BGP PATH Attributes Length 2 |
+-----------------------------------------------+
| Per-Peer Header 3 |
+-----------------------------------------------+
| BGP PATH Attribute 3 |
+-----------------------------------------------+
| BGP PATH Attributes Length 3 |
+-----------------------------------------------+
| BGP Update PDU |
|+----------------------------+ |
|| BGP PATH Attributes | |
|+----------------------------+ |
|| Prefixes | |
|+----------------------------+ |
+-----------------------------------------------+
Figure 10: Multiple peers (3) with all the peers having different
PATH attributes along with share BGP Path
liu, et al. Expires December 16, 2025 [Page 9]
Internet-Draft Aggregated BMP Route Monitoring Message June 2025
Figure 11: Multiple peers (3) with all the peers having different
PATH attributes along with no shared PATH attributes in BGP Update
PDU
+-----------------------------------------------+
| Per-Peer Header 1 |
+-----------------------------------------------+
| BGP PATH Attribute Length 1 |
+-----------------------------------------------+
| BGP PATH Attributes 1 |
+-----------------------------------------------+
| Per-Peer Header 2 |
+-----------------------------------------------+
| BGP PATH Attribute 2 |
+-----------------------------------------------+
| BGP PATH Attributes Length 2 |
+-----------------------------------------------+
| Per-Peer Header 3 |
+-----------------------------------------------+
| BGP PATH Attribute 3 |
+-----------------------------------------------+
| BGP PATH Attributes Length 2 |
+-----------------------------------------------+
+-----------------------------------------------+
| BGP Update PDU |
|+----------------------------+ |
|| Prefixes | |
|+----------------------------+ |
+-----------------------------------------------+
Figure 11: Multiple peers (3) with all the peers having different
PATH attributes along with no share BGP Path
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 that IANA assign the following new parameters
to the BMP parameters name space
(https://www.iana.org/assignments/bmp-parameters/bmp-
parameters.xhtml).
liu, et al. Expires December 16, 2025 [Page 10]
Internet-Draft Aggregated BMP Route Monitoring Message June 2025
7. 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/rfc/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>.
[I-D. patki-grow-bmp-common-updates] Patki D. and Narasimha P.,
"Common BMP Route-Monitoring Messages for Routes Unchanged
by Policy" Work in Progress, Internet-Draft, draft-patki-
grow-bmp-common-updates-01, 28 February 2025,
<https://datatracker.ietf.org/doc/html/draft-patki-grow-
bmp-common-updates-01>
liu, et al. Expires December 16, 2025 [Page 11]
Internet-Draft Aggregated BMP Route Monitoring Message June 2025
Authors' Addresses
Yisong Liu
China Mobile
China
Email: liuyisong@chinamobile.com
Changwang Lin
New H3C Technologies
China
Email: linchangwang.04414@h3c.com
Mukul Srivastava
Juniper Networks
10 Technology Park Dr
Westford, MA 01886
United States of America
Email: msri@juniper.net
Prasad S. Narasimha
Cisco Systems, Inc.
Email: snprasad@cisco.com
liu, et al. Expires December 16, 2025 [Page 12]