BMP Loc-RIB: Peer address

Using BMP Loc-RIB , the Peer Address field of a Per-Peer header is Zero-filled. This prevents a collector from knowing from which peer a path selected as best was received. The nexthop attribute of a path is indeed not an identifier of the peer from which the path was received. Knowing the peer address is also especially useful when Loc-RIB paths come from Add-Path enabled peers as the path ID space of paths are defined per peer. When VRFs are in use, the peer address information can only be interpreted in the VRF context within which the corresponding peering is taking place. This document introduces a BMPv4 TLV describing the address of the peer that announced the path to the current router, and BMPv4 TLVs describing the VRF context in which the path was received.

In this section, we describe a solution based on BMPv4 TLVs. describes a BMPv4 TLV used to convey the peer address. introduces optional TLVs for the case of paths imported from another VRF.

In BMPv4 , TLV's can be used to provide optional information along with monitored paths. Peer Address information can be included using one such TLV. A TLV type "Rx Peer-Address TLV" needs to be reserved from the BMP Route Monitoring TLVs registry. The length field is 4 when the peer is IPv4 and 16 when the peer is IPv6, as the index field of the TLV is not included in the length field. The value is the IP address of the peer from which the monitored path was received. The structure is illustrated in Figure . The Rx Peer-Address TLV may describe a self originated path by setting the value of the peer address to 0. The length of such a zero filled Peer-Address TLV SHOULD be either 4 or 16.

Path information advertised through BMP Loc-RIB might be related to a path imported from another VRF. In that scenario, the sole knowledge of the remote peer IP address is not sufficient to obtain a clear picture of where this path was coming from. A TLV type "Origin VRF TLV" needs to be reserved from the BMP Route Monitoring TLVs registry. It describes the VRF context in which this path was received from a peer or where it was self-originated. It contains a variable length field matching the definition of VRF/Table name from . The length field of this BMPv4 TLV is the length of the UTF-8 string of the VRF name. When this TLV is present, the Rx Peer-Address TLV associated with that path refers to the IP address of the peer from which it was received, in the VRF context refered in this TLV. A TLV type "Previous VRF TLV" needs to be reserved from the BMP Route Monitoring TLVs registry. It describes the VRF from which this path was imported. It contains a variable length field matching the definition of VRF/Table name from . The length field of this BMPv4 TLV is the length of the UTF-8 string of the VRF name. As an example, if BMP Loc-RIB describes a path P in VRF C, which was received from a peer I in VRF A, imported into VRF B, and finally imported from VRF B into VRF C, the Origin VRF Name is A, the Previous VRF Name is B, the VRF/Table Name TLV (as per is C, and the Rx Peer-Adress TLV is I.

A TLV type "Previous VRF sequence" needs to be reserved from the BMP Route Monitoring TLVs registry. It describes the entire chain of VRFs through which this path was imported before landing in the current VRF. The list starts with the previous VRF, and ends with the Origin VRF in which this path was received or originated. One entry of this list has the format described in Figure . The length field is an 8 bit value capturing the length of the Name field. The name field is the VRF name of the described VRF of the sequence, matching the definition of VRF/Table name from . A complete Previous VRF Sequence TLV structure is illustrated in Figure .

The length of a "Previous VRF Sequence" TLV is the sum of the total lengths of each VRF entry in the sequence (1 byte for the length field + the value of the length field). This does not include the length of the Index field as defined in . In the example above , the sequence listed in the Previous VRF sequence would be [B, A].