| Internet-Draft | GEN Message for BMP | October 2025 |
| Saad & Narasimha | Expires 22 April 2026 | [Page] |
This document defines a new BMP message type: the Generic Event Notification (GEN). The BMP GEN message provides a flexible mechanism for reporting a wide variety of events related to BGP at different levels of hierarchy, such as routing instance, AFI/SAFI, or peer level. The BMP GEN message enables operators and automated systems to receive detailed context for operational events, such as policy triggers, administrative interventions, and state management notifications (e.g., RIB view unmonitor events).¶
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 22 April 2026.¶
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.¶
The BGP Monitoring Protocol (BMP) [RFC7854] provides network operators with visibility into BGP message exchanges. Recent extensions, such as [I-D.ietf-grow-bmp-rel], increase the range of observable BGP-related events. However, there is a need for a more generic, extensible message type capable of reporting diverse operational events, including policy triggers, automated network adjustments, administrative interventions, and notifications for collector state management, such as route table purges.¶
This document introduces the BMP Generic Event Notification (GEN) message, designed to flexibly report on such events with enough context to allow the collector to take the appropriate action.¶
The BMP GEN message can be used to deliver a variety of notifications, including a RIB View notification, which allows a BMP sender to request that the BMP collector purge the state associated with specific peers and RIB views.¶
The current BMP message types focus primarily on peer session events and per-route updates. Network operators and automated systems often require notification of a broader class of events, such as:¶
RIB state management, such as notifying the collector when a RIB view is no longer being monitored.¶
Administrative resets, disables, or maintenance windows¶
Notifications about the status of various internal FSM router states (e.g., Import Completed, Export Completed, etc.)¶
Detection of anomalous behavior or threshold crossings¶
The BMP GEN message provides structured reporting of such events, including a clear indication of the event type and related context.¶
The BMP GEN message is a new BMP message type.¶
The BMP GEN message uses the BMP message common header as defined in [RFC7854]:¶
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 +-+-+-+-+-+-+-+-+ | Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Msg. Type | +---------------+
where a new Message Type = TBD1 is assigned to the BMP GEN message type.¶
The BMP GEN message body is formatted as follows:¶
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 +---------------------------------------------------------------+ | Event Type (2 octets) | Flags (2 octets) | +---------------------------------------------------------------+ | Timestamp (seconds) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp (microseconds) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Event Sub-TLVs (variable) | +---------------------------------------------------------------+
The BMP GEN message is extensible for future event types. It is meant to supplement, but not replace, existing BMP message types.¶
Identifies the event class (see Section 4.3.1 for example Event Types).¶
Reserved for future use.¶
The time when the event occurred, expressed as seconds and microseconds since midnight (00:00), January 1, 1970 (UTC). If both are zero, the time is unavailable. Precision of the timestamp is implementation-dependent.¶
Optional Sub-TLVs for additional context for the event that occurred (see Section 4.3.2 for example Sub-TLVs).¶
The following fields are defined for BMP GEN messages.¶
The following Event Types are defined:¶
The Event Sub-TLVs are encoded as a list of optional Sub-TLVs that add context to the associated event.¶
All Event Sub-TLVs use a 2-octet Type field and a 2-octet Length field. The Event Sub-TLV is defined as follows:¶
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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \\ Value \\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following are BMP GEN message Event Sub-TLV Types that are defined in this document:¶
| Type | Length | Description | Value Format |
|---|---|---|---|
| 0 | Variable | Reason String | UTF-8 string |
| 1 | 1 octet | RIB View | see Section 4.3.3 |
| 2 | 8 octets | Route Distinguisher | see Section 4.3.5 |
| 3 | 4 or 16 octets | Peer Address | see Section 4.3.6 |
| 4 | 1 octet | Reason Code | see Section 4.3.7 |
The RIB View Event Sub-TLV identifies one or more RIB views that are relevant to the event. The encoding of the RIB View Event Sub-TLV is shown in Figure 4.¶
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=1 | Length=1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RIB View | +-+-+-+-+-+-+-+-+
Identifies the RIB View Event Sub-TLV Type.¶
1-byte.¶
The RIB View value. This value is divided into 2 parts as shown in Figure 5.¶
+-+-+-+-+-+-+-+-+
|Type | View |
+-+-+-+-+-+-+-+-+
The RIB views are encoded as a bitmap in 1-octet to allow designating multiple views at the same time. The 3 most significant bits designate the Type (Pre and/or Post). The remaining 5 bits designate the specific RIB view (Adj-RIB-In, Adj-RIB-Out, and/or Local-RIB) as shown in Table 2.¶
The following values are defined in this document:¶
The Reason String Event Sub-TLV provides a UTF-8 encoded string describing the event in human-readable form. This Sub-TLV is intended to assist operators or automated systems in interpreting the context or rationale for the event, such as "Adj-RIB-Out export stopped by operator" or "Peer remains in down state".¶
The encoding of the Reason String Event Sub-TLV is shown in Figure 6.¶
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=0 | Length (Variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \\ Reason String \\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Route Distinguisher Event Sub-TLV allows identification of a particular VPN routing context. When present in the BMP GEN list of Event Sub-TLVs, the IP address that directly follows the Route Distinguisher Event Sub-TLV MUST be interpreted within the context of the routing instance associated with the Route Distinguisher.¶
The encoding of the Route Distinguisher Event Sub-TLV is shown in Figure 7:¶
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 | Length=8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Route Distinguisher | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Peer Address Event Sub-TLV identifies a BGP peer that is relevant to the event. If more than one peer is relevant to the event, multiple Peer Address Sub-TLVs MAY be included.¶
The encoding of the Peer Address Event Sub-TLV is shown in Figure 8:¶
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=3 | Length=(4 or 16) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peer Address (4 or 16 bytes) | ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Reason Code Event Sub-TLV provides a 1-octet code indicating the reason for the event. The encoding of the Reason Code Event Sub-TLV is shown in Figure 9:¶
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=4 | Length=1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reason Code | +-+-+-+-+-+-+-+-+
Identifies the Reason Code Event Sub-TLV Type.¶
1-byte.¶
The Reason Code Value. The following Reason Code values are defined in this document:¶
Additional values may be defined in future documents.¶
Description:¶
A BMP sender can stop exporting a RIB view to a BMP collector at any time after its initial export. Without a notification from the BMP sender, the collector may maintain stale state.¶
A RIB View Unmonitor event notifies the BMP collector that the specific RIB view is no longer being monitored on the BMP sender and updates for that RIB view will no longer be sent. The BMP collector, in this case, SHOULD purge any data associated with that RIB view that was previously received.¶
Scenario:¶
Adj-RIB-Out Export Stopped Due to Configuration Change¶
Background:¶
A network operator decides to stop exporting the Adj-RIB-Out view for a particular peer (e.g., to reduce monitoring overhead or due to a policy change).¶
Event:¶
The halt of Adj-RIB-Out export for all peers to the BMP collector.¶
Example BMP GEN Message:¶
The router sends a BMP GEN message to the BMP collector to notify that the Adj-RIB-Out view export is stopped for all peers and that any associated state should be purged.¶
{
"eventType": 0, // RIB View Unmonitor
"eventTimestampSeconds": 1712959200, // Seconds
"eventTimestampMicroseconds": 123, // Microseconds
"eventSubTLVs": [
{ "type": 0, "value": "Operator triggered for maintenance" },
// Reason String
{ "type": 1, "value": [0, 0, 1, 0, 0, 0, 1, 0] }
// RIB View (bitmap for Adj-RIB-Out Pre)
]
}
¶
Description:¶
Router has completed the route import activity. The trigger could be the configuration of VPN AFI/SAFI or the relevant neighbors coming up, among other events.¶
This event can be for:¶
- all routing instances (VRFs), - a given routing instance, or - a given AFI/SAFI.¶
Scenario:¶
A router has completed route import from VPN AFI/SAFI to all local routing instances (VRFs).¶
Event:¶
The completion of a full walk of VPN AFI/SAFI and route import activity.¶
Example BMP GEN Message:¶
The router sends a BMP GEN message to the BMP collector to notify that import activity has completed.¶
{
"eventType": 1, // Route Import Complete
"eventTimestampSeconds": 1712959200, // Seconds
"eventTimestampMicroseconds": 123 // Microseconds
}
¶
Description:¶
The router has peers configured that are not administratively shut down but are not operationally up. The duration for which they are down SHOULD be a configurable value on the router.¶
This event can be for:¶
- a given peer, or - a set of peers.¶
Scenario:¶
The operator configures a BGP peer (198.51.100.2) under the routing instance identified by Type=1 RD (198.51.100.1:10). The BGP peer remains in DOWN state after the configured 10-minute interval.¶
Event:¶
The BGP peer (RD=198.51.100.1:10, 198.51.100.2) does not come up after 10 minutes elapse from when it is configured.¶
Example BMP GEN Message:¶
The router sends a BMP GEN message to the BMP collector to notify that the BGP peer (RD=198.51.100.1:10, 198.51.100.2) is in DOWN state.¶
Note: The Route Distinguisher is encoded as an 8-octet value per [RFC4364]. The value shown is a hexadecimal representation for illustration.¶
{
"eventType": 2, // Peer in Down
"eventTimestampSeconds": 1712959200, // Seconds
"eventTimestampMicroseconds": 123, // Microseconds
"eventSubTLVs": [
{ "type": 0, "value": "Peer remains in down state" },
// Reason String
{ "type": 2, "value": [0, 1, 198, 51, 100, 1, 0, 10] },
// Route Distinguisher (8-octet value per RFC4364,
// example: 198.51.100.1:10)
{ "type": 3, "value": "198.51.100.2" } // Peer Address
]
}
¶
The BMP GEN messages may carry sensitive operational context. Implementations MUST ensure integrity and authenticity, for example by using transport security as recommended in [RFC7854]. Purge notifications can affect collector state and SHOULD only be accepted from authorized BMP senders.¶
IANA is requested to assign the following from the "BGP Monitoring Protocol (BMP) Parameters" registry (https://www.iana.org/assignments/bmp-parameters/).¶
A new BMP Message Type value (TBD1) is to be assigned for the BMP GEN message.¶
IANA is requested to create a new registry for BMP GEN Event Types. The following Event Types that are defined in this document (see Section 4.3.1):¶
IANA is requested to create a new registry for BMP GEN Event Sub-TLV Types. The Event Sub-TLV Types described in Table 1 are defined in this document.¶
The authors would like to thank Dhananjay Patki for his detailed review and feedback. Additional thanks are extended to Jeff Haas, Luuk Hendriks, and Ben Maddison for their valuable comments and suggestions. Their insights greatly improved the quality and clarity of this document.¶