Global Routing Operations P. Lucente Internet-Draft C. Cardona Updates: 7854 (if approved) C. Petrie Intended status: Standards Track NTT Expires: 2 September 2025 L. Hendriks NLnet Labs 1 March 2025 BMP State Summaries draft-lucente-grow-bmp-offline-01 Abstract BMP (BGP Monitoring Protocol) is perfectly suited for real-time consumption but less ideal in stream processing and off-wire historical scenarios. The main issue is that the ability to correctly parse BGP Update PDUs, carried in BMP Route Monitoring messages, depends on the BGP Capabilities exchanged during the establishment of the BGP session between the peers via BGP Open PDUs. The BGP Open PDUs, carried in BMP Peer Up Notification messages, are exported at the establishment of the BMP session. Similar to BGP, BMP sessions are typically long-lived, so the crucial information to correctly parse subsequent messages of such sessions was possibly sent a relatively long time ago (days, weeks, months). This document introduces the concept of Summaries. It defines a new optional BMP message type, called State Summary, and a new TLV, called Summary Id. A Summary is similar to the initial synchronisation performed upon establishment of the BMP session: all BGP session information is exported in Peer Up Notification messages, and all RIB contents are exported in Route Monitoring messages. All the messages carry the new Summary Id TLV, containing an ID uniquely identifying the summary these messages belong to. The messages are preceded by a State Summary message carrying the same Summary Id TLV, as well as meta-data describing the Summary. 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/. Lucente, et al. Expires 2 September 2025 [Page 1] Internet-Draft BMP State Summaries March 2025 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 2 September 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 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 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. State Summary message format . . . . . . . . . . . . . . . . 4 3.1. Summary Information TLVs . . . . . . . . . . . . . . . . 4 3.1.1. Summary Id TLV . . . . . . . . . . . . . . . . . . . 4 3.1.2. Optional meta-data TLVs . . . . . . . . . . . . . . . 4 3.2. Third party off-wire encoding formats . . . . . . . . . . 6 4. Operational Considerations . . . . . . . . . . . . . . . . . 6 4.1. Summary Id scheme . . . . . . . . . . . . . . . . . . . . 6 4.1.1. Global uniqueness . . . . . . . . . . . . . . . . . . 6 4.1.2. Increasing identifiers . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. Normative References . . . . . . . . . . . . . . . . . . . . 7 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction Correctly parsing BGP Update PDUs included in BMP messages (ie. Route Monitoring) does require a stateful approach by keeping track of capabilities exchanged in the BGP Open PDUs as reported by BMP Peer Up Notification messages. Lucente, et al. Expires 2 September 2025 [Page 2] Internet-Draft BMP State Summaries March 2025 Peer Up Notification messages are sent only during the initial synchronisation at the start of the BMP session, or, whenever a BGP session is established on the monitored router. The necessary information in the BGP Open (and Peer Up Notification) messages may thus have been received long before its needed to parse incoming BGP Updates in Route Monitoring messages. This inevitable stateful approach might be challenging in certain scenarios, such as consuming archived BMP messages or deployments where BMP Stations or processing nodes not necessarily see the (complete) start of every BMP stream. TLV support for BMP Route Monitoring and Peer Down Messages [I-D.ietf-grow-bmp-tlv] defines a Stateless Parsing TLV aimed at including relevant capabilities that have an impact in BGP Update message parsing as part of optional informational TLV in Route Monitoring messages. While the method is valid, in fact it does allow with minor effort to encapsulate BMP in MRT format for offline consumption as documented by Storing BMP messages in MRT Format [I-D.petrie-grow-mrt-bmp], it comes with some drawbacks like extra verbosity and increased correlation effort at a BMP exporter, where resources may be limited. Similar to how the necessary information carried in the BGP Open messages is sent from the exporter to the station only in the beginning of a BMP session (in forms of Peer Up Notifications), the contents of the RIBs is also only sent at the beginning (in forms of Route Monitoring messages). In other words, to make correct and complete sense of offline BMP data, both current state (RIB contents) and session details (BGP Open Capabilities) to parse future state changes are required. This document introduces Summaries, enabling synchronisation of both BGP session information and RIB contents anywhere in a BMP session. Summaries are enabled by the new optional State Summary message type and the new Summary Id TLV, both introduced in this document. A Summary is a collection of Peer Up Notification messages, Route Monitoring messages and a single State Summary message, all carrying the newly introduced Summary Id TLV containing the unique identifier for that Summary. The State Summary message further contains TLVs with meta-data describing when the Summary was created, information on the exporting side such as sysName and IP address, and/or information on the collecting side such as BMP station software name and version, etc. The new concepts described in this document are not restricted to either the BMP exporter or the BMP station. By building upon TLVs, supported in all BMP message types from BMPv4, the Summary approach imposes minimal requirements over the initial synchronisation in BMP today. Furthermore, if at any point in the future another message Lucente, et al. Expires 2 September 2025 [Page 3] Internet-Draft BMP State Summaries March 2025 type needs to be incorporated in a Summary, it will be a simple matter of attaching the Summary Id TLV to those messages. No existing message types have to be adapted to support Summaries. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC 2119 [RFC2119] RFC 8174 [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. State Summary message format The State Summary message starts with a BMP Common Header as defined in Section 4.1 of [RFC7854]. The Common Header is directly followed by TLVs. The Summary Id TLV defined in Section 3.1.1 MUST be present and SHOULD be the first of the TLVs. All additional TLVs listed in Section 3.1.2 are optional. The State Summary message can be generated by a BMP exporter or by a BMP station, as long as all required data for the Peer Up Notification and Route Monitoring messages pertaining to the Summary are available. The State Summary message MUST be followed by those messages, with the Summary Id TLV attached. 3.1. Summary Information TLVs 3.1.1. Summary Id TLV The Summary Id TLV is the only mandatory TLV of a State Summary message as defined in Section 3. It is an indexed TLV (as it will be included in Route Monitoring messages, with index zero), structured as defined in Section 4 of [I-D.ietf-grow-bmp-tlv], with a fixed value length of 16 bytes. This allows the use of UUID identifiers, or provides sufficient space for alternative schemes. Different approaches for schemes are discussed in Section 4. 3.1.2. Optional meta-data TLVs The Peer Summary message SHOULD carry TLVs providing additional information on the BMP session being summarized. These Summary Information TLVs describe the BMP exporter and station involved, and the date and time the summary was generated. By embedding these TLVs in the offline file, a consumer of the file does not have to rely on the filename or other external data to get these types of information. All TLVs are non-indexed. Lucente, et al. Expires 2 September 2025 [Page 4] Internet-Draft BMP State Summaries March 2025 * Type = TBD3: Datetime of summary Length: 8 bytes Value: 64bit UNIX epoch, in seconds * Type = TBD4: Exporter IP address Length: 16 bytes Value: IPv6 or IPv4-mapped IPv6 address * Type = TBD5: Exporter sysName Length: variable, non-zero, describing the number of bytes Value: UTF-8 string * Type = TBD6: Exporter sysDesc Length: variable, non-zero, describing the number of bytes Value: UTF-8 string * Type = TBD7: Station IP address Length: variable, non-zero, describing the number of bytes Value: IPv6 or IPv4-mapped IPv6 address * Type = TBD8: Station sysName Length: variable, non-zero, describing the number of bytes Value: UTF-8 string * Type = TBD9: Station sysDesc Length: variable, non-zero, describing the number of bytes Value: UTF-8 string Lucente, et al. Expires 2 September 2025 [Page 5] Internet-Draft BMP State Summaries March 2025 3.2. Third party off-wire encoding formats While this document does define a way to facilitate stream processing, replay and, more in general, consumption of raw BMP data offline, similar benefits may be harnessed by third party off-wire formats in replay and, more in general, consumption of raw BMP data offline, similar benefits may be harnessed by third party off-wire formats in which BMP can be encapsulated into, for example MRT (Multi-Threaded Routing Toolkit) as defined by RFC 6396 [RFC6396]. As a result of that, this document does not recommend a preferred way to stream process or store BMP data offline. 4. Operational Considerations 4.1. Summary Id scheme The generation and form of the Summary Ids introduced in this document is left to implementations. This document does not enforce any specific approach, though at least the following points should be considered. Note that implementations are not limited to supporting only one Id scheme, but ideally support multiple schemes via local configuration. 4.1.1. Global uniqueness In deployments where information is received from multiple BMP vantage points, unique Summary Ids might prove handy or even crucial in order to distinguish Summary A originally sent by BMP exporter X, from Summary B sent by exporter Y. If all exporting processes rely on an algorithm producing globally unique identifiers, e.g. UUID version 4, they all can send out Summaries without possibly using an identical Summary Id generated by another exporter. 4.1.2. Increasing identifiers Generating (linearly) increasing identifiers enable the BMP station to order Summaries, and, to spot any missing Summaries. Furthermore, in a (long running) BMP session where the exporter generates Summaries, the Summary Id doubles as a counter signalling how many Summaries have been sent so far. Note that some of these can be deduced via other means: ordering of Summaries can be done based on the Timestamp TLV (TBD3), and the number of sent Summaries could be included in the Stats Report message (Section 4.8 of [RFC7854]). 5. Security Considerations It is not believed that this document adds any additional security considerations. Lucente, et al. Expires 2 September 2025 [Page 6] Internet-Draft BMP State Summaries March 2025 6. IANA Considerations IANA is asked to allocate a new Peer Summary message type in the BMP Message Types registry with value TBD1. IANA is also asked to to create a registry within the BMP group, named "BMP Peer Summary Message TLVs". Registration procedures for this registry are: +=============+==========================+ | Range | Registration Procedures | +=============+==========================+ | 0-32767 | Standards Action | +-------------+--------------------------+ | 32768-65530 | First Come, First Served | +-------------+--------------------------+ | 65531-65534 | Experimental | +-------------+--------------------------+ | 65535 | Reserved | +-------------+--------------------------+ Table 1 Initial values for this registry are: +======+=============+===============+ | Type | Description | Reference | +======+=============+===============+ | TBD2 | Peer | this document | +------+-------------+---------------+ Table 2 7. Normative References [I-D.ietf-grow-bmp-rel] Lucente, P. and C. Cardona, "Logging of routing events in BGP Monitoring Protocol (BMP)", Work in Progress, Internet-Draft, draft-ietf-grow-bmp-rel-02, 8 July 2024, . Lucente, et al. Expires 2 September 2025 [Page 7] Internet-Draft BMP State Summaries March 2025 [I-D.ietf-grow-bmp-tlv] Lucente, P. and Y. Gu, "BMP v4: TLV Support for BGP Monitoring Prtoocol (BMP) Route Monitoring and Peer Down Messages", Work in Progress, Internet-Draft, draft-ietf- grow-bmp-tlv-16, 24 February 2025, . [I-D.petrie-grow-mrt-bmp] Petrie, C., "Storing BMP messages in MRT Format", Work in Progress, Internet-Draft, draft-petrie-grow-mrt-bmp-00, 1 November 2019, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC6396] Blunk, L., Karir, M., and C. Labovitz, "Multi-Threaded Routing Toolkit (MRT) Routing Information Export Format", RFC 6396, DOI 10.17487/RFC6396, October 2011, . [RFC7854] Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP Monitoring Protocol (BMP)", RFC 7854, DOI 10.17487/RFC7854, June 2016, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Acknowledgements TBD Authors' Addresses Paolo Lucente NTT Veemweg 23 3771 MT Barneveld Netherlands Email: paolo@ntt.net Lucente, et al. Expires 2 September 2025 [Page 8] Internet-Draft BMP State Summaries March 2025 Camilo Cardona NTT 164-168, Carrer de Numancia 08029 Barcelona Spain Email: camilo@ntt.net Colin Petrie NTT Veemweg 23 3771 MT Barneveld Netherlands Email: colin@ntt.net Luuk Hendriks NLnet Labs Science Park 400 1098 XH Amsterdam Netherlands Email: luuk@nlnetlabs.nl Lucente, et al. Expires 2 September 2025 [Page 9]