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, . [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 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]