Logging of routing events in BGP Monitoring Protocol (BMP)

As NLRIs are advertised and distributed, policies are applied and, as a result, actions are performed on them. Currently, in order to infer the outcome of an evaluation process, a comparative analysis needs to be performed between Route Monitoring data for two distinct observation points of interest. It would be instead more useful if a monitored router could export event-driven data with the relevant information. The envisioned use-cases are the most diverse and range from logging route filtering to reporting the outcome of validation processes taking place on the monitored router, to isolating certain subsets of data to be validated offline, to broader closed-loop operations. Since no other existing BMP message type does fit the described purpose, this document defines a new Route Event Logging (REL) message type that is suitable to carry event-driven data and is extensible in nature. While the message format is similar to the Route Mirroring message type defined in RFC 7854 and to the Route Monitoring message type as defined in TLV support for BMP Route Monitoring and Peer Down Messages, the semantics are different.

In basic terms a REL message does carry Events. Each Event is logically composed by one Event Subject and one or more Event Attributes. The structure of the Route Event Logging message is the same as the Route Monitoring message defined in TLV support for BMP Route Monitoring and Peer Down Messages where the Per-Peer Header is followed by indexed TLVs. One or more Event Subjects are packed as part of a BGP Update PDU. The BGP Update PDU Section 4.3 of is encoded itself as part of a BGP Message TLV with code point &IANA_REL_CODE_BGP_PDU; and index set to zero. Each Event Subject is represented by an NLRI carried in the PDU. The BGP Message TLV may be preceeded and followed by indexed Informational TLVs that carry Event Attributes, where attributes are bound to subjects referring to their index in the PDU or via a Group TLV as described in TLV support for BMP Route Monitoring and Peer Down Messages. Speaking comparatively to other existing message types, REL does not require an initial flooding of information as per the state synchronization nature of Route Monitoring and does not aim to provide a non-state-compressed full-fidelity view of all messages received as per the debugging nature of Route Mirroring. In the context of BMP REL message, and hence in the reminder of this document, the term Event Subject and NLRI will be used interchangeably. Also the term Event Attribute and Informational TLV will be used interchangeably. The following sections will describe each component of the REL message in more detail.

The message does start with a BMP per-peer header as defined in RFC 7854, subsequently extended by RFC 8671 and RFC 9069 allowing, among the other things, to timestamp an Event and set its observation point among those defined in BMP. Because the main purpose of the REL message is to log events at the time of applying an action, the Peer Flags field - even if applied to Adj-Rib-In or Adj-Rib-Out does not have the concept of pre- and post-policy. The flags are hence defined as follows:

The V flag and A flag do carry the same meaning as originally defined by RFC 7854. The remaining bits are reserved for future use. They MUST be transmitted as 0 and their values MUST be ignored on receipt.

The PDU enclosed as part of a BGP Message TLV is artificial, either packed from scratch or repacked starting from an existing BGP Update PDU to only contain the relevant NLRIs affected by an Event (one or multiple). The Event is going to be further described by means of Event Attributes by indexed Informational TLVs. The choice of describing one or multiple Event Subjects via a BGP Update PDU is because, on one hand, this does allow to not have to invent new encodings for NLRIs, while on the other, to support all types and encodings already supported by BGP. The advantage being that only minimal new code, on both the exporting and the receiving sides, will have to be produced.

Informational TLVs in BMP are formalized by the intersection of RFC 7854, TLV support for BMP Route Monitoring and Peer Down Messages and Support for Enterprise- specific TLVs in the BGP Monitoring Protocol. TLVs in a REL message are indexed. Contrary to other BMP messages where all Informational TLVs are entirely optional, in order for a REL message to be meaningful, it MUST contain at least one Event Reason TLV per Event Subject (ie. NLRI) carried by the BGP Update PDU and MAY contain further optional attribute TLVs to further characterize the Event. A new registry called "Route Event Logging TLVs" is defined and is seeded with the following TLVs: &IANA_REL_CODE_EVENT_REASON; = Event Reason TLV (4 octets). Indicates the IANA-registered reason code describing the type of the event. The following reason codes are defined as part of the "Event Reason TLV" registry: