MRT with Add-Paths: Multi-Threaded Routing Toolkit (MRT) Routing Information Export Format with BGP Additional Path Extensions
New MRT record subtypes so routing archives can store several BGP paths for the same prefix.
Petrie, C. and T. King, "Multi-Threaded Routing Toolkit (MRT) Routing Information Export Format with BGP Additional Path Extensions", RFC 8050, DOI 10.17487/RFC8050, May 2017, <https://www.rfc-editor.org/info/rfc8050>.
@misc{rfc8050,
series = {Request for Comments},
number = 8050,
howpublished = {RFC 8050},
publisher = {RFC Editor},
doi = {10.17487/RFC8050},
url = {https://www.rfc-editor.org/info/rfc8050},
author = {C. Petrie and T. King},
title = {{Multi-Threaded Routing Toolkit (MRT) Routing Information Export Format with BGP Additional Path Extensions}},
pagetotal = 6,
year = 2017,
month = may,
} RFC text
Contents
Internet Engineering Task Force (IETF) C. Petrie
Request for Comments: 8050 RIPE NCC
Category: Standards Track T. King
ISSN: 2070-1721 DE-CIX
May 2017
Multi-Threaded Routing Toolkit (MRT) Routing Information Export Format
with BGP Additional Path Extensions
Abstract
This document extends the Multi-threaded Routing Toolkit (MRT) export
format for Border Gateway Protocol (BGP) routing information by
supporting the advertisement of multiple paths in BGP extensions.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc8050.
Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. MRT Subtypes for Types BGP4MP/BGP4MP_ET . . . . . . . . . . . 3
4. MRT Subtypes for Type TABLE_DUMP_V2 . . . . . . . . . . . . . 3
4.1. AFI/SAFI-Specific RIB Subtypes . . . . . . . . . . . . . 4
4.2. RIB_GENERIC_ADDPATH Subtype . . . . . . . . . . . . . . . 4
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
5.1. BGP4MP/BGP4MP_ET Subtype Codes . . . . . . . . . . . . . 5
5.2. TABLE_DUMP_V2 Subtype Codes . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
7. Normative References . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
The MRT record format [RFC6396] 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 [RFC7911] 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
[RFC6396] and introduces additional definitions of MRT subtype fields
to permit representation of multiple path advertisements [RFC7911].
2. Rationale
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 [RFC7911] 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 [RFC6396] are
required to signal to an MRT parser how to parse the NLRI.
In Section 4.3 of the MRT specification [RFC6396], 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 [RFC7911], new subtypes need to be added.
The following two sections define the required subtypes.
3. MRT Subtypes for Types BGP4MP/BGP4MP_ET
This document defines the following new subtypes:
o BGP4MP_MESSAGE_ADDPATH
o BGP4MP_MESSAGE_AS4_ADDPATH
o BGP4MP_MESSAGE_LOCAL_ADDPATH
o 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 [RFC6396].
These enhancements continue to encapsulate the entire BGP message in
the BGP message field.
4. MRT Subtypes for Type TABLE_DUMP_V2
This document defines the following new subtypes:
o RIB_IPV4_UNICAST_ADDPATH
o RIB_IPV4_MULTICAST_ADDPATH
o RIB_IPV6_UNICAST_ADDPATH
o RIB_IPV6_MULTICAST_ADDPATH
o RIB_GENERIC_ADDPATH
The fields of these message types are identical to the equivalent
non-additional-path versions specified in Section 4.3 of [RFC6396].
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.
4.1. AFI/SAFI-Specific RIB Subtypes
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)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: RIB Entries for AFI/SAFI-Specific RIB Subtypes with
Support for Additional Paths
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.
4.2. RIB_GENERIC_ADDPATH Subtype
The fields of this subtype are identical to the equivalent non-
additional-path versions specified in Section 4.3.3 of [RFC6396].
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.
5. IANA Considerations
IANA has assigned the subtype codes defined below in the "Multi-
threaded Routing Toolkit (MRT)" registry
<https://www.iana.org/assignments/mrt>.
5.1. BGP4MP/BGP4MP_ET Subtype Codes
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)
5.2. TABLE_DUMP_V2 Subtype Codes
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)
6. Security Considerations
It is not believed that this document adds any additional security
considerations. However, the security considerations of [RFC6396]
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.
7. Normative References
[RFC6396] Blunk, L., Karir, M., and C. Labovitz, "Multi-Threaded
Routing Toolkit (MRT) Routing Information Export Format",
RFC 6396, DOI 10.17487/RFC6396, October 2011,
<http://www.rfc-editor.org/info/rfc6396>.
[RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder,
"Advertisement of Multiple Paths in BGP", RFC 7911,
DOI 10.17487/RFC7911, July 2016,
<http://www.rfc-editor.org/info/rfc7911>.
Authors' Addresses
Colin Petrie
RIPE NCC
Stationsplein 11
Amsterdam 1012 AB
The Netherlands
Email: cpetrie@ripe.net
Thomas King
DE-CIX Management GmbH
Lichtstrasse 43i
Cologne 50825
Germany
Email: thomas.king@de-cix.net
AI ELI5
On this page
§1What This Extension Adds
The MRT record format from RFC 6396 gives researchers and engineers a way to encapsulate, export and archive routing protocol transactions and RIB snapshots. RFC 7911 defines a BGP extension that lets a speaker advertise multiple paths for the same address prefix without the new paths implicitly replacing earlier ones.
RFC 8050 is an optional extension to MRT. It introduces new subtype definitions so that multiple path advertisements can be represented in MRT files.
A log of routes could only note one way to reach a place. This RFC lets the log hold several ways, as the newer BGP allows.
§2Why New Subtypes Are Needed
MRT parsers are usually stateless. They do not watch the BGP session setup, so they cannot know which capabilities were negotiated. The additional paths extension changes how the BGP Network Layer Reachability Information (NLRI) is encoded for withdrawals and announcements. The parser has to be told how to read the NLRI, and the MRT subtype is the place to say it.
The same problem exists for RIB records. In RFC 6396 the prefix length and prefix fields are encoded the same way as the BGP NLRI encoding, so supporting the Path Identifier from RFC 7911 also needs new subtypes.
A reader of the log cannot ask the people who wrote it what they meant. So the page type itself has to say how to read the entries.
§3New BGP4MP and BGP4MP_ET Subtypes
Four new subtypes are defined for the BGP4MP and BGP4MP_ET types: BGP4MP_MESSAGE_ADDPATH, BGP4MP_MESSAGE_AS4_ADDPATH, BGP4MP_MESSAGE_LOCAL_ADDPATH and BGP4MP_MESSAGE_AS4_LOCAL_ADDPATH.
Their fields are identical to the equivalent non-additional-path versions in Section 4.4 of RFC 6396. They continue to encapsulate the entire BGP message in the BGP message field. Only the subtype tells the parser that the NLRI inside uses additional-path encoding.
The pages look the same as before. Only the page title changes, to warn the reader that the entries inside carry extra labels.
§4New TABLE_DUMP_V2 Subtypes and the Path Identifier
Five new subtypes are defined for TABLE_DUMP_V2: RIB_IPV4_UNICAST_ADDPATH, RIB_IPV4_MULTICAST_ADDPATH, RIB_IPV6_UNICAST_ADDPATH, RIB_IPV6_MULTICAST_ADDPATH and RIB_GENERIC_ADDPATH. Their fields are identical to the non-additional-path versions in Section 4.3 of RFC 6396, except for the RIB Entries field of the four AFI/SAFI-specific subtypes.
To keep the record compaction of the common subtypes, and to let several RIB Entries sit in one record, the RIB Entries field is redefined. Each entry gains a Path Identifier field, placed after the Originated Time and before the Attribute Length.
RIB_GENERIC_ADDPATH is different. Its fields match Section 4.3.3 of RFC 6396 and carry the raw, additional-path-enabled AFI/SAFI/NLRI, and its RIB Entries are not redefined.
Each saved route entry gets a small extra label saying which of the several roads it is. The catch-all page type needs no change.
- 8RIB_IPV4_UNICAST_ADDPATH — IPv4 unicast RIB with Path Identifier.
- 9RIB_IPV4_MULTICAST_ADDPATH — IPv4 multicast RIB with Path Identifier.
- 10RIB_IPV6_UNICAST_ADDPATH — IPv6 unicast RIB with Path Identifier.
- 11RIB_IPV6_MULTICAST_ADDPATH — IPv6 multicast RIB with Path Identifier.
- 12RIB_GENERIC_ADDPATH — Generic RIB; RIB Entries not redefined.
§5Assigned Subtype Codes
IANA assigned the codes in the Multi-threaded Routing Toolkit (MRT) registry. The four BGP4MP subtypes take values 8 to 11 in both the BGP4MP and BGP4MP_ET registries. The five TABLE_DUMP_V2 subtypes take values 8 to 12.
Each new page type was given its own number so everyone uses the same name for it.
§6Security Considerations
The RFC does not believe it adds new security considerations, but the considerations of RFC 6396 apply equally, because the extension permits export of more detailed routing data.
An organization that stores its BGP routing information in MRT should know that these extensions allow more detailed network path information to be stored. An organization that peers with public BGP collectors and enables additional paths on a session is exporting not only its best paths but potentially other paths within its networks, and should weigh the implications.
Writing down every road you know, not only your favorite, tells outsiders more about your town. Think before you share the longer list.