idnits 2.17.1 draft-ietf-idr-large-community-09.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 21, 2016) is 2710 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 352 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 25, 2017 NTT 6 K. Patel 7 Arrcus 8 I. Bagdonas 9 Equinix 10 N. Hilliard 11 INEX 12 November 21, 2016 14 BGP Large Communities 15 draft-ietf-idr-large-community-09 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 25, 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 6 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 either be 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 MUST NOT be transmitted. A 159 receiving speaker MUST silently remove duplicate BGP Large Community 160 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 Large Communities attribute SHALL NOT be considered 200 malformed due solely to presence of duplicate community values. 202 o A BGP UPDATE message with a malformed BGP Large Communities 203 attribute SHALL be handled using the approach of "treat-as- 204 withdraw" as described in section 2 [RFC7606]. 206 The BGP Large Communities Global Administrator field MAY contain any 207 value, and a BGP Large Communities attribute MUST NOT be considered 208 malformed if the Global Administrator field contains an unallocated, 209 unassigned or reserved ASN or is set to one of the reserved BGP Large 210 Community values defined in Section 5. 212 7. Security Considerations 214 This extension to BGP has similar security implications as BGP 215 Communities [RFC1997]. 217 This document does not change any underlying security issues 218 associated with any other BGP Communities mechanism. Specifically, 219 an AS relying on the BGP Large Communities attribute carried in BGP 220 must have trust in every other AS in the path, as any intermediate 221 Autonomous System in the path may have added, deleted, or altered the 222 BGP Large Communities attribute. Specifying the mechanism to provide 223 such trust is beyond the scope of this document. 225 BGP Large Communities do not protect the integrity of each community 226 value. Operators should be aware that it is possible for a BGP 227 speaker to alter BGP Large Community Attribute values in a BGP Update 228 Message. Protecting the integrity of the transitive handling of BGP 229 Large Community attributes in a manner consistent with the intent of 230 expressed BGP routing policies falls within the broader scope of 231 securing BGP, and is not specifically addressed here. 233 Network administrators should note the recommendations in Section 11 234 of BGP Operations and Security [RFC7454]. 236 8. Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION 238 This section records the status of known implementations of the 239 protocol defined by this specification at the time of posting of this 240 Internet-Draft, and is based on a proposal described in [RFC7942]. 241 The description of implementations in this section is intended to 242 assist the IETF in its decision processes in progressing drafts to 243 RFCs. Please note that the listing of any individual implementation 244 here does not imply endorsement by the IETF. Furthermore, no effort 245 has been spent to verify the information presented here that was 246 supplied by IETF contributors. This is not intended as, and must not 247 be construed to be, a catalog of available implementations or their 248 features. Readers are advised to note that other implementations may 249 exist. 251 As of today these vendors have produced an implementation of BGP 252 Large Communities: 254 o Cisco IOS XR 256 o ExaBGP 258 o GoBGP 260 o BIRD 262 o OpenBGPD 264 o pmacct 266 o Quagga 268 The latest implementation news is tracked at 269 http://largebgpcommunities.net/ [1]. 271 9. IANA Considerations 273 IANA has made an Early Allocation of the value 32 (LARGE_COMMUNITY) 274 in the "BGP Path Attributes" registry under the "Border Gateway 275 Protocol (BGP) Parameters" group and is now asked to make that 276 Permanent. 278 10. Contributors 280 The following people contributed significantly to the content of the 281 document: 283 John Heasley 284 NTT Communications 285 Email: heas@shrubbery.net 287 Adam Simpson 288 Nokia 289 Email: adam.1.simpson@nokia.com 291 11. Acknowledgments 293 The authors would like to thank Ruediger Volk, Russ White, Acee 294 Lindem, Shyam Sethuram, Jared Mauch, Joel M. Halpern, Jeffrey Haas, 295 Gunter van de Velde, Marco Marzetti, Eduardo Ascenco Reis, Mark 296 Schouten, Paul Hoogsteder, Martijn Schmidt, Greg Hankins, Bertrand 297 Duvivier, Barry O'Donovan, Grzegorz Janoszka, Linda Dunbar, Marco 298 Davids, Gaurab Raj Upadhaya, Jeff Tantsura, Teun Vink, Adam 299 Davenport, Theodore Baschak, Pier Carlo Chiodi, Nabeel Cocker, Ian 300 Dickinson, Jan Baggen, Duncan Lockwood, David Farmer, Randy Bush, Wim 301 Henderickx, Stefan Plug, Kay Rechthien, Rob Shakir, Warren Kumari, 302 Gert Doering, Thomas King, Mikael Abrahamsson, Wesley Steehouwer, 303 Sander Steffann, Brad Dreisbach, Martin Millnert, Christopher Morrow, 304 Jay Borkenhagen, Arnold Nipper, Joe Provo, Niels Bakker, Bill Fenner, 305 Tom Daly, Ben Maddison, Alexander Azimov, Brian Dickson, Peter van 306 Dijk, Julian Seifert, Tom Petch, Tom Scholl, Arjen Zonneveld, Remco 307 van Mook, Adam Chappell, Jussi Peltola, Kristian Larsson, Markus 308 Hauschild, Richard Steenbergen, David Freedman, Richard Hartmann, 309 Geoff Huston and Mach Chen for their support, insightful review and 310 comments. 312 12. References 314 12.1. Normative References 316 [RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities 317 Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996, 318 . 320 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 321 Requirement Levels", BCP 14, RFC 2119, 322 DOI 10.17487/RFC2119, March 1997, 323 . 325 [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet 326 Autonomous System (AS) Number Space", RFC 6793, 327 DOI 10.17487/RFC6793, December 2012, 328 . 330 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 331 Patel, "Revised Error Handling for BGP UPDATE Messages", 332 RFC 7606, DOI 10.17487/RFC7606, August 2015, 333 . 335 12.2. Informative References 337 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 338 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 339 February 2006, . 341 [RFC7454] Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations 342 and Security", BCP 194, RFC 7454, DOI 10.17487/RFC7454, 343 February 2015, . 345 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 346 Code: The Implementation Status Section", BCP 205, 347 RFC 7942, DOI 10.17487/RFC7942, July 2016, 348 . 350 12.3. URIs 352 [1] http://largebgpcommunities.net 354 Authors' Addresses 356 Jakob Heitz (editor) 357 Cisco 358 170 West Tasman Drive 359 San Jose, CA 95054 360 USA 362 Email: jheitz@cisco.com 364 Job Snijders (editor) 365 NTT Communications 366 Theodorus Majofskistraat 100 367 Amsterdam 1065 SZ 368 The Netherlands 370 Email: job@ntt.net 372 Keyur Patel 373 Arrcus, Inc 375 Email: keyur@arrcus.com 376 Ignas Bagdonas 377 Equinix 378 London 379 UK 381 Email: ibagdona.ietf@gmail.com 383 Nick Hilliard 384 INEX 385 4027 Kingswood Road 386 Dublin 24 387 IE 389 Email: nick@inex.ie