idnits 2.17.1 draft-petrie-grow-mrt-add-paths-00.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 (October 11, 2015) is 3110 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.narten-iana-considerations-rfc2434bis' is defined on line 266, but no explicit reference was found in the text == Unused Reference: 'RFC2629' is defined on line 272, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 276, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-idr-add-paths-11 -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Petrie 3 Internet-Draft RIPE NCC 4 Intended status: Informational October 11, 2015 5 Expires: April 13, 2016 7 Multi-Threaded Routing Toolkit (MRT) Routing Information Export Format 8 with BGP Additional Paths Extensions 9 draft-petrie-grow-mrt-add-paths-00 11 Abstract 13 This document updates the Multi-threaded Routing Toolkit (MRT) export 14 format for Border Gateway Protocol (BGP) routing information by 15 extending it to support the Advertisement of Multiple Paths in BGP 16 extensions. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on April 13, 2016. 35 Copyright Notice 37 Copyright (c) 2015 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 54 3. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 2 55 4. MRT Subtypes for Type BGP4MP . . . . . . . . . . . . . . . . 3 56 5. MRT Subtypes for Type TABLE_DUMP_V2 . . . . . . . . . . . . . 4 57 5.1. AFI/SAFI specific RIB Subtypes . . . . . . . . . . . . . 4 58 5.2. RIB_GENERIC_AP Subtype . . . . . . . . . . . . . . . . . 5 59 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 60 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 61 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 63 8.2. Informative References . . . . . . . . . . . . . . . . . 6 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 66 1. Introduction 68 Researchers and engineers often wish to analyze network behavior by 69 studying routing protocol transactions and routing information base 70 snapshots. To this end, the MRT record format [RFC6396] was 71 developed to encapsulate, export, and archive this information in a 72 standardized data representation. 74 The Advertisement of Multiple Paths in BGP [I-D.ietf-idr-add-paths] 75 defines a BGP extension to allow the advertisement of multiple paths 76 for the same address prefix without the new paths implicitly 77 replacing any previous ones. The essence of the extension is that 78 each path is identified by a path identifier in addition to the 79 addres prefix 81 This memo documents an optional extension to the MRT format RFC6396 82 [RFC6396] and introduces additional definitions of MRT Subtype fields 83 to permit representation of Multiple Path advertisements 85 2. Requirements Language 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 89 document are to be interpreted as described in RFC 2119 [RFC2119]. 91 3. Rationale 93 When a BGP message requires information about the capabilities 94 negotiated during the setup of the BGP session for a parser to 95 interpret the message, this information is carried by the MRT 96 subtypes. 98 The MRT specification defines the following BGP4MP subtypes: 100 o BGP4MP_MESSAGE 102 o BGP4MP_MESSAGE_AS4 104 o BGP4MP_MESSAGE_LOCAL 106 o BGP4MP_MESSAGE_AS4_LOCAL 108 These indicate to a parser whether the AS_PATH and AGGREGATOR 109 attributes should be interpretted according to the rules in RFC6793 110 [RFC6793] 112 Additional Paths in BGP [I-D.ietf-idr-add-paths] alters the encoding 113 of the BGP NLRI format for withdraws and announcements. Therefore 114 new BGP4MP subtypes are required to signal to a parser how to parse 115 the NLRI. 117 The MRT specification defines the following TABLE_DUMP_V2 subtypes: 119 o RIB_IPV4_UNICAST 121 o RIB_IPV4_MULTICAST 123 o RIB_IPV6_UNICAST 125 o RIB_IPV6_MULTICAST 127 o RIB_GENERIC 129 The existing TABLE_DUMP_V2 AFI/SAFI-Specific RIB Subtypes specify 130 that the Prefix Length and Prefix fields are encoded in the same 131 manner as the BGP NLRI encoding. These also require new subtypes to 132 retain the path identifier information in Additional Paths. 134 The TABLE_DUMP_V2 RIB_GENERIC subtype contains a single raw NLRI 135 entry, the encoding of which is defined by the AFI and SAFI. 136 Additional Paths alter the NLRI encoding. Therefore a new subtype is 137 required to indicate the change in NLRI format. 139 4. MRT Subtypes for Type BGP4MP 141 This document defines the following new Subtypes: 143 o BGP4MP_MESSAGE_AP 145 o BGP4MP_MESSAGE_AS4_AP 146 o BGP4MP_MESSAGE_LOCAL_AP 148 o BGP4MP_MESSAGE_AS4_LOCAL_AP 150 The fields of these message types are identical to the equivalent 151 non-additional-path versions specified in RFC 6396 [RFC6396], and 152 continues to encapsulate the entire BGP message in the BGP Message 153 field. 155 5. MRT Subtypes for Type TABLE_DUMP_V2 157 This document defines the following new Subtypes: 159 o RIB_IPV4_UNICAST_AP 161 o RIB_IPV4_MULTICAST_AP 163 o RIB_IPV6_UNICAST_AP 165 o RIB_IPV6_MULTICAST_AP 167 o RIB_GENERIC_AP 169 The fields of these message types are identical to the equivalent 170 non-additional-path versions specified in RFC 6396 [RFC6396]. 171 However, for the specific case of the 4 AFI/SAFI specific RIB 172 Subtypes, the existing RIB Entries field is re-defined as detailed in 173 the sections below. 175 5.1. AFI/SAFI specific RIB Subtypes 177 In order to preserve the record compaction achieved by using the most 178 common subtypes, and allowing multiple RIB entries to be stored in a 179 single TABLE_DUMP_V2 record, the existing RIB Entries field is 180 redefined for use within the new AFI/SAFI specific RIB Subtypes 181 defined by this document as follows: 183 0 1 2 3 184 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 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | Peer Index | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | Originated Time | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | Path Identifier | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | Attribute Length | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | BGP Attributes... (variable) 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 Figure 1: RIB Entries for AFI/SAFI-specific RIB Subtypes with 198 additional-paths support 200 This adds a field to the RIB Entries record, to store the Path 201 Identifier, when used with the RIB_IPV4_UNICAST_AP, 202 RIB_IPV4_MULTICAST_AP, RIB_IPV6_UNICAST_AP and RIB_IPV6_MULTICAST_AP 203 Subtypes 205 5.2. RIB_GENERIC_AP Subtype 207 The fields of this message types is identical to the equivalent non- 208 additional-path versions specified in RFC 6396 [RFC6396], and 209 continues to encapsulate the raw AFI/SAFI/NLRI in the record, and the 210 raw attributes in the RIB Entries. 212 The RIB entries are unchanged, and should be interpreted according to 213 RFC 6396 [RFC6396] 215 6. IANA Considerations 217 This document requests that IANA add the appropriate Type Codes and 218 Subtype Codes (to be assigned). This is currently a placeholder. 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 [RFC6396] are equally 226 applicable to this document, and this document permits the export of 227 more detailed routing data. 229 An organisation which 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 network that peers with public BGP collectors, and enable the 235 additional-paths capability on a the peering session, should be aware 236 that they are exporting not only their best paths, but potentially 237 other paths within their network. The BGP peer should consider any 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-11 (work in progress), October 2015. 249 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 250 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 251 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 [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet 260 Autonomous System (AS) Number Space", RFC 6793, DOI 261 10.17487/RFC6793, December 2012, 262 . 264 8.2. Informative References 266 [I-D.narten-iana-considerations-rfc2434bis] 267 Narten, T. and H. Alvestrand, "Guidelines for Writing an 268 IANA Considerations Section in RFCs", draft-narten-iana- 269 considerations-rfc2434bis-09 (work in progress), March 270 2008. 272 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, DOI 273 10.17487/RFC2629, June 1999, 274 . 276 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 277 Text on Security Considerations", BCP 72, RFC 3552, DOI 278 10.17487/RFC3552, July 2003, 279 . 281 Author's Address 283 Colin Petrie 284 RIPE NCC 285 Amsterdam 286 NL 288 Email: cpetrie@ripe.net