Internet-Draft BMP Peer Interface July 2026
Lin, et al. Expires 7 January 2027 [Page]
Workgroup:
GROW
Internet-Draft:
draft-lin-grow-bmp-peer-interface-02
Published:
Intended Status:
Standards Track
Expires:
Authors:
C. Lin
New H3C Technologies
Y. Liu
China Mobile
M. Srivastava
Hewlett Packard Enterprise
P. Francois
INSA-Lyon
M. Younsi
INSA-Lyon

Extension for BMP Peer Interface

Abstract

This document proposes extending BMP to allow BMP messages with the per-peer header to carry interface information for the established peer session, especially in order to distinguish parallel link-local and unnumbered BGP peers established based on distinct interfaces.

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 7 January 2027.

▲

Table of Contents

1. Introduction

When BGP establishes a peer relationship using a link-local address or unnumbered address, the local outgoing interface must be specified for the relationship to be established successfully. In other words, parallel link-local or unnumbered BGP peers can only be distinguished by interface information.

However, the peer information in a BMP message does not include peer interface information, making it impossible to distinguish which BGP peer the reported BMP message originated from or sent to in scenarios involving parallel link-local or unnumbered BGP peers.

This document introduces two approaches that enables BMP messages with the per-peer header to carry interface information for the established peer session.

2. Terminology

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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

3. Solutions

This section presents two BMP extensions designed to convey peer interface information within BMP messages: one extends the BMPv4 TLV structure, while the other introduces an extension to the BMP per-peer header.

3.1. BMPv4 TLV Extension

In order to report the BMP messages that need to be distinguished through peer interface information, this section extends "Rx Peer-Address TLV" defined in [I-D.ietf-grow-bmp-loc-peer], and defines a new BMPv4 [I-D.ietf-grow-bmp-tlv] TLV. This new BMPv4 TLV is designed to convey interface information of the peer to which the monitored path is sent and is therefore named the "Tx Peer-Interface TLV".

3.1.1. Rx Peer-Address TLV Extension

This section introduces the extension of the "Rx Peer-Address TLV" to carry the peer interface information. The structure of the "Rx Peer-Address TLV" is defined in [I-D.ietf-grow-bmp-loc-peer] and is shown in Figure 1.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Type (2 octets)        |       Length (2 octets)       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|G|      Index (15 bits)        | Address Type  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                    Rx Peer Address (variable)                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 1: Rx Peer-Address TLV

This document defines new four address types, as follows:

  • Address Type = 4: IPv6 Address with Interface ID. The "Rx Peer Address" is the 16 bytes IPv6 Address of the peer, followed by an interface ID of a variable size S. The "Length" is thus set to 1 + 16 + S.
  • Address Type = 5: IPv6 Address with Interface Name. The "Rx Peer Address" is the 16 bytes IPv6 Address of the peer, followed by an interface name of a variable size S, encoded in UTF-8 without specific termination characters. The "Length" is thus set to 1 + 16 + S.
  • Address Type = 6: IPv4 Address with Interface ID. The "Rx Peer Address" is the 4 bytes IPv4 Address of the peer, followed by an interface ID of a variable size S. The "Length" is thus set to 1 + 4 + S.
  • Address Type = 7: IPv4 Address with Interface Name. The "Rx Peer Address" is the 4 bytes IPv4 Address of the peer, followed by an interface name of a variable size S, encoded in UTF-8 without specific termination characters. The "Length" is thus set to 1 + 4 + S.

The "Rx Peer-Address TLV" could be used for Local-RIB, Adj-RIB-In, and Adj-RIB-Out.

For Local-RIB, this TLV is only used for BMP Route Monitoring Messages.

For Adj-RIB-In, this TLV can be used for BMP Route Monitoring Messages, BMP Route Mirroring Messages, and BMP Stats Reports Messages, and the "Index" field MUST be ignored.

For Adj-RIB-Out, this TLV can be used for BMP Route Monitoring Messages and BMP Route Mirroring Messages.

For Non-Local-RIB peers, this TLV can be used for BMP Peer Down Notification Messages and Peer Up Notification Messages, and the "Index" field also MUST be ignored.

3.1.2. Tx Peer-Interface TLV

This section introduces the new "Tx Peer-Interface TLV" to carry the peer interface information. The TLV structure is illustrated in Figure 2.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Type (2 octets)        |       Length (2 octets)       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Subtype    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                  Tx Peer Interface (variable)                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 2: Tx Peer-Interface TLV

The "Tx Peer-Interface TLV" type is TBD1. The value of the TLV is the "Subtype" code (1 octet) followed by the "Tx Peer Interface" information used to establish the related peer session. The "Length" field is one (for the "Subtype" field) plus the length of the "Tx Peer Interface" field.

The "Subtype" field is defined, as shown below:

  • Subtype = 1: IPv6 Address with Interface ID. The "Tx Peer Interface" is the 16 bytes IPv6 Address of the peer, followed by an interface ID of a variable size S. The "Length" is thus set to 1 + 16 + S.
  • Subtype = 2: IPv6 Address with Interface Name. The "Tx Peer Interface" is the 16 bytes IPv6 Address of the peer, followed by an interface name of a variable size S, encoded in UTF-8 without specific termination characters. The "Length" is thus set to 1 + 16 + S.
  • Subtype = 3: IPv4 Address with Interface ID. The "Tx Peer Interface" is the 4 bytes IPv4 Address of the peer, followed by an interface ID of a variable size S. The "Length" is thus set to 1 + 4 + S.
  • Subtype = 4: IPv4 Address with Interface Name. The "Tx Peer Interface" is the 4 bytes IPv4 Address of the peer, followed by an interface name of a variable size S, encoded in UTF-8 without specific termination characters. The "Length" is thus set to 1 + 4 + S.

The "Tx Peer-Interface TLV" could only be used for Adj-RIB-Out.

For Adj-RIB-Out, this TLV can be used for BMP Route Monitoring Messages and BMP Route Mirroring Messages, and BMP Stats Reports Messages.

For Non-Local-RIB peers, this TLV can also be used for BMP Peer Down Notification Messages and Peer Up Notification Messages.

For BMP Peer Down Notification Messages and Peer Up Notification Messages, only one of the "Tx Peer-Interface TLV" and "Rx Peer-Address TLV" is allowed to carry the peer interface information.

3.2. Per-Peer Header Extension

To enable the distinction of BMP messages based on peer interfaces, this section defines new BMP peer types and extends the BMP per-peer header accordingly.

3.2.1. BMP Peer Type Definition

The peer types are defined as follows:

  • Peer Type = TBD1 (RECOMMENDED value 4): Global Instance Interface Peer.
  • Peer Type = TBD2 (RECOMMENDED value 5): RD Instance Interface Peer.

BMP messages using the peer types defined in this document MUST include peer interface information in the per-peer header.

3.2.2. New Per-Peer Header Format

For new BMP peer types defined in this document, this section defines a new per-peer header, called the "Interface Per-Peer Header". It is defined according to per-peer header of [RFC7854], as shown in Figure 2.

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Peer Type   |  Peer Flags   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Peer Distinguisher (present based on peer type)       |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 Peer Address (16 bytes)                       |
~                                                               ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Peer Interface Index (present based on peer type)     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Peer AS                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Peer BGP ID                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Timestamp (seconds)                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                  Timestamp (microseconds)                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           Figure 2: Interface Per-Peer Header Format

Compared with per-peer header of [RFC7854], the Peer Interface Index is added to indicate the interface used to establish BGP peers. Other fields are defined in Section 4.2 of [RFC7854] and Section 4 of [RFC8671].

4. Operational Considerations

This document introduces two solutions designed to convey peer interface information within BMP messages: one is the BMPv4 TLV extension, and the other is the BMP per-peer header extension. The BMP per-peer header extension could apply to BMPv3 and BMPv4 [I-D.ietf-grow-bmp-tlv], but the interface is identified only by its interface index. If the interface name must be needed to identify a interface, the BMP per-peer header extension cannot be used; only the BMPv4 TLV extension can be used. The BMPv4 TLV extension applies exclusively to BMPv4. And when reporting BMP Local RIB messages requires peer interface information, the BMPv4 TLV extension MUST be used.

When a BMP monitoring station needs to distinguish between parallel BGP sessions established over different interfaces (e.g., using link-local or unnumbered addresses), the BMPv4 TLV extension or BMP per-peer header extension SHOULD be included in the relevant BMP messages.

When a BMP sender generates a BMP message that requires distinguishing peers by interface, the BMP message SHOULD include the BMPv4 TLV extension or BMP per-peer header extension. The BMP receiver needs to be able to resolve this TLV extension or this per-peer header extension to correctly associate the BMP message with the BGP peer on a specific interface.

BMP receivers with older versions that do not support this TLV or this new peer type MAY ignore unknown TLVs or peer types, but this MAY prevent them from correctly identifying parallel interface-based peers.

5. Security Considerations

TBD

6. IANA Considerations

TBD

7. References

7.1. Normative References

[I-D.ietf-grow-bmp-loc-peer]
Francois, P., Younsi, M., and P. Lucente, "BMP Loc-RIB: Peer address", Work in Progress, Internet-Draft, draft-ietf-grow-bmp-loc-peer-02, , <https://datatracker.ietf.org/doc/html/draft-ietf-grow-bmp-loc-peer-02>.
[I-D.ietf-grow-bmp-tlv]
Lucente, P., Gu, Y., Younsi, M., and P. Francois, "BMP v4: Extended TLV Support for BGP Monitoring Protocol (BMP)", Work in Progress, Internet-Draft, draft-ietf-grow-bmp-tlv-20, , <https://datatracker.ietf.org/doc/html/draft-ietf-grow-bmp-tlv-20>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC7854]
Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP Monitoring Protocol (BMP)", RFC 7854, DOI 10.17487/RFC7854, , <https://www.rfc-editor.org/info/rfc7854>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.
[RFC8671]
Evens, T., Bayraktar, S., Lucente, P., Mi, P., and S. Zhuang, "Support for Adj-RIB-Out in the BGP Monitoring Protocol (BMP)", RFC 8671, DOI 10.17487/RFC8671, , <https://www.rfc-editor.org/info/rfc8671>.

Authors' Addresses

Changwang Lin
New H3C Technologies
Beijing
China
Yisong Liu
China Mobile
32 Xuanwumen West Street
Beijing
Xicheng District, 100053
China
Mukul Srivastava
Hewlett Packard Enterprise
Pierre Francois
INSA-Lyon
Villeurbanne
France
Maxence Younsi
INSA-Lyon
Villeurbanne
France