BMP Extension for Monitoring Multiple BGP Instances

Introduction The BGP Monitoring Protocol (BMP) defines a mechanism by which a monitored router sends BGP-related state to a BMP Monitoring Station. Each monitored BGP peer is identified on the wire by a Per-Peer Header that carries fields such as Peer Type, Peer Flags, Peer Distinguisher, Peer Address, Peer AS, Peer BGP ID, and a timestamp. On modern routing platforms it is increasingly common to run multiple, independent BGP instances on the same physical device. A typical deployment comprises:

One BGP base instance (the default instance traditionally implied by ).
One or more additional BGP instances, each identified by a locally significant Instance Name.

Instances on the same device are strictly isolated: they MAY use identical or different AS numbers, MAY have independent Router-IDs, and are typically implemented in distinct operating-system processes. Each instance independently maintains its own set of BGP peers, address families, and routing tables. BGP instances and VRFs are orthogonal concepts: a given BGP instance may itself host multiple VRFs. When such a device is monitored through a single BMP session (or even through multiple BMP sessions multiplexed to the same Monitoring Station), the BMP messages produced by the different BGP instances become indistinguishable. Two peers located in different BGP instances may share the same Peer Address, Peer AS, and Peer BGP ID, and a given prefix may legitimately appear in more than one instance with a different best path. As a result, the Monitoring Station cannot correctly attribute state to the originating BGP instance. This document addresses this gap by defining a new TLV element - the BGP Instance Name TLV - that carries the Instance Name of the BGP instance associated with the BMP message. The TLV is defined within the TLV extension framework of , which extends RFC 7854 to support TLV-encoded optional data across all BMP message types.

Requirements Language 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 when, and only when, they appear in all capitals, as shown here.

Terminology This document uses the following terms:

BGP Instance:: An independent instantiation of the BGP protocol on a monitored router, characterized by its own BGP state machine, peer table, and RIBs. Multiple BGP instances MAY coexist on the same device and are typically implemented in separate processes.
BGP Base Instance:: The default BGP instance on a monitored router; i.e., the instance historically assumed by implementations of .
Instance Name:: A locally significant, administratively assigned string that uniquely identifies a BGP instance on a monitored router. The Instance Name is encoded as a UTF-8 string .
Monitored Router:: A BMP-speaking device that runs one or more BGP instances and sends BMP messages to a Monitoring Station, as defined in .
Monitoring Station:: A BMP-receiving entity, as defined in .
TLV:: Type-Length-Value element, as defined in .

Problem Statement A monitored router running multiple BGP instances produces BMP messages whose Per-Peer Headers are, taken in isolation, insufficient to identify the originating BGP instance. Specifically:

Two BGP instances on the same router MAY use the same AS number. The Peer AS field of the Per-Peer Header therefore cannot disambiguate instances.
Two BGP instances MAY establish peerings with peers that share the same Peer Address (for example, when the instances have overlapping address spaces, or simply by administrative coincidence). The Peer Address field therefore cannot disambiguate instances.
The Peer Distinguisher field defined in is used to express a Route Distinguisher or is zero for the global instance, and is orthogonal to the concept of a BGP instance as defined in this document.
The Peer Type field enumerates BGP peer kinds (Global, RD, Local, Loc-RIB, and extensions such as those in ) but does not convey which BGP instance a peer belongs to.

Consequently, when a Monitoring Station receives a Route Monitoring or Peer Up message from such a router, it cannot reliably attribute the reported information to a specific BGP instance. This is problematic for operations such as per-instance route-table reconstruction, per-instance policy auditing, and per-instance fault isolation. This document resolves the ambiguity by tagging BMP messages with the Instance Name of the originating BGP instance.

BGP Instance Name TLV This document defines a new TLV, the BGP Instance Name TLV, using the TLV encoding and semantics of . The TLV carries the Instance Name of the BGP instance with which the enclosing BMP message is associated.

TLV Format The BGP Instance Name TLV is encoded as follows:

BGP Instance Name TLV

E (1 bit):: Enterprise Bit, as defined in . MUST be set to 0 when this IANA-registered Type value is used.
Type (15 bits):: Set to TBD (to be assigned by IANA, see ). This value identifies the TLV as a BGP Instance Name TLV.
Length (2 octets):: Length, in octets, of the BGP Instance Name field. The Length MUST be non-zero; a Length of 0 is invalid and the TLV MUST be ignored by the receiver.
BGP Instance Name (variable):: The Instance Name of the BGP instance associated with the enclosing BMP message, encoded as a UTF-8 string . There is no requirement to terminate the string with a null or any other character. The Instance Name is locally significant on the monitored router; no semantics beyond uniqueness on that router are implied by this document.

Scope and Cardinality The BGP Instance Name TLV describes a property of the BGP peer (and therefore of the BGP instance) that originates the enclosing BMP message. The TLV is therefore defined to apply at the scope of the whole BMP message rather than at the scope of an individual NLRI within a Route Monitoring message. In the terminology of , it is a global TLV ("G-Type"). A BMP message SHOULD contain at most one BGP Instance Name TLV. If a receiver encounters more than one BGP Instance Name TLV in the same BMP message, it MUST use the first occurrence and MUST ignore subsequent occurrences. When this document is implemented, the monitored router SHOULD include the BGP Instance Name TLV in every BMP message emitted on behalf of a non-default BGP instance. The monitored router MAY include the TLV for messages originated by the BGP base instance; when the TLV is omitted, the Monitoring Station SHOULD treat the message as originating from the BGP base instance.

Applicability to BMP Message Types The BGP Instance Name TLV MAY be carried in the following BMP message types:

Peer Up Notification (Section 4.10 of , using the BMP Peer Up TLVs registry as updated by ).
Peer Down Notification (Section 4.9 of , using the TLV mechanism defined in ).
Route Monitoring (Section 4.6 of , using the TLV mechanism defined in ).
Statistics Report (Section 4.8 of , using the TLV mechanism defined in ).
Route Mirroring (Section 4.7 of ).

This document does not define the carriage of the BGP Instance Name TLV in Initiation or Termination messages. Initiation and Termination describe properties of the BMP session itself rather than of an individual BGP instance. Future documents MAY define such usage if required by new use cases. For Route Monitoring, Statistics Report, Peer Down, and Route Mirroring messages, the BGP Instance Name TLV is encoded in the optional TLV area defined by . For Peer Up messages, the TLV is carried in the Peer Up Information TLVs area, using the registry defined by . The BGP Instance Name conveyed in Peer Up for a given peer MUST remain constant for the lifetime of the BMP-monitored peering session. A Peer Down Notification for that peer SHOULD carry the same BGP Instance Name TLV, to allow the Monitoring Station to correlate the teardown with the corresponding Peer Up even in the presence of message reordering or partial state loss.

Operational Considerations Because a BGP instance is a property of the peer rather than of each individual route, the Instance Name is, strictly speaking, redundant once the Monitoring Station has received the Peer Up message for a peer. Nevertheless, including the BGP Instance Name TLV in Route Monitoring, Statistics Report, and Route Mirroring messages provides the following operational benefits:

Self-contained messages: each BMP message can be independently interpreted without relying on prior state, which simplifies Monitoring Station implementations that do not maintain a complete peer cache.
Robustness to state loss: a Monitoring Station that restarts, or that connects to the monitored router mid-session, can still correctly attribute messages to their BGP instance.
Correlation across sessions: when a single Monitoring Station aggregates data from multiple BMP sessions or multiple routers, per-message instance tagging simplifies downstream processing.

Implementations SHOULD make the inclusion of the BGP Instance Name TLV in high-volume message types (notably Route Monitoring) configurable, so that operators may trade off per-message self-containment against the additional bandwidth and processing overhead imposed by repeated Instance Names. The length of the Instance Name is bounded only by the BMP message framing. Operators SHOULD choose short, stable Instance Names to limit per-message overhead.

Backward Compatibility A Monitoring Station that does not implement this extension will treat the BGP Instance Name TLV as an unknown TLV. Per , unknown TLVs are silently ignored; legacy Monitoring Stations therefore remain interoperable with monitored routers that emit the new TLV. In mixed deployments where legacy Monitoring Stations are present, operators SHOULD ensure that BGP instance disambiguation is achieved by some other means (for example, by using separate BMP sessions per BGP instance, or by arranging that peer addresses are unique across instances). A Monitoring Station that implements this extension but receives BMP messages from a legacy monitored router - i.e., a router that does not emit the BGP Instance Name TLV - SHOULD treat such messages as originating from the BGP base instance.

Security Considerations This document defines a new TLV for use within BMP messages and does not alter the underlying BMP transport, authentication, or authorization model. The security considerations of and therefore apply unchanged. The BGP Instance Name is administratively assigned on the monitored router and may reveal information about the internal structure of the operator's network (for example, the existence and naming of tenant-specific or service-specific BGP instances). Operators who regard Instance Names as sensitive SHOULD ensure that BMP sessions are carried over a confidential and integrity-protected transport, as recommended by . A misbehaving or compromised monitored router could emit forged or misleading BGP Instance Name TLVs. Monitoring Stations SHOULD NOT take policy or control actions based solely on the value of the BGP Instance Name without additional authentication of the monitored router.

IANA Considerations This document requests that IANA allocate one new code point in each of the following registries under the "BGP Monitoring Protocol (BMP) Parameters" registry group, referring to this document.

BMP Peer Up and Peer Down TLVs Registry IANA is requested to allocate a new code point in the "BMP Peer Up and Peer Down TLVs" registry (as defined by , updating ): BMP Peer Up and Peer Down TLVs Allocation

Value	Description	Reference
TBD	BGP Instance Name	This document

BMP Route Monitoring TLVs Registry IANA is requested to allocate a new code point in the "BMP Route Monitoring TLVs" registry (as defined by ): BMP Route Monitoring TLVs Allocation

Value	Description	Reference
TBD	BGP Instance Name	This document

BMP Statistics TLVs Registry IANA is requested to allocate a new code point in the "BMP Statistics TLVs" registry (as defined by ): BMP Statistics TLVs Allocation

Value	Description	Reference
TBD	BGP Instance Name	This document

BMP Route Mirroring TLVs Registry IANA is requested to allocate a new code point in the "BMP Route Mirroring TLVs" registry : BMP Route Mirroring TLVs Allocation

Value	Description	Reference
TBD	BGP Instance Name	This document

It is RECOMMENDED that IANA assign the same numeric code point across all of the above registries, for consistency of implementation. The Value field for each allocation is defined in of this document.