BMP Local Path-ID

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 the 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 , we introduce the concept of Local Path ID, which is an identifier of a path for a given NLRI, preserved through the import/export operations performed onto them. In , we introduce a BMPv4 TLV allowing to communicate the value of a Local Path ID on a BMP session.

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.

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. While we put a minimum scope (the NLRI) for the identifier space, an implementor may decide to use a broader space for this unicity, as long as Local Path IDs are still unique for a given NLRI. For example, Local Path IDs can be unique accross VRFs, even though they will have to be larger, as this does not violate the rule. 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.

In this section, we give general recommendations for the Local Path ID generation. These recommendations may or may not be applicable depending on the platform, the implementation of BGP, etc. The actual generation process of the Local Path ID does not matter as long as the the properties defined in are respected. We recommend having the Local Path ID made of three concatenated parts: < process_id | vrf_id | path_discriminator >. The path_discriminator allows differentiation between different paths for a NLRI, coming from the same table and process (with the same vrf_id and process_id). The process originating the path is in charge of guaranteeing the uniqueness of the path_discriminator it produces for each path of its NLRIs. The vrf_id represents a unique identifier for the VRF in which the path to the NLRI is contained. It allows leveraging the already existing routing table structures of most BGP implementations by having to guarantee the uniqueness of the path_discriminator only within the table. 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 from path IDs generated 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 Local Path ID management process. To ensure traceability in monitoring, processes importing a path (like BGP redistribution or VRF imports) MUST keep the same Local Path ID if provided by the source.

The Local Path ID is to be included in BMPv4 Route Monitoring messages as an optional TLV, called "Local Path ID TLV".

Type:: set to TBD
Length:: the length of the Local Path ID, in bytes
Index:: index of the NLRI in the BGP Update PDU as described by . The Index MUST refer to a single NLRI (no Group TLV).
local_path_id:: the Local Path ID defined in

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, on a single byte, followed by a 2-byte error code from . The Length field of the "Local Path ID TLV" is thus set to 3 in this case. Local Path ID Unavailability Reason Codes

Code	Description
0x00	Unknown Reason
0x01	Origin process did not provide a Local Path ID.
0x02	All Local Path ID have already been allocated.

This means such implementations SHOULD always include a Local Path ID TLV.