idnits 2.17.1 draft-ietf-idr-large-community-07.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 (November 13, 2016) is 2721 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 349 Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 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: May 17, 2017 NTT 6 K. Patel 7 Arrcus 8 I. Bagdonas 9 Equinix 10 N. Hilliard 11 INEX 12 November 13, 2016 14 BGP Large Communities 15 draft-ietf-idr-large-community-07 17 Abstract 19 This document describes the BGP Large Communities attribute, an 20 extension to BGP-4. This attribute provides a mechanism to signal 21 opaque information within separate namespaces to aid in routing 22 management. The attribute is suitable for use with four-octet 23 Autonomous System Numbers. 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 29 document are to be interpreted as described in [RFC2119]. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on May 17, 2017. 48 Copyright Notice 50 Copyright (c) 2016 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. BGP Large Communities Attribute . . . . . . . . . . . . . . . 3 67 3. Aggregation . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 4. Canonical Representation . . . . . . . . . . . . . . . . . . 4 69 5. Reserved BGP Large Community values . . . . . . . . . . . . . 4 70 6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 5 71 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 72 8. Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION 5 73 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 74 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 6 75 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 76 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 77 12.1. Normative References . . . . . . . . . . . . . . . . . . 7 78 12.2. Informative References . . . . . . . . . . . . . . . . . 8 79 12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 8 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 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 associate particular properties 87 with these routes. These properties may include information such as 88 the route origin location, or specification of a routing policy 89 action to be taken, or one that has been taken, and is applied to all 90 routes contained in a BGP Update Message where the Communities 91 Attribute is included. Because BGP communities are optional 92 transitive BGP attributes, BGP communities may be acted upon or 93 otherwise used by routing policies in other Autonomous Systems (ASes) 94 on the Internet. 96 BGP Communities attributes are a variable length attribute consisting 97 of a set of one or more four-octet values, each of which specify a 98 community [RFC1997]. Common use of the individual values of this 99 attribute type split this single 32-bit value into two 16-bit values. 100 The most significant word is interpreted as an Autonomous System 101 Number (ASN) and the least significant word is a locally defined 102 value whose meaning is assigned by the operator of the Autonomous 103 System in the most significant word. 105 Since the adoption of four-octet ASNs [RFC6793], the BGP Communities 106 attribute can no longer accommodate the above encoding, as a two- 107 octet word cannot fit a four-octet ASN. The BGP Extended Communities 108 attribute [RFC4360] is also unsuitable. The six-octet length of the 109 Extended Community value precludes the common operational practise of 110 encoding four-octet ASNs in both the Global Administrator and the 111 Local Administrator sub-fields. 113 To address these shortcomings, this document defines a BGP Large 114 Communities attribute encoded as an unordered set of one or more 115 twelve-octet values, each consisting of a four-octet Global 116 Administrator field and two four-octet operator-defined fields, each 117 of which can be used to denote properties or actions significant to 118 the operator of the Autonomous System assigning the values. 120 2. BGP Large Communities Attribute 122 This document defines the BGP Large Communities attribute as an 123 optional transitive path attribute of variable length. All routes 124 with the BGP Large Communities attribute belong to the communities 125 specified in the attribute. 127 Each BGP Large Community value is encoded as a 12-octet quantity, as 128 follows: 130 0 1 2 3 131 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 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 | Global Administrator | 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 | Local Data Part 1 | 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 | Local Data Part 2 | 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 Global Administrator: A four-octet namespace identifier. 142 Local Data Part 1: A four-octet operator-defined value. 144 Local Data Part 2: A four-octet operator-defined value. 146 The Global Administrator field is intended to allow different 147 Autonomous Systems to define BGP Large Communities without collision. 148 This field SHOULD be either one of the reserved values as defined 149 below, or an Autonomous System Number (ASN). If it is a reserved 150 value, then the Local Data Parts are as defined by the reserved 151 value. If it is an ASN then the Local Data Parts are to be 152 interpreted as defined by the owner of the ASN. 154 There is no significance to the order in which twelve-octet Large 155 Community Attribute values are encoded in a Large Communities 156 attribute, A BGP speaker can transmit them in any order. 158 Duplicate BGP Large Community values SHOULD NOT be transmitted. A 159 receiving speaker SHOULD silently remove duplicate BGP Large 160 Community values from a BGP Large Community attribute. 162 3. Aggregation 164 If a range of routes is aggregated, then the resulting aggregate 165 should have a BGP Large Communities attribute which contains all of 166 the BGP Large Communities attributes from all of the aggregated 167 routes. 169 4. Canonical Representation 171 The canonical representation of BGP Large Communities is three 172 separate unsigned integers in decimal notation in the following 173 order: Global Administrator, Local Data 1, Local Data 2. Numbers 174 MUST NOT contain leading zeros; a zero value MUST be represented with 175 a single zero. Each number is separated from the next by a single 176 colon. For example: 64496:4294967295:2, 64496:0:0. 178 BGP Large Communities SHOULD be represented in the canonical 179 representation. 181 5. Reserved BGP Large Community values 183 The following Global Administrator values are reserved: 0, 65535, and 184 4294967295. Operators SHOULD NOT use these Global Administrator 185 values. 187 Although this document does not define any Special-Use BGP Large 188 Communities, the Global Administrator values specified above could be 189 used if there is a future need for them. 191 6. Error Handling 193 The error handling of BGP Large Communities is as follows: 195 o A BGP Large Communities attribute SHALL be considered malformed if 196 the length of the BGP Large Communities Attribute value, expressed 197 in octets, is not a non-zero multiple of 12. 199 o A BGP UPDATE message with a malformed BGP Large Communities 200 attribute SHALL be handled using the approach of "treat-as- 201 withdraw" as described in section 2 [RFC7606]. 203 The BGP Large Communities Global Administrator field MAY contain any 204 value, and a BGP Large Communities attribute MUST NOT be considered 205 malformed if the Global Administrator field contains an unallocated, 206 unassigned or reserved ASN or is set to one of the reserved BGP Large 207 Community values defined in Section 5. 209 7. Security Considerations 211 This extension to BGP has similar security implications as BGP 212 Communities [RFC1997]. 214 This document does not change any underlying security issues 215 associated with any other BGP Communities mechanism. Specifically, 216 an AS relying on the BGP Large Communities attribute carried in BGP 217 must have trust in every other AS in the path, as any intermediate 218 Autonomous System in the path may have added, deleted, or altered the 219 BGP Large Communities attribute. Specifying the mechanism to provide 220 such trust is beyond the scope of this document. 222 BGP Large Communities do not protect the integrity of each community 223 value. Operators should be aware that it is possible for a BGP 224 speaker to alter BGP Large Community Attribute values in a BGP Update 225 Message. Protecting the integrity of the transitive handling of BGP 226 Large Community attributes in a manner consistent with the intent of 227 expressed BGP routing policies falls within the broader scope of 228 securing BGP, and is not specifically addressed here. 230 Network administrators should note the recommendations in Section 11 231 of BGP Operations and Security [RFC7454]. 233 8. Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION 235 This section records the status of known implementations of the 236 protocol defined by this specification at the time of posting of this 237 Internet-Draft, and is based on a proposal described in [RFC7942]. 238 The description of implementations in this section is intended to 239 assist the IETF in its decision processes in progressing drafts to 240 RFCs. Please note that the listing of any individual implementation 241 here does not imply endorsement by the IETF. Furthermore, no effort 242 has been spent to verify the information presented here that was 243 supplied by IETF contributors. This is not intended as, and must not 244 be construed to be, a catalog of available implementations or their 245 features. Readers are advised to note that other implementations may 246 exist. 248 As of today these vendors have produced an implementation of BGP 249 Large Communities: 251 o Cisco IOS XR 253 o ExaBGP 255 o GoBGP 257 o BIRD 259 o OpenBGPD 261 o pmacct 263 o Quagga 265 The latest implementation news is tracked at 266 http://largebgpcommunities.net/ [1]. 268 9. IANA Considerations 270 IANA has made an Early Allocation of the value 32 (LARGE_COMMUNITY) 271 in the "BGP Path Attributes" registry under the "Border Gateway 272 Protocol (BGP) Parameters" group and is now asked to make that 273 Permanent. 275 10. Contributors 277 The following people contributed significantly to the content of the 278 document: 280 John Heasley 281 NTT Communications 282 Email: heas@shrubbery.net 284 Adam Simpson 285 Nokia 286 Email: adam.1.simpson@nokia.com 288 11. Acknowledgments 290 The authors would like to thank Ruediger Volk, Russ White, Acee 291 Lindem, Shyam Sethuram, Jared Mauch, Joel M. Halpern, Jeffrey Haas, 292 Gunter van de Velde, Marco Marzetti, Eduardo Ascenco Reis, Mark 293 Schouten, Paul Hoogsteder, Martijn Schmidt, Greg Hankins, Bertrand 294 Duvivier, Barry O'Donovan, Grzegorz Janoszka, Linda Dunbar, Marco 295 Davids, Gaurab Raj Upadhaya, Jeff Tantsura, Teun Vink, Adam 296 Davenport, Theodore Baschak, Pier Carlo Chiodi, Nabeel Cocker, Ian 297 Dickinson, Jan Baggen, Duncan Lockwood, David Farmer, Randy Bush, Wim 298 Henderickx, Stefan Plug, Kay Rechthien, Rob Shakir, Warren Kumari, 299 Gert Doering, Thomas King, Mikael Abrahamsson, Wesley Steehouwer, 300 Sander Steffann, Brad Dreisbach, Martin Millnert, Christopher Morrow, 301 Jay Borkenhagen, Arnold Nipper, Joe Provo, Niels Bakker, Bill Fenner, 302 Tom Daly, Ben Maddison, Alexander Azimov, Brian Dickson, Peter van 303 Dijk, Julian Seifert, Tom Petch, Tom Scholl, Arjen Zonneveld, Remco 304 van Mook, Adam Chappell, Jussi Peltola, Kristian Larsson, Markus 305 Hauschild, Richard Steenbergen, David Freedman, Richard Hartmann, 306 Geoff Huston and Mach Chen for their support, insightful review and 307 comments. 309 12. References 311 12.1. Normative References 313 [RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities 314 Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996, 315 . 317 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 318 Requirement Levels", BCP 14, RFC 2119, 319 DOI 10.17487/RFC2119, March 1997, 320 . 322 [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet 323 Autonomous System (AS) Number Space", RFC 6793, 324 DOI 10.17487/RFC6793, December 2012, 325 . 327 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 328 Patel, "Revised Error Handling for BGP UPDATE Messages", 329 RFC 7606, DOI 10.17487/RFC7606, August 2015, 330 . 332 12.2. Informative References 334 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 335 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 336 February 2006, . 338 [RFC7454] Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations 339 and Security", BCP 194, RFC 7454, DOI 10.17487/RFC7454, 340 February 2015, . 342 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 343 Code: The Implementation Status Section", BCP 205, 344 RFC 7942, DOI 10.17487/RFC7942, July 2016, 345 . 347 12.3. URIs 349 [1] http://largebgpcommunities.net 351 Authors' Addresses 353 Jakob Heitz (editor) 354 Cisco 355 170 West Tasman Drive 356 San Jose, CA 95054 357 USA 359 Email: jheitz@cisco.com 361 Job Snijders (editor) 362 NTT Communications 363 Theodorus Majofskistraat 100 364 Amsterdam 1065 SZ 365 The Netherlands 367 Email: job@ntt.net 369 Keyur Patel 370 Arrcus, Inc 372 Email: keyur@arrcus.com 373 Ignas Bagdonas 374 Equinix 375 London 376 UK 378 Email: ibagdona.ietf@gmail.com 380 Nick Hilliard 381 INEX 382 4027 Kingswood Road 383 Dublin 24 384 IE 386 Email: nick@inex.ie