Global Routing OperationsInternet Engineering Task Force (IETF) C. PetrieInternet-DraftRequest for Comments: 8050 RIPE NCCIntended status:Category: Standards Track T. KingExpires: July 18, 2017ISSN: 2070-1721 DE-CIXJanuary 14,May 2017 Multi-Threaded Routing Toolkit (MRT) Routing Information Export Format with BGP AdditionalPathsPath Extensionsdraft-ietf-grow-mrt-add-paths-03Abstract This documentupdatesextends the Multi-threaded Routing Toolkit (MRT) export format for Border Gateway Protocol (BGP) routing information byextending it to supportsupporting theAdvertisementadvertisement ofMultiple Pathsmultiple paths in BGP extensions. Status of This Memo ThisInternet-Draftissubmitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documentsan Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF).Note that other groups may also distribute working documents as Internet-Drafts. The listIt represents the consensus ofcurrent Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents validthe IETF community. It has received public review and has been approved fora maximumpublication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 ofsix monthsRFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may beupdated, replaced, or obsoleted by other documentsobtained atany 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 July 18, 2017.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 specificAFI/SAFI-Specific RIB Subtypes . . . . . . . . . . . . .34 4.2. RIB_GENERIC_ADDPATH Subtype . . . . . . . . . . . . . . . 4 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . .45 5.1. BGP4MP/BGP4MP_ET Subtypecodes:Codes . . . . . . . . . . . . .45 5.2. TABLE_DUMP_V2 Subtypecodes:Codes . . . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 7.References . . . . . . . . . . . . . . . . . . . . . . . . . 5 7.1.Normative References . . . . . . . . . . . . . . . . . .5 7.2. URIs . . . . . . . . . . . . . . . . . . . . . . . .. . 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 androuting information baseRIB 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 messageswhichthat contain data structures that depend on the capabilities negotiated during the BGP session setup, theso-calledMRT subtypes are utilized. The Advertisement of MultiplePathPaths [RFC7911] extension for BGP alters the encoding of the BGPNLRINetwork Layer Reachability Information (NLRI) format for withdraws and announcements.ThereforeTherefore, new BGP4MP/BGP4MP_ET subtypes as defined in [RFC6396] are required to signal toaan MRT parser how to parse the NLRI. InsectionSection 4.3[RFC6396]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 supportpath identifierPath Identifier information as defined in[RFC7911][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 newSubtypes: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 insectionSection 4.4 of [RFC6396]. These enhancementscontinuescontinue to encapsulate the entire BGP message in the BGP message field. 4. MRT Subtypes for Type TABLE_DUMP_V2 This document defines the following newSubtypes: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 insectionSection 4.3 of [RFC6396]. However, for thespecificcase of the 4AFI/SAFI specificAFI/SAFI-specific RIB subtypes, the existing RIB Entries field isre-definedredefined as detailed in the sections below. 4.1.AFI/SAFI specificAFI/SAFI-Specific RIB Subtypes In order to preserve the record compaction achieved by using the most commonsubtypes,subtypes andallowingallow multiple RIB Entries to be stored in a single TABLE_DUMP_V2 record, the existing RIB Entries field is redefined for use within the newAFI/SAFI specificAFI/SAFI-specific RIBSubtypessubtypes 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 forAFI/SAFI-specificAFI/SAFI-Specific RIB Subtypes withadditional-paths supportSupport for Additional Paths This adds a field to the RIB Entriesrecord,record to store thepath identifier,Path Identifier when used with the RIB_IPV4_UNICAST_ADDPATH, RIB_IPV4_MULTICAST_ADDPATH,RIB_IPV6_UNICAST_ADDPATHRIB_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 insectionSection 4.3.3 of [RFC6396]. These fields continue to encapsulate the raw andadditional-pathadditional-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 ConsiderationsThis document requests thatIANAassignhas assigned thefollowingsubtype codestodefined below in theMRT name space [1]:"Multi- threaded Routing Toolkit (MRT)" registry <https://www.iana.org/assignments/mrt>. 5.1. BGP4MP/BGP4MP_ET Subtypecodes: BGP4MP_MESSAGE_ADDPATH =Codes The following have been registered in the "BGP4MP Subtype Codes" and "BGP4MP_ET Subtype Codes" registries: 8(Section 3) BGP4MP_MESSAGE_AS4_ADDPATH =BGP4MP_MESSAGE_ADDPATH (RFC 8050) 9(Section 3) BGP4MP_MESSAGE_LOCAL_ADDPATH =BGP4MP_MESSAGE_AS4_ADDPATH (RFC 8050) 10(Section 3) BGP4MP_MESSAGE_AS4_LOCAL_ADDPATH =BGP4MP_MESSAGE_LOCAL_ADDPATH (RFC 8050) 11(Section 3) The values provided above are suggested as they are used in implementations.BGP4MP_MESSAGE_AS4_LOCAL_ADDPATH (RFC 8050) 5.2. TABLE_DUMP_V2 Subtypecodes: RIB_IPV4_UNICAST_ADDPATH =Codes The following have been registered in the "TABLE_DUMP_V2 Subtype Codes" registry: 8(Section 4.1) RIB_IPV4_MULTICAST_ADDPATH =RIB_IPV4_UNICAST_ADDPATH (RFC 8050) 9(Section 4.1) RIB_IPV6_UNICAST_ADDPATH =RIB_IPV4_MULTICAST_ADDPATH (RFC 8050) 10(Section 4.1) RIB_IPV6_MULTICAST_ADDPATH =RIB_IPV6_UNICAST_ADDPATH (RFC 8050) 11(Section 4.1) RIB_GENERIC_ADDPATH =RIB_IPV6_MULTICAST_ADDPATH (RFC 8050) 12(Section 4.2) The values provided above are suggested as they are used in implementations.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,andbecause 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 bestored,stored and should consider the implications of this within their environment. An organization that peers with public BGPcollectors,collectors and enables theadditional-pathscapability for additional paths on a peeringsession,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.References 7.1.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>.7.2. URIs [1] https://www.iana.org/assignments/mrt/mrt.xhtmlAuthors' Addresses Colin Petrie RIPE NCC Stationsplein 11 Amsterdam 1012 ABNLThe Netherlands Email: cpetrie@ripe.net Thomas King DE-CIX Management GmbH Lichtstrasse 43i Cologne 50825 Germany Email: thomas.king@de-cix.net