ietf-corpus from Lantern
rfc-9736

The BGP Monitoring Protocol (BMP) Peer Up Message Namespace

J. Scudder, P. Lucente
date2025-03 streamIETF areaops wggrow statusPROPOSED STANDARD pages6 canonicalhttps://www.rfc-editor.org/rfc/rfc9736 doi10.17487/RFC9736
RFC 7854, the BGP Monitoring Protocol (BMP), uses different message types for different purposes. Most of these are structured as Type, Length, Value (TLV). One message type, the Peer Up message, lacks a set of TLVs defined for its use, instead sharing a namespace with the Initiation message. Experience has shown that this namespace sharing was a mistake, as it hampers the extension of the protocol. This document updates RFC 7854 by creating an independent namespace for the Peer Up message. It also updates RFCs 8671 and 9069 by moving defined codepoints into the newly introduced registry. Compliant implementations of RFCs 7854, 8671, and 9069 also comply with this specification.

updates

Extracted elements (13)

design-rationale §1

The Peer Up message in RFC 7854 shares a TLV namespace with the Initiation message. Experience showed this was a mistake because it hampers extension of the protocol, motivating the creation of a separate namespace for Peer Up.

bgp, registry

interoperability-note §1

Compliant implementations of RFC 7854, RFC 8671, and RFC 9069 also comply with this specification. No changes to on-wire behavior are required for existing conformant implementations.

bgp

normative-requirement §3.3 MUST

For Peer Up Information TLV Type=3 (VRF/Table Name), the Information field value MUST be equal to the VRF or table name being conveyed, and the string size MUST be within the range of 1 to 255 bytes.

bgp

normative-requirement §3.1 MUST

For the Initiation Information TLV, Type=1 (sysDescr) MUST be set equal to the value of the sysDescr MIB-II object, and Type=2 (sysName) MUST be set equal to the sysName MIB-II object.

bgp

normative-requirement §3.3 MUST

If multiple String TLVs (Type=0) are included in a Peer Up Information TLV, their ordering MUST be preserved when they are reported.

bgp

normative-requirement §3.2 OPTIONAL

Inclusion of the Information field in the Peer Up Notification is OPTIONAL; its presence or absence can be inferred by inspection of the Message Length in the common header.

bgp

normative-requirement §3.1 MUST NOT

The Information TLV defined in Section 4.4 of RFC 7854 is renamed 'Initiation Information TLV' and is used only by the Initiation message, not by the Peer Up message.

bgp, registry

protocol-element §2

A string TLV is defined as a free-form sequence of UTF-8 characters whose length in bytes is given by the TLV's Length field. There is no requirement to terminate the string with a null or any other character.

bgp

protocol-element §3.3

The Peer Up Information TLV defines three initial types: Type=0 (String, free-form UTF-8, administratively assigned), Type=3 (VRF/Table Name, UTF-8, 1–255 bytes), and Type=4 (Admin Label, free-form UTF-8).

bgp, registry

registry §4

IANA created the 'BMP Peer Up Message TLVs' registry within the 'BGP Monitoring Protocol (BMP) Parameters' group. Ranges 0 and 3–32767 require Standards Action; 32768–65530 are First Come First Served; 65531–65534 are Experimental; 1–2 and 65535 are Reserved.

bgp, registry

registry §4

IANA renamed the 'BMP Initiation and Peer Up Information TLVs' registry to 'BMP Initiation Information TLVs', reserving types 3 and 4 (previously used by Peer Up) and retaining types 0 (String), 1 (sysDescr), and 2 (sysName).

bgp, registry

security-consideration §5

This document does not alter the security considerations of RFC 7854, which continue to apply. No new security risks are introduced by the namespace separation.

bgp, security

wire-format §3.3

The Peer Up Information TLV has a 2-byte Information Type field, a 2-byte Information Length field (length in bytes of the Information field), and a variable-length Information field.

bgp