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,
<https://datatracker.ietf.org/doc/html/draft-ietf-grow-
bmp-rel-02>.
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,
<https://datatracker.ietf.org/doc/html/draft-ietf-grow-
bmp-tlv-16>.
[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, <https://datatracker.ietf.org/doc/html/
draft-petrie-grow-mrt-bmp-00>.
[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/info/rfc2119>.
[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,
<https://www.rfc-editor.org/info/rfc6396>.
[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>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
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]