Internet DRAFT - draft-liu-grow-bmp-rm-aggregated

draft-liu-grow-bmp-rm-aggregated



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]