BMP State Summaries

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

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 RFC 8174 when, and only when, they appear in all capitals, as shown here.

The State Summary message starts with a BMP Common Header as defined in Section 4.1 of. The Common Header is directly followed by TLVs. The Summary Id TLV defined in MUST be present and SHOULD be the first of the TLVs. All additional TLVs listed in 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.

The Summary Id TLV is the only mandatory TLV of a State Summary message as defined in . It is an indexed TLV (as it will be included in Route Monitoring messages, with index zero), structured as defined in , 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 .

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. 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

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. As a result of that, this document does not recommend a preferred way to stream process or store BMP data offline.

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.

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.

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 ().

It is not believed that this document adds any additional security considerations.

IANA is asked to allocate a new Peer Summary message type in the BMP Message Types registry with value &IANA_PS_MSG_TYPE;. 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 Initial values for this registry are: Type Description Reference &IANA_PS_CODE_PEER_TLV; Peer this document