idnits 2.17.1 draft-ietf-grow-mrt-add-paths-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 14, 2017) is 2630 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 246 Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Global Routing Operations C. Petrie 3 Internet-Draft RIPE NCC 4 Intended status: Standards Track T. King 5 Expires: July 18, 2017 DE-CIX 6 January 14, 2017 8 Multi-Threaded Routing Toolkit (MRT) Routing Information Export Format 9 with BGP Additional Paths Extensions 10 draft-ietf-grow-mrt-add-paths-03 12 Abstract 14 This document updates the Multi-threaded Routing Toolkit (MRT) export 15 format for Border Gateway Protocol (BGP) routing information by 16 extending it to support the Advertisement of Multiple Paths in BGP 17 extensions. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on July 18, 2017. 36 Copyright Notice 38 Copyright (c) 2017 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 2 55 3. MRT Subtypes for Types BGP4MP/BGP4MP_ET . . . . . . . . . . . 3 56 4. MRT Subtypes for Type TABLE_DUMP_V2 . . . . . . . . . . . . . 3 57 4.1. AFI/SAFI specific RIB Subtypes . . . . . . . . . . . . . 3 58 4.2. RIB_GENERIC_ADDPATH Subtype . . . . . . . . . . . . . . . 4 59 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 60 5.1. BGP4MP/BGP4MP_ET Subtype codes: . . . . . . . . . . . . . 4 61 5.2. TABLE_DUMP_V2 Subtype codes: . . . . . . . . . . . . . . 5 62 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 63 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 65 7.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 68 1. Introduction 70 The MRT record format [RFC6396] was developed to provide researchers 71 and engineers a means to encapsulate, export, and archive routing 72 protocol transactions and routing information base snapshots. 74 The Advertisement of Multiple Paths in BGP [RFC7911] defines a BGP 75 extension to allow the advertisement of multiple paths for the same 76 address prefix without the new paths implicitly replacing any 77 previous ones. 79 This document contains an optional extension to the MRT format 80 [RFC6396] and introduces additional definitions of MRT subtype fields 81 to permit representation of multiple path advertisements [RFC7911]. 83 2. Rationale 85 MRT parsers are usually stateless. In order to parse BGP messages 86 which contain data structures that depend on the capabilities 87 negotiated during the BGP session setup, the so-called MRT subtypes 88 are utilized. The Advertisement of Multiple Path [RFC7911] extension 89 for BGP alters the encoding of the BGP NLRI format for withdraws and 90 announcements. Therefore new BGP4MP/BGP4MP_ET subtypes as defined in 91 [RFC6396] are required to signal to a MRT parser how to parse the 92 NLRI. 94 In section 4.3 [RFC6396] of the MRT specification RIB subtypes are 95 specified. Prefix length and prefix fields are encoded in the same 96 manner as the BGP NLRI encoding. In order to support path identifier 97 information as defined in [RFC7911] new subtypes need to be added. 99 The following two sections define the required subtypes. 101 3. MRT Subtypes for Types BGP4MP/BGP4MP_ET 103 This document defines the following new Subtypes: 105 o BGP4MP_MESSAGE_ADDPATH 107 o BGP4MP_MESSAGE_AS4_ADDPATH 109 o BGP4MP_MESSAGE_LOCAL_ADDPATH 111 o BGP4MP_MESSAGE_AS4_LOCAL_ADDPATH 113 The fields of these message types are identical to the equivalent 114 non-additional-path versions specified in section 4.4 [RFC6396]. 115 These enhancements continues to encapsulate the entire BGP message in 116 the BGP message field. 118 4. MRT Subtypes for Type TABLE_DUMP_V2 120 This document defines the following new Subtypes: 122 o RIB_IPV4_UNICAST_ADDPATH 124 o RIB_IPV4_MULTICAST_ADDPATH 126 o RIB_IPV6_UNICAST_ADDPATH 128 o RIB_IPV6_MULTICAST_ADDPATH 130 o RIB_GENERIC_ADDPATH 132 The fields of these message types are identical to the equivalent 133 non-additional-path versions specified in section 4.3 [RFC6396]. 134 However, for the specific case of the 4 AFI/SAFI specific RIB 135 subtypes, the existing RIB Entries field is re-defined as detailed in 136 the sections below. 138 4.1. AFI/SAFI specific RIB Subtypes 140 In order to preserve the record compaction achieved by using the most 141 common subtypes, and allowing multiple RIB Entries to be stored in a 142 single TABLE_DUMP_V2 record, the existing RIB Entries field is 143 redefined for use within the new AFI/SAFI specific RIB Subtypes 144 defined by this document as follows: 146 0 1 2 3 147 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 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | Peer Index | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 | Originated Time | 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | Path Identifier | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | Attribute Length | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | BGP Attributes... (variable) 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 Figure 1: RIB Entries for AFI/SAFI-specific RIB Subtypes with 161 additional-paths support 163 This adds a field to the RIB Entries record, to store the path 164 identifier, when used with the RIB_IPV4_UNICAST_ADDPATH, 165 RIB_IPV4_MULTICAST_ADDPATH, RIB_IPV6_UNICAST_ADDPATH and 166 RIB_IPV6_MULTICAST_ADDPATH subtypes. 168 4.2. RIB_GENERIC_ADDPATH Subtype 170 The fields of this subtype are identical to the equivalent non- 171 additional-path versions specified in section 4.3.3 [RFC6396]. These 172 fields continue to encapsulate the raw and additional-path enabled 173 AFI/SAFI/NLRI in the record, and the raw attributes in the RIB 174 Entries. 176 For clarity, the RIB Entries in this subtype are not redefined. 178 5. IANA Considerations 180 This document requests that IANA assign the following subtype codes 181 to the MRT name space [1]: 183 5.1. BGP4MP/BGP4MP_ET Subtype codes: 185 BGP4MP_MESSAGE_ADDPATH = 8 (Section 3) 187 BGP4MP_MESSAGE_AS4_ADDPATH = 9 (Section 3) 189 BGP4MP_MESSAGE_LOCAL_ADDPATH = 10 (Section 3) 190 BGP4MP_MESSAGE_AS4_LOCAL_ADDPATH = 11 (Section 3) 192 The values provided above are suggested as they are used in 193 implementations. 195 5.2. TABLE_DUMP_V2 Subtype codes: 197 RIB_IPV4_UNICAST_ADDPATH = 8 (Section 4.1) 199 RIB_IPV4_MULTICAST_ADDPATH = 9 (Section 4.1) 201 RIB_IPV6_UNICAST_ADDPATH = 10 (Section 4.1) 203 RIB_IPV6_MULTICAST_ADDPATH = 11 (Section 4.1) 205 RIB_GENERIC_ADDPATH = 12 (Section 4.2) 207 The values provided above are suggested as they are used in 208 implementations. 210 6. Security Considerations 212 It is not believed that this document adds any additional security 213 considerations. 215 However, the security considerations of [RFC6396] are equally 216 applicable to this document, and this document permits the export of 217 more detailed routing data. 219 An organization that uses the MRT format to store their BGP routing 220 information should be aware that supporting these extensions permits 221 more detailed network path information to be stored, and should 222 consider the implications of this within their environment. 224 An organization that peers with public BGP collectors, and enables 225 the additional-paths capability on a peering session, should be aware 226 that it is exporting not only its best paths, but potentially other 227 paths within its networks. The BGP peer should consider any and all 228 implications of exposing this additional data. 230 7. References 232 7.1. Normative References 234 [RFC6396] Blunk, L., Karir, M., and C. Labovitz, "Multi-Threaded 235 Routing Toolkit (MRT) Routing Information Export Format", 236 RFC 6396, DOI 10.17487/RFC6396, October 2011, 237 . 239 [RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder, 240 "Advertisement of Multiple Paths in BGP", RFC 7911, 241 DOI 10.17487/RFC7911, July 2016, 242 . 244 7.2. URIs 246 [1] https://www.iana.org/assignments/mrt/mrt.xhtml 248 Authors' Addresses 250 Colin Petrie 251 RIPE NCC 252 Stationsplein 11 253 Amsterdam 1012 AB 254 NL 256 Email: cpetrie@ripe.net 258 Thomas King 259 DE-CIX Management GmbH 260 Lichtstrasse 43i 261 Cologne 50825 262 Germany 264 Email: thomas.king@de-cix.net