Definition for Aggregated BMP Route Monitoring Message
draft-liu-grow-bmp-rm-aggregated-00
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Yisong Liu , Changwang Lin | ||
| Last updated | 2024-01-05 | ||
| 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-00
Network Working Group Y. Liu
Internet Draft China Mobile
Intended status: Standards Track C. Lin
Expires: July 5, 2024 New H3C Technologies
January 5, 2024
Definition for Aggregated BMP Route Monitoring Message
draft-liu-grow-bmp-rm-aggregated-00
Abstract
This document proposes a 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 July 5, 2024.
Copyright Notice
Copyright (c) 2024 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
(http://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 Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
liu, et al. Expires July 5, 2024 [Page 1]
Internet-Draft Aggregated BMP Route Monitoring Message January 2024
Table of Contents
1. Introduction .................................................. 2
2. Requirements Language ......................................... 4
3. Aggregated Route Monitoring Definition ........................ 4
4. Aggregated Route Monitoring Message Format .................... 5
5. Security Considerations ....................................... 6
6. IANA Considerations ........................................... 6
7. Normative References........................................... 6
Authors' Addresses ............................................... 7
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
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.
When sending multiple routes with the same attributes to multiple
peers, BGP UPDATE PDU information needs to be assembled once for
each peer (as shown in Figure 2). This implementation has low packet
assembly efficiency. In order to improve the efficiency of packet
assembly, equipment from all manufacturers implements group
packaging, that is, multiple peers form a group, and only one BGP
UPDATE PDU is assembled for the peer group, and then sent to the
liu, et al. Expires July 5, 2024 [Page 2]
Internet-Draft Aggregated BMP Route Monitoring Message January 2024
peers in the group (such as Figure 3). When assembling BGP UPDATE
PDU by peer group, if the routing attributes sent to a peer are
different from those of other peers, just modify the packaged BGP
UPDATE PDU when sending to the peer.
+--------+ +---------+ +-----------------+
| |----->|Packaging|----->|Sending to Peer 1|
| | +---------+ +-----------------+
| | ~
|Prefixes| ~
| | +---------+ +-----------------+
| |----->|Packaging|----->|Sending to Peer N|
+--------+ +---------+ +-----------------+
Figure 2: BGP Encapsulation by Peer
+--------+ +---------+ +-----------------+
| | | |----->|Sending to Peer 1|
| | | | +-----------------+
| | | | ~
|Prefixes|----->|Packaging| ~
| | | | +-----------------+
| | | |----->|Sending to Peer N|
+--------+ +---------+ +-----------------+
Figure 3: BGP Encapsulation by Peer Group
The comparison of packet assembly by peer and peer group is shown in
Figure 4. It can be clearly seen that assembling packets by peer
group can greatly improve packet performance. 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.
+------------------------------------------------------------+
| Encapsulation by Peer | Encapsulation by Peer Group |
+------------------------------------------------------------+
| N Peers | N Peers of Peer Group |
+------------------------------------------------------------+
| N Times Packaging | 1 Times Packaging |
+------------------------------------------------------------+
| N Times Sending | N Times Sending |
+------------------------------------------------------------+
Figure 4: Comparison of Two Packaging Methods
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 group, the different
liu, et al. Expires July 5, 2024 [Page 3]
Internet-Draft Aggregated BMP Route Monitoring Message January 2024
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 5 and 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 Peer
+--------+ +------------------------+ +-----------------+
|Prefixes|----->|Packaging for Peer Group|----->|Sending to Server|
+--------+ +------------------------+ +-----------------+
Figure 6: BMP Encapsulation by Peer 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.
2. 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].
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: Peer-Group Route Monitoring, Recommended value
7.
liu, et al. Expires July 5, 2024 [Page 4]
Internet-Draft Aggregated BMP Route Monitoring Message January 2024
4. Aggregated Route Monitoring Message Format
This section defines the aggregated BMP route monitoring message
format, as shown in Figure 7, 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 prefix, and the Multi-Peer Header will be
defined below.
+------------------------------+
| Common Header |
+------------------------------+
| Multi-Peer Header |
+------------------------------+
| BGP Update PDU |
|+----------------------------+|
|| BGP PATH Attributes ||
|+----------------------------+|
|| Prefixes ||
|+----------------------------+|
+------------------------------+
Figure 7: BMP Peer-Group Route Monitoring Message Format
As shown in Figure 8, 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 |
+-----------------------------------------------+
| BGP PATH Attribute Length N (2 bytes) |
+-----------------------------------------------+
| BGP PATH Attributes N |
+-----------------------------------------------+
Figure 8: Multi-Peer Header Format
liu, et al. Expires July 5, 2024 [Page 5]
Internet-Draft Aggregated BMP Route Monitoring Message January 2024
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.
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).
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>.
liu, et al. Expires July 5, 2024 [Page 6]
Internet-Draft Aggregated BMP Route Monitoring Message January 2024
Authors' Addresses
Yisong Liu
China Mobile
China
Email: liuyisong@chinamobile.com
Changwang Lin
New H3C Technologies
China
Email: linchangwang.04414@h3c.com
liu, et al. Expires July 5, 2024 [Page 7]