]> Generic Event Notification (GEN) for BGP Monitoring Protocol (BMP) Cisco Systems, Inc.
CA tsaad@cisco.com
Cisco Systems, Inc.
IND snprasad@cisco.com
GROW Internet-Draft BMP BGP Event Notification 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).
Introduction The BGP Monitoring Protocol (BMP) provides network operators with visibility into BGP message exchanges. Recent extensions, such as , 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.
Terminology GEN: Generic Event Notification BMP: BGP Monitoring Protocol BGP: Border Gateway Protocol TLV: Type-Length-Value RIB: Routing Information Base
Motivation 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 Format The BMP GEN message is a new BMP message type.
The BMP Message Common Header The BMP GEN message uses the BMP message common header as defined in :
where a new Message Type = TBD1 is assigned to the BMP GEN message type.
The BMP GEN Message Body The BMP GEN message body is formatted as follows:
The BMP GEN message is extensible for future event types. It is meant to supplement, but not replace, existing BMP message types.
Event Type:
Identifies the event class (see for example Event Types).
Flags:
Reserved for future use.
Timestamp:
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.
Event Sub-TLVs:
Optional Sub-TLVs for additional context for the event that occurred (see for example Sub-TLVs).
The BMP GEN Message Fields The following fields are defined for BMP GEN messages.
Example Event Types The following Event Types are defined: Type=0 : RIB View Unmonitor Type=1 : Route Import Complete Type=2 : Peer Configured is Down
Event Sub-TLVs 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:
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 2 8 octets Route Distinguisher see 3 4 or 16 octets Peer Address see 4 1 octet Reason Code see
RIB View Event Sub-TLV 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 .
Type=1:
Identifies the RIB View Event Sub-TLV Type.
Length=1:
1-byte.
RIB View:
The RIB View value. This value is divided into 2 parts as shown in .
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 . The following values are defined in this document: Type View Description 001 (Pre) 00001 (Adj-RIB-In) Adj-RIB-In Pre 010 (Post) 00001 (Adj-RIB-In) Adj-RIB-In Post 001 (Pre) 00010 (Adj-RIB-Out) Adj-RIB-Out Pre 010 (Post) 00010 (Adj-RIB-Out) Adj-RIB-Out Post 000 00100 Local-RIB
Reason String Event Sub-TLV 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 .
Type=0:
Identifies the Reason String Event Sub-TLV Type.
Length (Variable):
The length of the string in bytes.
Reason String:
The UTF-8 string not null-terminated.
Route Distinguisher Sub-TLV 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 :
Type=2:
Identifies the Route Distinguisher Event Sub-TLV Type.
Length=8:
The length in bytes of the Route Distinguisher field (always 8 bytes).
Route Distinguisher:
The Route Distinguisher value as per .
Peer Address Event Sub-TLV 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 :
Type=3:
Identifies the Peer Address Event Sub-TLV Type.
Length=(4 or 16):
The length in bytes of the Peer Address. This is 4 bytes for IPv4 address and 16-bytes for IPv6 address.
Peer Address:
The BGP Peer IPv4 or IPv6 address.
Reason Code Event Sub-TLV 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 :
Type=4:
Identifies the Reason Code Event Sub-TLV Type.
Length=1:
1-byte.
Reason Code:
The Reason Code Value. The following Reason Code values are defined in this document:
  • Value=0: Administrative (e.g., operator action or configuration change) Value=1: Periodic (e.g., scheduled or timer-based) Value=2: Error (e.g., protocol error, failure detected)
Additional values may be defined in future documents.
Use Cases
Example Scenario: RIB View Unmonitor 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.
Example Scenario: Route Import Complete 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:
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.
Example Scenario: Peer Configured is Down 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:
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 . The value shown is a hexadecimal representation for illustration.
Security Considerations The BMP GEN messages may carry sensitive operational context. Implementations MUST ensure integrity and authenticity, for example by using transport security as recommended in . Purge notifications can affect collector state and SHOULD only be accepted from authorized BMP senders.
IANA Considerations IANA is requested to assign the following from the "BGP Monitoring Protocol (BMP) Parameters" registry (https://www.iana.org/assignments/bmp-parameters/).
BMP Message Type A new BMP Message Type value (TBD1) is to be assigned for the BMP GEN message.
BMP GEN Event Types IANA is requested to create a new registry for BMP GEN Event Types. The following Event Types that are defined in this document (see ):
  • Type=0 :
    RIB View Unmonitor
    Type=1 :
    Route Import Complete
    Type=2 :
    Peer Configured is Down
BMP GEN Event Sub-TLV Types IANA is requested to create a new registry for BMP GEN Event Sub-TLV Types. The Event Sub-TLV Types described in are defined in this document.
Acknowledgements 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.
BGP Monitoring Protocol (BMP) This document defines the BGP Monitoring Protocol (BMP), which can be used to monitor BGP sessions. BMP is intended to provide a convenient interface for obtaining route views. Prior to the introduction of BMP, screen scraping was the most commonly used approach to obtaining such views. The design goals are to keep BMP simple, useful, easily implemented, and minimally service affecting. BMP is not suitable for use as a routing protocol. BGP/MPLS IP Virtual Private Networks (VPNs) This document describes a method by which a Service Provider may use an IP backbone to provide IP Virtual Private Networks (VPNs) for its customers. This method uses a "peer model", in which the customers' edge routers (CE routers) send their routes to the Service Provider's edge routers (PE routers); there is no "overlay" visible to the customer's routing algorithm, and CE routers at different sites do not peer with each other. Data packets are tunneled through the backbone, so that the core routers do not need to know the VPN routes. [STANDARDS-TRACK] Logging of routing events in BGP Monitoring Protocol (BMP) NTT NTT The BGP Monitoring Protocol (BMP) does provision for BGP session event logging (Peer Up, Peer Down), state synchronization (Route Monitoring), debugging (Route Mirroring) and Statistics messages, among the others. This document defines a new Route Event Logging (REL) message type for BMP with the aim of covering use-cases with affinity to alerting, reporting and on-change analysis.