Support for Local RIB 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 (25)
Direct BMP Loc-RIB access is preferred over the alternative of deriving Loc-RIB by monitoring Adj-RIB-In pre-policy from a separate BGP peering router, because the alternative requires additional routers and peering sessions, is error-prone due to outbound policy transforms, and cannot provide system-level information (e.g., router name, VRF identity) needed to correctly correlate the data.
Although RFC 7854 defines 'locally originated routes' in Section 8.2, this document replaces that section: locally sourced routes now MUST use the Loc-RIB Instance Peer Type rather than the previously defined mechanism, which did not capture all selected routes from BGP peers.
When ADD-PATH (RFC 7911) is enabled for an address family and the Loc-RIB contains additional paths, the ADD-PATH capability SHOULD be reflected in the fabricated Peer Up OPEN message so that BMP receivers correctly parse the additional-path-encoded Route Monitoring messages.
If any change alters the 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.
If locally sourced routes are communicated using BMP, they MUST be conveyed using the Loc-RIB Instance Peer Type (Peer Type 3).
If the VRF/Table Name TLV is included in a Peer Up notification, it MUST also be included in the corresponding Peer Down notification.
Loc-RIB Route Monitoring messages MUST use 4-byte ASN encoding as indicated in the Peer Up sent OPEN message capability.
Route Mirroring is not applicable to Loc-RIB because PDUs are originated by the router rather than received from a peer. Any received Route Mirroring messages SHOULD be ignored.
State compression and throttling SHOULD be used by a BMP sender to reduce the number of Route Monitoring messages transmitted; only the final resultant update for a given prefix within a compression interval need be sent, suppressing intermediate changes.
The Peer Down notification for a Loc-RIB peer MUST use reason code 6 ('Local system closed, TLV data follows'). The VRF/Table Name TLV MUST be included in the Peer Down if it was present in the Peer Up.
The Peer Up notification Sent OPEN Message is a fabricated BGP OPEN message. Capabilities MUST include the 4-octet ASN and all necessary capabilities to represent the Loc-RIB Route Monitoring messages, and only capabilities that will actually be used MUST be included.
The Peer Up Received OPEN Message MUST be a repeat of the sent OPEN message, allowing the BMP receiver to parse it as defined in RFC 7854 Section 4.10.
There MUST be at least one emulated peer for each Loc-RIB instance (e.g., each VRF). When multiple emulated peers represent the same Loc-RIB instance (e.g., for different address families), each MUST send a Peer Up with an OPEN message indicating its address family capabilities, and a BMP receiver MUST process these capabilities.
When multiple filters are associated with the same Loc-RIB and the F flag is set, a table name MUST be used to allow the BMP receiver to correctly associate filtered views with the right Loc-RIB instance.
When multiple VRF/Table Name TLVs of the same type are included in the same message, their ordering MUST be preserved when reported. A BMP receiver should append multiple TLVs of the same type to a set to support alternate or additional names.
A new BMP peer type is defined: Peer Type 3 (Loc-RIB Instance Peer), indicating the peer represents the router Loc-RIB, which may have a route distinguisher (RD). This supplements the existing Local Instance Peer type (for non-RD peers with instance identifiers) defined in RFC 7854.
A new Peer Up Information TLV Type 3 (VRF/Table Name) is defined. The Information field contains a UTF-8 string equal to the VRF or table name (1 to 255 bytes). If a name is configured, it MUST be included; the default value 'global' MUST be used for the default Loc-RIB instance with a zero-filled distinguisher.
For Loc-RIB Statistics Reports, only Stat Type 8 (64-bit Gauge: number of routes in Loc-RIB) and Stat Type 10 (number of routes in per-AFI/SAFI Loc-RIB, encoded as 2-byte AFI + 1-byte SAFI + 64-bit Gauge) are relevant.
IANA created a new registry 'BMP Peer Flags for Loc-RIB Instance Peer Type 3' and registered Flag 0 as the F flag (indicates Loc-RIB is filtered). Flags 1–7 are unassigned; the registration procedure is Standards Action. The existing F flag entry in 'BMP Peer Flags for Peer Types 0 through 2' was deprecated.
IANA registered Peer Down reason code 6 ('Local system closed, TLV data follows') in the BMP Peer Down Reason Code registry, used when a Loc-RIB peer is taken down with accompanying TLV data.
IANA registered Peer Type 3 (Loc-RIB Instance Peer) in the 'BGP Monitoring Protocol (BMP) Parameters' registry under 'BMP Peer Type'.
IANA renamed 'BMP Initiation Message TLVs' to 'BMP Initiation and Peer Up Information TLVs' and registered Type 3 (VRF/Table Name) as a new BMP Peer Up Information TLV type, carrying a UTF-8 string of 1 to 255 bytes.
The security considerations of RFC 7854 Section 11 apply. Implementations SHOULD require that BMP sessions only be established with authorized and trusted monitoring devices. This document is not believed to introduce additional security considerations beyond RFC 7854.
For the Loc-RIB Instance Peer per-peer header: Peer Type is 3; Peer Distinguisher is zero-filled for the global instance or set to the RD/unique local value; Peer Address is zero-filled (V flag not applicable); Peer AS is set to the primary router BGP ASN; Peer BGP ID is set to the VRF router-id or global instance router-id.
The per-peer header flags for Loc-RIB Instance Peer Type use an 8-bit field where bit 0 is the F flag. The F flag MUST be set when a filter is applied to Loc-RIB routes sent to the BMP collector. Unused bits MUST be transmitted as 0 and ignored on receipt.