Multi-Threaded Routing Toolkit (MRT) Routing Information Export Format with BGP Additional Path Extensions

The MRT record format was developed to provide researchers and engineers a means to encapsulate, export, and archive routing protocol transactions and RIB snapshots. The Advertisement of Multiple Paths in BGP defines a BGP extension to allow the advertisement of multiple paths for the same address prefix without the new paths implicitly replacing any previous ones. This document contains an optional extension to the MRT format and introduces additional definitions of MRT subtype fields to permit representation of multiple path advertisements .

MRT parsers are usually stateless. In order to parse BGP messages that contain data structures that depend on the capabilities negotiated during the BGP session setup, the MRT subtypes are utilized. The Advertisement of Multiple Paths extension for BGP alters the encoding of the BGP Network Layer Reachability Information (NLRI) format for withdraws and announcements. Therefore, new BGP4MP/BGP4MP_ET subtypes as defined in are required to signal to an MRT parser how to parse the NLRI. In Section 4.3 of the MRT specification , RIB subtypes are specified. Prefix length and prefix fields are encoded in the same manner as the BGP NLRI encoding. In order to support Path Identifier information as defined in , new subtypes need to be added. The following two sections define the required subtypes.

This document defines the following new subtypes: BGP4MP_MESSAGE_ADDPATH BGP4MP_MESSAGE_AS4_ADDPATH BGP4MP_MESSAGE_LOCAL_ADDPATH BGP4MP_MESSAGE_AS4_LOCAL_ADDPATH The fields of these message types are identical to the equivalent non-additional-path versions specified in Section 4.4 of. These enhancements continue to encapsulate the entire BGP message in the BGP message field.

This document defines the following new subtypes: RIB_IPV4_UNICAST_ADDPATH RIB_IPV4_MULTICAST_ADDPATH RIB_IPV6_UNICAST_ADDPATH RIB_IPV6_MULTICAST_ADDPATH RIB_GENERIC_ADDPATH The fields of these message types are identical to the equivalent non-additional-path versions specified in Section 4.3 of. However, for the case of the 4 AFI/SAFI-specific RIB subtypes, the existing RIB Entries field is redefined as detailed in the sections below.

In order to preserve the record compaction achieved by using the most common subtypes and allow multiple RIB Entries to be stored in a single TABLE_DUMP_V2 record, the existing RIB Entries field is redefined for use within the new AFI/SAFI-specific RIB subtypes defined by this document as follows:

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 Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Originated Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Path Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BGP Attributes... (variable) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This adds a field to the RIB Entries record to store the Path Identifier when used with the RIB_IPV4_UNICAST_ADDPATH, RIB_IPV4_MULTICAST_ADDPATH, RIB_IPV6_UNICAST_ADDPATH, and RIB_IPV6_MULTICAST_ADDPATH subtypes.

The fields of this subtype are identical to the equivalent non-additional-path versions specified in Section 4.3.3 of. These fields continue to encapsulate the raw and additional-path-enabled AFI/SAFI/NLRI in the record, and the raw attributes in the RIB Entries. For clarity, the RIB Entries in this subtype are not redefined.

IANA has assigned the subtype codes defined below in the "Multi-threaded Routing Toolkit (MRT)" registry <https://www.iana.org/assignments/mrt>.

The following have been registered in the "BGP4MP Subtype Codes" and "BGP4MP_ET Subtype Codes" registries: 8 BGP4MP_MESSAGE_ADDPATH (RFC 8050) 9 BGP4MP_MESSAGE_AS4_ADDPATH (RFC 8050) 10 BGP4MP_MESSAGE_LOCAL_ADDPATH (RFC 8050) 11 BGP4MP_MESSAGE_AS4_LOCAL_ADDPATH (RFC 8050)

The following have been registered in the "TABLE_DUMP_V2 Subtype Codes" registry: 8 RIB_IPV4_UNICAST_ADDPATH (RFC 8050) 9 RIB_IPV4_MULTICAST_ADDPATH (RFC 8050) 10 RIB_IPV6_UNICAST_ADDPATH (RFC 8050) 11 RIB_IPV6_MULTICAST_ADDPATH (RFC 8050) 12 RIB_GENERIC_ADDPATH (RFC 8050)

It is not believed that this document adds any additional security considerations. However, the security considerations of are equally applicable to this document, because this document permits the export of more detailed routing data. An organization that uses the MRT format to store their BGP routing information should be aware that supporting these extensions permits more detailed network path information to be stored and should consider the implications of this within their environment. An organization that peers with public BGP collectors and enables the capability for additional paths on a peering session should be aware that it is exporting not only its best paths, but potentially other paths within its networks. The BGP peer should consider any and all implications of exposing this additional data.