Network Working Group Y. Liu Internet Draft China Mobile Intended status: Standards Track C. Lin Expires: January 2, 2025 New H3C Technologies M. Srivastava Juniper Networks July 4, 2024 Definition for Aggregated BMP Route Monitoring Message draft-liu-grow-bmp-rm-aggregated-01 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 January 2, 2025. 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 January 2, 2025 [Page 1] Internet-Draft Aggregated BMP Route Monitoring Message July 2024 Table of Contents 1. Introduction...................................................3 1.1. Requirements Language.....................................3 2. Solution.......................................................3 2.1. Current BGP Group Packaging...............................3 2.2. BMP send batching optimization............................5 3. Aggregated Route Monitoring Definition.........................6 4. Aggregated Route Monitoring Message Format.....................6 5. Security Considerations........................................8 6. IANA Considerations............................................8 7. Normative References...........................................8 Authors' Addresses................................................9 liu, et al. Expires January 2, 2025 [Page 2] Internet-Draft Aggregated BMP Route Monitoring Message July 2024 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. 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 liu, et al. Expires January 2, 2025 [Page 3] Internet-Draft Aggregated BMP Route Monitoring Message July 2024 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 | | | | | +---------------------------------------------+ | | | | +------------------------------+ | | | | +---------------+ | | | | | | | | | | +-+------+ +--+-----+ +--+-----+ +--+-----+ | | | 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 liu, et al. Expires January 2, 2025 [Page 4] Internet-Draft Aggregated BMP Route Monitoring Message July 2024 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. 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. liu, et al. Expires January 2, 2025 [Page 5] Internet-Draft Aggregated BMP Route Monitoring Message July 2024 +--------+ +---------------------+ +-----------------+ | |----->|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. 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 prefix, and the Multi-Peer Header will be defined below. +------------------------------+ | Common Header | +------------------------------+ | Multi-Peer Header | +------------------------------+ | BGP Update PDU | |+----------------------------+| || BGP PATH Attributes || |+----------------------------+| || Prefixes || |+----------------------------+| liu, et al. Expires January 2, 2025 [Page 6] Internet-Draft Aggregated BMP Route Monitoring Message July 2024 +------------------------------+ 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 | +-----------------------------------------------+ | 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 liu, et al. Expires January 2, 2025 [Page 7] Internet-Draft Aggregated BMP Route Monitoring Message July 2024 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, . [RFC7854] Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP Monitoring Protocol (BMP)", RFC 7854, DOI 10.17487/RFC7854, June 2016, . liu, et al. Expires January 2, 2025 [Page 8] Internet-Draft Aggregated BMP Route Monitoring Message July 2024 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 liu, et al. Expires January 2, 2025 [Page 9]