]> 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 :
The BMP message common header
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 contents
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 Event sent when a particular RIB-view is no longer monitored on the Router (Eg: Globally at router level or for a given AFI/SAFI or for a set of BGP peers).
  • Type=1 : Route Import Complete Event sent when import of Routes is completed (Eg: Globally at router level or for a given Table).
  • Type=2 : Peer Configured is Down Event sent when configured monitored BGP peer on the router has never come up.
Event Sub-TLVs The Event Sub-TLVs are encoded as a list of optional Sub-TLVs. They add context to the associated event, either by providing the reason or act as a set of filters. All Event Sub-TLVs use a 2-octet Type field and a 2-octet Length field. The Event Sub-TLV is defined as follows:
BMP GEN message optional Event Sub-TLVs
The following are BMP GEN message Event Sub-TLV Types that are defined in this document: Event Sub-TLVs Types defined in this document
Type Length (octets) Description Value Format
0 Variable Reason String UTF-8 string
1 1 Reason Code see
2 2 RIB View (Filter) see
3 8 Route Distinguisher (Filter) see
4 4 or 16 Peer Address (Filter) 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 .
The RIB View Event Sub-TLV encoding
Type=2:
Identifies the RIB View Event Sub-TLV Type.
Length=2:
2-bytes.
RIB View:
The RIB View value. This value encoded as shown in .
RIB View value encoding
  • When I flag is set, it indicates that the Event reflects the Pre-Policy Adj-RIB-In view
  • When J flag is set, it indicates that the Event reflects the Post-Policy Adj-RIB-In view
  • When O flag is set, it indicates that the Event reflects the Pre-Policy Adj-RIB-Out view
  • When P flag is set, it indicates that the Event reflects the Post-Policy Adj-RIB-Out view
  • When L flag is set, it indicates that the Event reflects the Local-RIB view
The remaining bits are reserved for future use. They MUST be transmitted as 0 and their values MUST be ignored on receipt. NOTE: Above is an extension to RIB-view value encoding defined in
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 .
The Reason String Event Sub-TLV encoding
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.
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 :
The Reason Code Event Sub-TLV encoding
Type=1:
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.
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 :
The Route Distinguisher Event Sub-TLV encoding
Type=3:
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 :
The Peer Address Event Sub-TLV encoding
Type=4:
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.
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 SHOULD 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.
References Normative References 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] Informative References 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. Common BMP Route-Monitoring Messages for Routes Unchanged by Policy Cisco Systems, Inc. Cisco Systems, Inc. A route unmodified by the inbound policy on a monitored router is included both in Pre-Policy Adj-RIB-In as well as Post-Policy Adj- RIB-In Route-Monitoring messages when both the Pre-Policy and Post- Policy Route-Monitoring modes are enabled. Similarly, a route unmodified by the outbound policy is included in Pre-Policy Adj-RIB- Out as well as Post-Policy Adj-RIB-Out Route-Monitoring messages. This document defines a method to avoid duplicate inclusion of routes unmodified by policy either in Adj-RIB-In or Adj-RIB-Out.