TLV support for BMP Route Monitoring and Peer Down Messages

The BGP Monitoring Protocol (BMP) is defined in RFC 7854. The Route Monitoring message consists of: Common Header Per-Peer Header BGP Update PDU The Peer Down Notification message consists of: Common Header Per-Peer Header Reason Data (only if Reason code is 1, 2 or 3) This means that both Route Monitoring and Peer Down messages have a non-extensible format. In the Route Monitoring case this is limiting if wanting to transmit characteristics of transported NLRIs (ie. to help stateless parsing) or vendor-specific data; in the Peer Down case this is limiting if wanting to match TLVs shipped with the Peer Up. The proposal of this document is to bump the BMP version, for backward compatibility, and allow all message types to provision for trailing TLV data.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC 2119 RFC 8174 when, and only when, they appear in all capitals, as shown here.

TLV data type is already defined in Section 4.4 for the Initiation and Peer Up message types. A TLV consists of: 2 octets of TLV Type, 2 octets of TLV Length, 0 or more octets of TLV Value.

TLVs can be sent in any order. Multiple TLVs of the same type can be repeated as part of the same message and it is left to the specific use-cases whether all, any, the first or the last TLV should be considered.

Section 4.1 defines the Common Header. While the structure remains unaltered, the following two definitions are changed: Version: Indicates the BMP version. This is set to '4' for all messages. Message Length: Length of the message in bytes (including headers, data, encapsulated messages and TLV data if any)

The Route Monitoring message type is defined in Section 4.6. The BGP Update PDU Section 4.3 MAY be followed by TLV data. This document defines the following new codes to help stateless parsing of BGP Update PDUs: Type = &IANA_RM_CODE_4B_ASN;: the BGP Update PDU is encoded with support for 4-octet AS number capability RFC 6793, value MUST be boolean. Type = &IANA_RM_CODE_PATH_ID;: the BGP Update PDU is encoded with ADD-PATH capability RFC 7911, value MUST be boolean. Type = &IANA_RM_CODE_MULTI_LABELS;: the BGP Update PDU is encoded with Multiple Labels capability RFC 8277, value MUST be boolean.

The Peer Down Notification message type is defined in Section 4.9. TLV data MAY now follow any Reason code.

All other message types defined in RFC7854 do already provision for TLV data. It is RECOMMENDED that all future BMP message types will provision for trailing TLV data.

It is not believed that this document adds any additional security considerations.

This document defines the following new TLV types for BMP Route Monitoring and Peer Down messages (): Type = &IANA_RM_CODE_4B_ASN;: Support for 4-octet AS number capability. The value field contains a boolean value. 1 if the BGP Update PDU enclosed in the Route Monitoring message was encoded according to the capability. Type = &IANA_RM_CODE_PATH_ID;: ADD-PATH capability. The value field contains a boolean value. 1 if the BGP Update PDU enclosed in the Route Monitoring message was encoded according to the capability. Type = &IANA_RM_CODE_MULTI_LABELS;: Multiple Labels capability. The value field contains a boolean value. 1 if the BGP Update PDU enclosed in the Route Monitoring message was encoded according to the capability.