BMP Sequence Number, Timestamp and Flags TLVs

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 4 January 2026.¶

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

This document defines three new BMP Version 4 [I-D.ietf-grow-bmp-tlv] TLVs to enhance the metadata exported by the BMP station.¶

BMP [RFC7854] defines a Timestamp field in the Per-Peer header. This Timestamp field contains the time of reception of a route [RFC7854], the time the route was installed in the local-rib [RFC9069] or the time the routes were advertised to a peer [RFC8671]. As this information is sometimes unavailable in some implementations, some of them abuse this field by filling it with the time of export of the messages, misguiding collectors and operators which assume the value is correct.¶

In this document, we deprecate the Timestamp field of the Per-Peer Header and define a Timestamp TLV that can carry multiple types of Timestamps. This allows implementations of BMP to export all the timestamps available while being explicit about the their meaning.¶

Using a TLV for the timestamp field also allows exporting the timestamp of the Adj-Rib-In in the Local-RIB route monitoring messages. This removes the need to export entire RIBs just for the purpose of obtaining route reception timestamps.¶

Currently, the Timestamp field is also optional, which means it might be zero-filled. When it is the case, timestamp-based ordering of BMP messages cannot work. In this document, we also define a Sequence Number TLV that carries for each message its sequence number. This allows ordering of BMP messages, even when no timestamps are available.¶

Finally, the Flags field of the Per-Peer Header is close to running out of bits to allocate for Adj-In and Adj-Out. We thus move these flags to an extensible TLV that will allow for bits to be allocated more freely. To do that, we allocate the rightmost bit of the Per-Peer Header Flags. This bit indicates that the flags in the TLV MUST be used in place of the ones in the Per-Peer Header.¶

2. Timestamp TLV

In this section, we describe the optional Timestamp TLV. This BMPv4 TLV [I-D.ietf-grow-bmp-tlv] carries one of multiple types of Timestamp for a BMP message.¶

A TLV type "Timestamp TLV" needs to be reserved from the BMP Route Monitoring TLVs registry. The value of the type field of this TLV is TBD1.¶

The value of the TLV is the "Timestamp Type" code, defined in Table 1, followed by the timestamp values expressed in seconds and microseconds since midnight (zero hour), January 1, 1970 (UTC).¶

The encoding of the timestamp is identical to existing BMP documents [RFC7854], [RFC8671], and [RFC9069], except that the timestamp MUST NOT be set to zero to indicate unavailability. The "Timestamp TLV" is optional, a timestamp MUST NOT be included if it is not available.¶

The value of the Length field is 9 bytes (1 byte for the "Timestamp Type" field plus the length of the "Timestamp" fields which are 4 bytes each). The "Index" field is, as described by [I-D.ietf-grow-bmp-tlv], not included in the length.¶

The TLV structure is illustrated in Figure 1.¶

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Type (2 octets)        |       Length (2 octets)       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|G|      Index (2 octets)       | Timestmp Type |               ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~              Timestamp (seconds)              |               ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~            Timestamp (microseconds)           ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The Section 2.1 defines the list of currently defined Timestamp Types.¶

3. Sequence Number TLV

In this section, we describe the Sequence Number TLV. This TLV carries the sequence number of a message in a BMP session.¶

Ordering of BMP messages based on timestamp becomes complicated when timestamps have conflicting meanings or when they are simply unavailable. A Sequence Number on a per BMP session basis allows the operator to easily and uniquely identify BMP messages on a BMP session.¶

A TLV type "Sequence Number TLV" needs to be reserved from the BMP Route Monitoring TLVs registry. The value of the type field of this TLV is TBD2.¶

The value of the TLV is the sequence number of the BMP message in the BMP session, starting at 0, and encoded on 8 bytes.¶

The value of the Length field is 8. The "Index" field is, as described by [I-D.ietf-grow-bmp-tlv], not included in the length.¶

The TLV structure is illustrated in Figure 2.¶

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Type (2 octets)        |       Length (2 octets)       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|G|      Index (2 octets)       |                               ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
~                   Sequence Number (8 octets)                  ~
+                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4. Flags TLV

In this section, we describe the Flags TLV. This TLV carries the Flags field usually present in the Per-Peer Header, while extending the length of the field. This allows for a larger range of flags to be allocated in the future.¶

A TLV type "Flags TLV" needs to be reserved from the BMP Route Monitoring TLVs registry. The value of the type field of this TLV is TBD3.¶

The value of the TLV is a sequence of bytes of variable size. The minimum size of the sequence is one, to fit at least the already existing flags. The first byte of the sequence carries all flags defined previous to this document, that is Flags V, L, A, O, and F. Newly allocated bits will be carried in the following byte of the sequence.¶

The value of the "Length" field is the number of bytes in the sequence. The "Index" field is, as described by [I-D.ietf-grow-bmp-tlv], not included in the length.¶

The "Index" field is set to 0 to indicate the global scope of the TLV.¶

The TLV structure is illustrated in Figure 3.¶

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Type (2 octets)        |       Length (2 octets)       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|G|      Index (2 octets)       |        Flags (Variable)       ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

When this TLV is included in a BMP message, the rightmost bit (X Flag) of the Per-Peer Header Flags MUST be set to 1 to indicate that the flags to consider are carried in this TLV.¶

5. IANA Considerations

This document requests that IANA assigns the following new parameters to the "BMP Route Monitoring TLVs" [I-D.ietf-grow-bmp-tlv] registry:¶

• Type = TBD1: Timestamp TLV type. This TLV carries a timestamp along with a code identifying which type of event it qualifies.¶
• Type = TBD2: Sequence Number TLV type. This TLV carries a sequence number for a BMP Message.¶
• Type = TBD3: Flags TLV type. This TLV carries a sequence of bytes representing the Per-Peer Header Flags for a BMP Message.¶

This document requests that IANA assigns the following new parameters to the "BMP Peer Flags for Peer Types 0 through 2" registry and to the "BMP Peer Flags for Loc-RIB Instance Peer Type 3" registry: * Flag = "7": X Flag (Extended Flags). Set if the Flags are carried in the Flags TLV instead of the Per-Peer Header.¶

This document also requests the definition of a "BMP Timestamp Types" registry which contains type codes for the different kinds of timestamps carried by the Timestamp TLV and exported by BMP version 4 or more.¶

The registration policy for this registry is Expert Review as defined in [RFC8126].¶

The registry is seeded as follows:¶

• Type = 0x00: Trigger Time. Set to 0x00 if the timestamp corresponds to the event that triggered BMP to report the route or state, such as receiving a message or a session transition.¶
• Type = 0x01: Message Export Time. Set to 0x01 if the timestamp corresponds to the time when the BMP message was generated for export.¶
• Type = 0x02: Adj-In Time. Set to 0x02 if the timestamp corresponds to when the route was installed in the Adj-RIB-In, as per <xref target="RFC7854"/>.¶
• Type = 0x03: Local-RIB Time. Set to 0x03 if the timestamp corresponds to when the route was installed in the Local-RIB, as per <xref target="RFC9069"/>.¶
• Type = 0x04: Adj-Out Time. Set to 0x04 if the timestamp corresponds to when the route was installed in the Adj-RIB-Out, as per <xref target="RFC8671"/>.¶

6. Security Considerations

This document does not introduce new security considerations.¶

7. Acknowledgements

Authors' Addresses