BMP Extension for Monitoring Multiple BGP Instances

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 24 October 2026.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

The BGP Monitoring Protocol (BMP) [RFC7854] 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 [RFC4271]).¶
• 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 [I-D.ietf-grow-bmp-tlv], which extends RFC 7854 to support TLV-encoded optional data across all BMP message types.¶

2. 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 [RFC4271].¶

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 [RFC3629].¶

Monitored Router:

A BMP-speaking device that runs one or more BGP instances and sends BMP messages to a Monitoring Station, as defined in [RFC7854].¶

Monitoring Station:

A BMP-receiving entity, as defined in [RFC7854].¶

TLV:

Type-Length-Value element, as defined in [I-D.ietf-grow-bmp-tlv].¶

3. 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 [RFC7854] is used to express a Route Distinguisher [RFC4364] 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 [RFC9069]) 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.¶

4. BGP Instance Name TLV

This document defines a new TLV, the BGP Instance Name TLV, using the TLV encoding and semantics of [I-D.ietf-grow-bmp-tlv]. The TLV carries the Instance Name of the BGP instance with which the enclosing BMP message is associated.¶

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E|         Type = TBD          |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~            BGP Instance Name (variable, UTF-8)                ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5. 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.¶

6. Backward Compatibility

A Monitoring Station that does not implement this extension will treat the BGP Instance Name TLV as an unknown TLV. Per [I-D.ietf-grow-bmp-tlv], 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.¶

7. 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 [RFC7854] and [I-D.ietf-grow-bmp-tlv] 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 [RFC7854].¶

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.¶

8. 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.¶

Authors' Addresses