idnits 2.17.1 draft-ietf-grow-mrt-add-paths-01.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 8, 2016) is 2849 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 277 == Unused Reference: 'RFC2629' is defined on line 261, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 265, but no explicit reference was found in the text == Unused Reference: 'RFC5226' is defined on line 270, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 4 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: January 9, 2017 DE-CIX Management GmbH 6 July 8, 2016 8 Multi-Threaded Routing Toolkit (MRT) Routing Information Export Format 9 with BGP Additional Paths Extensions 10 draft-ietf-grow-mrt-add-paths-01 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 January 9, 2017. 36 Copyright Notice 38 Copyright (c) 2016 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. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 55 3. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 4. MRT Subtypes for Types BGP4MP/BGP4MP_ET . . . . . . . . . . . 3 57 5. MRT Subtypes for Type TABLE_DUMP_V2 . . . . . . . . . . . . . 3 58 5.1. AFI/SAFI specific RIB Subtypes . . . . . . . . . . . . . 4 59 5.2. RIB_GENERIC_ADDPATH Subtype . . . . . . . . . . . . . . . 4 60 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 61 6.1. BGP4MP/BGP4MP_ET Subtype codes: . . . . . . . . . . . . . 5 62 6.2. TABLE_DUMP_V2 Subtype codes: . . . . . . . . . . . . . . 5 63 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 64 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 66 8.2. Informative References . . . . . . . . . . . . . . . . . 6 67 8.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 70 1. Introduction 72 The MRT record format [RFC6396] was developed to provide researchers 73 and engineers a means to encapsulate, export, and archive routing 74 protocol transactions and routing information base snapshots. 76 The Advertisement of Multiple Paths in BGP [I-D.ietf-idr-add-paths] 77 defines a BGP extension to allow the advertisement of multiple paths 78 for the same address prefix without the new paths implicitly 79 replacing any previous ones. 81 This document contains an optional extension to the MRT format 82 [RFC6396] and introduces additional definitions of MRT subtype fields 83 to permit representation of multiple path advertisements 84 [I-D.ietf-idr-add-paths]. 86 2. Requirements Language 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 90 document are to be interpreted as described in RFC 2119 [RFC2119]. 92 3. Rationale 94 MRT parsers are usually stateless. In order to parse BGP messages 95 which contain data structures that depend on the capabilities 96 negotiated during the BGP session setup, the so-called MRT subtypes 97 are utilized. The Advertisement of Multiple Path 98 [I-D.ietf-idr-add-paths] extension for BGP alters the encoding of the 99 BGP NLRI format for withdraws and announcements. Therefore new 100 BGP4MP/BGP4MP_ET subtypes as defined in [RFC6396] are required to 101 signal to a MRT parser how to parse the NLRI. 103 In section 4.3 [RFC6396] of the MRT specification RIB subtypes are 104 specified. Prefix length and prefix fields are encoded in the same 105 manner as the BGP NLRI encoding. In order to support path identifier 106 information as defined in [I-D.ietf-idr-add-paths] new subtypes need 107 to be added. 109 The following two sections define the required subtypes. 111 4. MRT Subtypes for Types BGP4MP/BGP4MP_ET 113 This document defines the following new Subtypes: 115 o BGP4MP_MESSAGE_ADDPATH 117 o BGP4MP_MESSAGE_AS4_ADDPATH 119 o BGP4MP_MESSAGE_LOCAL_ADDPATH 121 o BGP4MP_MESSAGE_AS4_LOCAL_ADDPATH 123 The fields of these message types are identical to the equivalent 124 non-additional-path versions specified in section 4.4 [RFC6396]. 125 These enhancements continues to encapsulate the entire BGP message in 126 the BGP message field. 128 5. MRT Subtypes for Type TABLE_DUMP_V2 130 This document defines the following new Subtypes: 132 o RIB_IPV4_UNICAST_ADDPATH 134 o RIB_IPV4_MULTICAST_ADDPATH 136 o RIB_IPV6_UNICAST_ADDPATH 138 o RIB_IPV6_MULTICAST_ADDPATH 139 o RIB_GENERIC_ADDPATH 141 The fields of these message types are identical to the equivalent 142 non-additional-path versions specified in section 4.3 [RFC6396]. 143 However, for the specific case of the 4 AFI/SAFI specific RIB 144 subtypes, the existing RIB Entries field is re-defined as detailed in 145 the sections below. 147 5.1. AFI/SAFI specific RIB Subtypes 149 In order to preserve the record compaction achieved by using the most 150 common subtypes, and allowing multiple RIB Entries to be stored in a 151 single TABLE_DUMP_V2 record, the existing RIB Entries field is 152 redefined for use within the new AFI/SAFI specific RIB Subtypes 153 defined by this document as follows: 155 0 1 2 3 156 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 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | Peer Index | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | Originated Time | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | Path Identifier | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | Attribute Length | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | BGP Attributes... (variable) 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 Figure 1: RIB Entries for AFI/SAFI-specific RIB Subtypes with 170 additional-paths support 172 This adds a field to the RIB Entries record, to store the path 173 identifier, when used with the RIB_IPV4_UNICAST_ADDPATH, 174 RIB_IPV4_MULTICAST_ADDPATH, RIB_IPV6_UNICAST_ADDPATH and 175 RIB_IPV6_MULTICAST_ADDPATH subtypes. 177 5.2. RIB_GENERIC_ADDPATH Subtype 179 The fields of this subtype are identical to the equivalent non- 180 additional-path versions specified in section 4.3.3 [RFC6396]. These 181 fields continue to encapsulate the raw and additional-path enabled 182 AFI/SAFI/NLRI in the record, and the raw attributes in the RIB 183 Entries. 185 For clarity, the RIB Entries in this subtype are not redefined. 187 6. IANA Considerations 189 This document requests that IANA assign the following subtype codes 190 to the MRT name space [1]: 192 6.1. BGP4MP/BGP4MP_ET Subtype codes: 194 BGP4MP_MESSAGE_ADDPATH = 8 (Section 4) 196 BGP4MP_MESSAGE_AS4_ADDPATH = 9 (Section 4) 198 BGP4MP_MESSAGE_LOCAL_ADDPATH = 10 (Section 4) 200 BGP4MP_MESSAGE_AS4_LOCAL_ADDPATH = 11 (Section 4) 202 The values provided above are suggested as they are used in 203 implementations. 205 6.2. TABLE_DUMP_V2 Subtype codes: 207 RIB_IPV4_UNICAST_ADDPATH = 8 (Section 5.1) 209 RIB_IPV4_MULTICAST_ADDPATH = 9 (Section 5.1) 211 RIB_IPV6_UNICAST_ADDPATH = 10 (Section 5.1) 213 RIB_IPV6_MULTICAST_ADDPATH = 11 (Section 5.1) 215 RIB_GENERIC_ADDPATH = 12 (Section 5.2) 217 The values provided above are suggested as they are used in 218 implementations. 220 7. Security Considerations 222 It is not believed that this document adds any additional security 223 considerations. 225 However, the security considerations of [RFC6396] are equally 226 applicable to this document, and this document permits the export of 227 more detailed routing data. 229 An organization that uses the MRT format to store their BGP routing 230 information should be aware that supporting these extensions permits 231 more detailed network path information to be stored, and should 232 consider the implications of this within their environment. 234 An organization that peers with public BGP collectors, and enables 235 the additional-paths capability on a peering session, should be aware 236 that it is exporting not only its best paths, but potentially other 237 paths within its networks. The BGP peer should consider any and all 238 implications of exposing this additional data. 240 8. References 242 8.1. Normative References 244 [I-D.ietf-idr-add-paths] 245 Walton, D., Retana, A., Chen, E., and J. Scudder, 246 "Advertisement of Multiple Paths in BGP", draft-ietf-idr- 247 add-paths-15 (work in progress), May 2016. 249 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 250 Requirement Levels", BCP 14, RFC 2119, 251 DOI 10.17487/RFC2119, March 1997, 252 . 254 [RFC6396] Blunk, L., Karir, M., and C. Labovitz, "Multi-Threaded 255 Routing Toolkit (MRT) Routing Information Export Format", 256 RFC 6396, DOI 10.17487/RFC6396, October 2011, 257 . 259 8.2. Informative References 261 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 262 DOI 10.17487/RFC2629, June 1999, 263 . 265 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 266 Text on Security Considerations", BCP 72, RFC 3552, 267 DOI 10.17487/RFC3552, July 2003, 268 . 270 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 271 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 272 DOI 10.17487/RFC5226, May 2008, 273 . 275 8.3. URIs 277 [1] https://www.iana.org/assignments/mrt/mrt.xhtml 279 Authors' Addresses 281 Colin Petrie 282 RIPE NCC 283 Singel 258 284 Amsterdam 1016 AB 285 NL 287 Email: cpetrie@ripe.net 289 Thomas King 290 DE-CIX Management GmbH 291 Lichtstrasse 43i 292 Cologne 50825 293 Germany 295 Email: thomas.king@de-cix.net