idnits 2.17.1 draft-ietf-idr-large-community-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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Large BGP Communities MUST be represented as three separate unsigned decimal numbers, without leading zeros, in the following order: Global Administrator, Local Data 1, Local Data 2. Numbers MUST not be omitted, even when zero. For example: 64496:4294967295:2 or 64496:0:0 or (64496, 111, 222). -- The document date (October 16, 2016) is 2746 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 316 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR J. Heitz, Ed. 3 Internet-Draft Cisco 4 Intended status: Standards Track J. Snijders, Ed. 5 Expires: April 19, 2017 NTT 6 K. Patel 7 Arrcus 8 I. Bagdonas 9 Equinix 10 A. Simpson 11 Nokia 12 N. Hilliard 13 INEX 14 October 16, 2016 16 Large BGP Communities 17 draft-ietf-idr-large-community-03 19 Abstract 21 This document describes the Large BGP Communities attribute, an 22 extension to BGP-4. This attribute provides a mechanism to signal 23 opaque information within separate namespaces to aid in routing 24 management. The attribute is suitable for use in four-octet ASNs. 26 Requirements Language 28 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 29 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 30 document are to be interpreted as described in [RFC2119]. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on April 19, 2017. 49 Copyright Notice 51 Copyright (c) 2016 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Large BGP Communities Attribute . . . . . . . . . . . . . . . 3 68 3. Aggregation . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 4. Canonical Representation . . . . . . . . . . . . . . . . . . 4 70 5. Reserved Large BGP Community values . . . . . . . . . . . . . 4 71 6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 4 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 73 8. Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION 5 74 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 75 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 76 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 77 11.1. Normative References . . . . . . . . . . . . . . . . . . 6 78 11.2. Informative References . . . . . . . . . . . . . . . . . 7 79 11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 7 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 82 1. Introduction 84 BGP implementations typically support a routing policy language to 85 control the distribution of routing information. Network operators 86 attach BGP communities to routes to identify intrinsic properties of 87 these routes. These properties may include information such as the 88 route origin location, or specification of a routing policy action to 89 be taken, or one that has been taken, and may apply to an individual 90 route or to a group of routes. Because BGP communities are optional 91 transitive BGP attributes, BGP communities may be acted upon or 92 otherwise used by routing policies in other Autonomous Systems (ASes) 93 on the Internet. 95 [RFC1997] BGP Communities attributes are four-octet values split into 96 two two-octet words. The most significant word is usually 97 interpreted as an Autonomous System Number (ASN) and the least 98 significant word is a locally defined value whose meaning is assigned 99 by the operator of the Autonomous System in the most significant 100 word. 102 Since the adoption of four-octet ASNs [RFC6793], the BGP Communities 103 attribute can no longer accommodate the above encoding, as a two- 104 octet word cannot fit a four-octet ASN. The BGP Extended Communities 105 attribute [RFC4360] is also unsuitable, as the protocol limit of six 106 octets cannot accommodate both a four-octet Global Administrator 107 value and a four-octet Local Administrator value, which precludes the 108 common operational practice of encoding a target ASN in the Local 109 Administrator field. 111 To address these shortcomings, this document defines a Large BGP 112 Communities attribute encoded as one or more twelve-octet values, 113 each consisting of a four-octet ASN and two four-octet operator- 114 defined values, each of which can be used to denote properties or 115 actions significant to that ASN. 117 2. Large BGP Communities Attribute 119 This document creates the Large BGP Communities attribute as an 120 optional transitive path attribute of variable length. All routes 121 with the Large BGP Communities attribute belong to the community 122 specified in the attribute. 124 The attribute consists of one or more twelve-octet values. Each 125 twelve-octet Large BGP Communities value represents three four-octet 126 values, as follows: 128 0 1 2 3 129 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 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 | Global Administrator | 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 | Local Data Part 1 | 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 | Local Data Part 2 | 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 Global Administrator: A four-octet namespace identifier. This 139 SHOULD be an Autonomous System Number. 141 Local Data Part 1: A four-octet operator-defined value. 143 Local Data Part 2: A four-octet operator-defined value. 145 The Global Administrator field is intended to allow different 146 Autonomous Systems to define Large BGP Communities without collision. 147 Implementations MUST allow the operator to specify any value for the 148 Global Administrator field. 150 There is no significance to the order in which Large BGP Communities 151 are encoded in a path attributes field and a receiving speaker MAY 152 retransmit them in an order different from which it received them. 154 Duplicate Large BGP Communities SHOULD NOT be transmitted. A 155 receiving speaker SHOULD silently remove duplicate Large BGP 156 Communities from a BGP UPDATE message. 158 3. Aggregation 160 If a range of routes is aggregated, then the resulting aggregate 161 should have a Large BGP Communities attribute which contains all of 162 the Large BGP Communities attributes from all of the aggregated 163 routes. 165 4. Canonical Representation 167 Large BGP Communities MUST be represented as three separate unsigned 168 decimal numbers, without leading zeros, in the following order: 169 Global Administrator, Local Data 1, Local Data 2. Numbers MUST not 170 be omitted, even when zero. For example: 64496:4294967295:2 or 171 64496:0:0 or (64496, 111, 222). 173 5. Reserved Large BGP Community values 175 The Large BGP Community attribute values in the following ranges are 176 reserved: 178 0:0:0 - 0:4294967295:4294967295 179 65535:0:0 - 65535:4294967295:4294967295 180 4294967295:0:0 - 4294967295:4294967295:4294967295 182 6. Error Handling 184 The error handling of Large BGP Communities is as follows: 186 o A Large BGP Communities attribute with a length of zero MUST be 187 ignored upon receipt and removed when sending. 189 o A Large BGP Communities attribute SHALL be considered malformed if 190 its length is not a non-zero multiple of 12 bytes. 192 o A BGP UPDATE message with a malformed Large BGP Communities 193 attribute SHALL be handled using the approach of "treat-as- 194 withdraw" as described in section 2 [RFC7606]. 196 The Large BGP Communities Global Administrator field may contain any 197 value, and a Large BGP Communities attribute MUST NOT be considered 198 malformed if the Global Administrator field contains an unallocated, 199 unassigned or reserved ASN or is set to one of the reserved Large BGP 200 Community values defined in Section 5. 202 7. Security Considerations 204 This extension to BGP has similar security implications as BGP 205 Communities [RFC1997]. 207 This document does not change any underlying security issues 208 associated with any other BGP Communities mechanism. Specifically, 209 an AS relying on the Large BGP Communities attribute carried in BGP 210 must have trust in every other AS in the path, as any intermediate 211 Autonomous System in the path may have added, deleted or altered the 212 Large BGP Communities attribute. Specifying the mechanism to provide 213 such trust is beyond the scope of this document. 215 Network administrators should note the recommendations in Section 11 216 of BGP Operations and Security [RFC7454]. 218 8. Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION 220 This section records the status of known implementations of the 221 protocol defined by this specification at the time of posting of this 222 Internet-Draft, and is based on a proposal described in [RFC7942]. 223 The description of implementations in this section is intended to 224 assist the IETF in its decision processes in progressing drafts to 225 RFCs. Please note that the listing of any individual implementation 226 here does not imply endorsement by the IETF. Furthermore, no effort 227 has been spent to verify the information presented here that was 228 supplied by IETF contributors. This is not intended as, and must not 229 be construed to be, a catalog of available implementations or their 230 features. Readers are advised to note that other implementations may 231 exist. 233 As of today these vendors have produced an implementation of Large 234 BGP Communities: 236 o Cisco IOS XR 238 o ExaBGP 239 o GoBGP 241 o BIRD 243 o OpenBGPD 245 o pmacct 247 The latest implementation news is tracked at 248 http://largebgpcommunities.net/ [1]. 250 9. IANA Considerations 252 IANA has made an Early Allocation of the value 30 (LARGE_COMMUNITY) 253 in the "BGP Path Attributes" registry under the "Border Gateway 254 Protocol (BGP) Parameters" group and is now asked to make that 255 Permanent. 257 10. Acknowledgments 259 The authors would like to thank Ruediger Volk, Russ White, Acee 260 Lindem, Shyam Sethuram, Jared Mauch, Joel M. Halpern, Jeffrey Haas, 261 John Heasley, Gunter van de Velde, Marco Marzetti, Eduardo Ascenco 262 Reis, Mark Schouten, Paul Hoogsteder, Martijn Schmidt, Greg Hankins, 263 Acee Lindem, Bertrand Duvivier, Barry O'Donovan, Grzegorz Janoszka, 264 Linda Dunbar, Marco Davids, Gaurab Raj Upadhaya, Jeff Tantsura, Teun 265 Vink, Adam Davenport, Theodore Baschak, Pier Carlo Chiodi, Nabeel 266 Cocker, Ian Dickinson, Jan Baggen, Duncan Lockwood, David Farmer, 267 Randy Bush, Wim Henderickx, Stefan Plug, Kay Rechthien, Rob Shakir, 268 Warren Kumari, Gert Doering, Thomas King, Mikael Abrahamsson, Wesley 269 Steehouwer, Sander Steffann, Brad Dreisbach, Martin Millnert, 270 Christopher Morrow, Jay Borkenhagen, Arnold Nipper, Joe Provo, Niels 271 Bakker, Bill Fenner, Tom Daly, Ben Maddison, Alexander Azimov, Brian 272 Dickson, Peter van Dijk, Julian Seifert, Tom Petch, Tom Scholl, Arjen 273 Zonneveld, and Remco van Mook for their support, insightful review 274 and comments. 276 11. References 278 11.1. Normative References 280 [RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities 281 Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996, 282 . 284 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 285 Requirement Levels", BCP 14, RFC 2119, 286 DOI 10.17487/RFC2119, March 1997, 287 . 289 [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet 290 Autonomous System (AS) Number Space", RFC 6793, 291 DOI 10.17487/RFC6793, December 2012, 292 . 294 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 295 Patel, "Revised Error Handling for BGP UPDATE Messages", 296 RFC 7606, DOI 10.17487/RFC7606, August 2015, 297 . 299 11.2. Informative References 301 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 302 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 303 February 2006, . 305 [RFC7454] Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations 306 and Security", BCP 194, RFC 7454, DOI 10.17487/RFC7454, 307 February 2015, . 309 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 310 Code: The Implementation Status Section", BCP 205, 311 RFC 7942, DOI 10.17487/RFC7942, July 2016, 312 . 314 11.3. URIs 316 [1] http://largebgpcommunities.net 318 Authors' Addresses 320 Jakob Heitz (editor) 321 Cisco 322 170 West Tasman Drive 323 San Jose, CA 95054 324 USA 326 Email: jheitz@cisco.com 327 Job Snijders (editor) 328 NTT Communications 329 Theodorus Majofskistraat 100 330 Amsterdam 1065 SZ 331 NL 333 Email: job@ntt.net 335 Keyur Patel 336 Arrcus, Inc 338 Email: keyur@arrcus.com 340 Ignas Bagdonas 341 Equinix 342 London 343 UK 345 Email: ibagdona.ietf@gmail.com 347 Adam Simpson 348 Nokia 349 600 March Road 350 Ottawa Ontario K2K 2E6 351 Canada 353 Email: adam.1.simpson@nokia.com 355 Nick Hilliard 356 INEX 357 4027 Kingswood Road 358 Dublin 24 359 IE 361 Email: nick@inex.ie