Support for Adj-RIB-Out in the BGP Monitoring Protocol (BMP)
updated by
- rfc-9736 — The BGP Monitoring Protocol (BMP) Peer Up Message Namespace
updates
- rfc-7854 — BGP Monitoring Protocol (BMP)
Extracted elements (20)
Pre-policy Adj-RIB-Out does not contain all local RIB routes; it contains only the candidate routes available based on the BGP peering type (IBGP, IBGP RR client, EBGP, confederation, route server client). This mirrors the candidate-set semantics of RFC 4271 rather than exposing the full local RIB.
The Admin Label TLV was introduced instead of a peer group name because BGP implementations use structured, hierarchical policy groupings (session, AFI/SAFI, template-based inheritance) that do not map to a single flat group name or ID. Free-form labels allow operators to attach administratively meaningful metadata (e.g., 'type=wholesale', 'region=west') without requiring protocol-level group semantics.
BMP receiver implementations SHOULD ignore the O flag in Peer Up and Down Notifications, as these convey session state independent of whether Adj-RIB-In or Adj-RIB-Out monitoring is used.
For pre-policy Adj-RIB-Out, all mandatory attributes (such as next hop) that are unknown at pre-policy phase completion MUST be either zero or have an empty length. The BMP receiver will treat such attributes as self-originated.
If any change results in alteration of behavior of an existing BMP session (e.g., changes to filtering or table names), the session MUST be bounced with a Peer Down/Peer Up sequence.
Post-policy Adj-RIB-Out MUST convey to the BMP receiver what is actually transmitted to the peer, reflecting all attribute modifications and filters applied by outbound policy.
Reserved bits in the per-peer header flags MUST be transmitted as 0, and their values MUST be ignored on receipt.
Statistics Report messages are not specific to Adj-RIB-In or Adj-RIB-Out and MUST have the O flag set to zero; BMP receivers SHOULD ignore the O flag in these messages.
The L flag MUST be set to 0 to indicate pre-policy Adj-RIB-Out.
The L flag MUST be set to 1 to indicate post-policy Adj-RIB-Out.
The O flag MUST be set accordingly in Route Monitoring and Route Mirroring messages to indicate whether the message conveys Adj-RIB-In or Adj-RIB-Out.
When multiple Admin Labels are included in a Peer Up Notification, the BMP receiver MUST preserve their order.
A new Peer Up Information TLV Type 4 (Admin Label) is defined: a free-form UTF-8 string of byte length given by the Information Length field, administratively assigned, with no required null termination. Multiple Admin Labels may be included in a single Peer Up Notification.
Four new Statistics Report types are defined: Stat Type 14 (pre-policy Adj-RIB-Out route count, 64-bit Gauge), Type 15 (post-policy Adj-RIB-Out route count, 64-bit Gauge), Type 16 (per-AFI/SAFI pre-policy, 2-byte AFI + 1-byte SAFI + 64-bit Gauge), and Type 17 (per-AFI/SAFI post-policy, same structure).
The O flag is added to bit 3 of the per-peer header flags byte. When set to 0, it indicates Adj-RIB-In; when set to 1, it indicates Adj-RIB-Out.
When O flag is 1, the Timestamp field in the per-peer header represents the time when the encapsulated routes were advertised (or installed in the Adj-RIB-Out), in seconds and microseconds since the Unix epoch. A value of zero means the time is unavailable.
When the O flag is set to 1 (Adj-RIB-Out), the Peer Address, Peer AS, and Peer BGP ID fields in the per-peer header are redefined to refer to the remote peer to which the encapsulated PDU is sent, rather than from which it was received.
Three IANA registries under 'BGP Monitoring Protocol (BMP) Parameters' are updated: (1) BMP Peer Flags — O flag assigned to bit 3; (2) BMP Statistics Types — types 14–17 for Adj-RIB-Out route counts; (3) BMP Initiation Message TLVs — Type 4 for Admin Label.
All security considerations from Section 11 of RFC 7854 apply. Implementations SHOULD require establishing BMP sessions with authorized and trusted monitoring devices. This document is believed to introduce no additional security considerations.
The per-peer header flags byte is extended to 'V|L|A|O|Resv' (8 bits). The O flag occupies bit 3; remaining reserved bits MUST be transmitted as 0 and MUST be ignored on receipt.