Internet-Draft local-path-id October 2023
Younsi, et al. Expires 25 April 2024 [Page]
Network Working Group
9069 (if approved)
Intended Status:
Standards Track
M. Younsi
P. Francois
P. Lucente

BMP Local Path-ID


Intelligence is required to track BGP paths throughout the various RIBs and VRFs of a routing platform, due to potential attribute modifications and the use of BGP multipath. This document introduces the option to identify a path within a router in order to ease correlation in monitoring. A BMPv4 TLV is defined in order to communicate this locally significant identifier in monitoring messages.

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

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

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 25 April 2024.

Table of Contents

1. Introduction

When using VRFs and/or BGP Multipath, multiple paths to the same destination may be shared among various routing information bases. From a collection perspective, tracking the identity of a path thus requires some form of modeling, which is subject to inaccuracy. This aspect is exacerbated as path attributes may be modified in the process. This is especially problematic when a PE using BGP multipath in VPN instances exports multiple paths for the same destination into the default VRF, which were learned from different peers.

While BGP ADD-PATH provides a way to identify paths in BGP multi-path scenarios, the scope of ADD-PATH path-id is local to a single BGP peering session, and thus cannot be used to distinguish paths received over multiple sessions.

This document introduces a way to identify paths globally within a router, allowing operators to not resort to modeling when monitoring BGP paths on a router. In Section 2, we introduce the concept of Local Path ID, which is an identifier of a path for a given NLRI, which is preserved through the import/export operations performed onto them. In Section 3, we introduce a BMPv4 TLV allowing to communicate the value of a Local Path ID on a BMP session.

2. Local Path ID

In this section, we define an identifier called Local Path ID, which allows to uniquely identify a path for a given NLRI on a router.

According to this specification, a path to be advertised by BMP is provided with an associated Local Path ID. The Local Path ID is an opaque numerical value with a few properties guaranteeing its utility. The exact approach to generate a Local Path ID is however left for the implementation.

2.1. Local Path ID Properties

The Local Path ID of each path MUST be unique for a given NLRI. We scope the identifier space to each NLRI to keep it a small value. Indeed, most internet routers have at most a few tens of paths for a given NLRI.

The Local Path ID only has a meaning locally on the router generating it.

Once generated, the Local Path ID MUST be preserved between VRFs, and Routing Information Bases. It, however, MUST NOT be exchanged or synchronized between routers.

The value of 0 for a Local Path ID is reserved.

2.2. Design Recommendation

In this specification, we recommend making the Local Path ID made of two concatenated parts: < process_id | path_discriminator >.

The process_id is the identifier of the process which produced, originated, or received a path. The process_id allows differentiation between path IDs generated in BGP and in other processes like an IGP. Redistributed IGP paths will then have a different Local Path ID no matter if BGP or another IGP has chosen the same path_discriminator value. Using the process_id avoids requiring interprocess synchronization of path_discriminators or the use of a path_discriminator managing process.

The path_discriminator allows differentiation between different paths for a NLRI, coming from the same process (with the same process_id). This process originating the path is in charge of guaranteeing the uniqueness of the path_discriminator it produces for each path of its NLRIs.

To ensure traceability in monitoring, processes importing a path (like BGP redistribution or VRF imports) SHOULD keep the same Local Path ID if provided by the source.

3. Advertising the Local Path ID in BMP

The Local Path ID is included in BMPv4 Route Monitoring messages [I-D.ietf-grow-bmp-tlv] as an optional TLV, called "Local Path ID TLV".

 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 (TBD)             |       Length (2 octets)       |
|        Index (2 octets)       |
~                         local_path_id                         ~

Figure 1
set to TBD
the length of the Local Path ID, in bytes (TBD static or dynamic)
index of the NLRI in the BGP Update PDU as described by [I-D.ietf-grow-bmp-tlv]. The Index MUST refer to a single NLRI (no Group TLV).
the Local Path ID defined in Section 2, on Length (Section 3) bytes

An implementation enabled for Local Path ID usage MUST notify if a Local Path ID is unavailable (for any reason) by setting the value field to the reserved value of 0. This means such implementations SHOULD always include a Local Path ID TLV (Section 3).

4. Normative References

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <>.
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <>.
Lucente, P. and Y. Gu, "TLV support for BMP Route Monitoring and Peer Down Messages", Work in Progress, Internet-Draft, draft-ietf-grow-bmp-tlv-12, , <>.

Authors' Addresses

Maxence Younsi
Pierre Francois
Paolo Lucente
Siriusdreef 70-72
Hoofddorp, WT 2132