idnits 2.17.1 draft-ietf-idr-large-community-06.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 (October 30, 2016) is 2735 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 339 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 3, 2017 NTT 6 K. Patel 7 Arrcus 8 I. Bagdonas 9 Equinix 10 A. Simpson 11 Nokia 12 N. Hilliard 13 INEX 14 October 30, 2016 16 Large BGP Communities 17 draft-ietf-idr-large-community-06 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 with 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 May 3, 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. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 6 76 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 77 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 78 12.1. Normative References . . . . . . . . . . . . . . . . . . 7 79 12.2. Informative References . . . . . . . . . . . . . . . . . 7 80 12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 8 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 83 1. Introduction 85 BGP implementations typically support a routing policy language to 86 control the distribution of routing information. Network operators 87 attach BGP communities to routes to identify intrinsic properties of 88 these routes. These properties may include information such as the 89 route origin location, or specification of a routing policy action to 90 be taken, or one that has been taken, and may apply to an individual 91 route or to a group of routes. 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 [RFC1997] BGP Communities attributes are four-octet values split into 97 two two-octet words. The most significant word is interpreted as an 98 Autonomous System Number (ASN) and the least significant word is a 99 locally defined value whose meaning is assigned by the operator of 100 the Autonomous System in the most significant 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 Global Administrator field and two 114 four-octet operator-defined fields, each of which can be used to 115 denote properties or actions significant to the operator of the 116 Autonomous System assigning the values. 118 2. Large BGP Communities Attribute 120 This document creates the Large BGP Communities attribute as an 121 optional transitive path attribute of variable length. All routes 122 with the Large BGP Communities attribute belong to the community 123 specified in the attribute. 125 The attribute consists of one or more twelve-octet values. Each 126 twelve-octet Large BGP Communities value represents three four-octet 127 values, as follows: 129 0 1 2 3 130 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 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 | Global Administrator | 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 | Local Data Part 1 | 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 | Local Data Part 2 | 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 Global Administrator: A four-octet namespace identifier. This 140 SHOULD be an Autonomous System Number. 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 Large BGP Communities without collision. 148 Implementations MUST allow the operator to specify any value for the 149 Global Administrator field. 151 There is no significance to the order in which Large BGP Communities 152 are encoded in the BGP path attribute payload. A BGP speaker can 153 transmit them in any order. 155 Duplicate Large BGP Communities SHOULD NOT be transmitted. A 156 receiving speaker SHOULD silently remove duplicate Large BGP 157 Communities from a BGP UPDATE message. 159 3. Aggregation 161 If a range of routes is aggregated, then the resulting aggregate 162 should have a Large BGP Communities attribute which contains all of 163 the Large BGP Communities attributes from all of the aggregated 164 routes. 166 4. Canonical Representation 168 Large BGP Communities MUST be represented as three separate unsigned 169 integers in decimal notation in the following order: Global 170 Administrator, Local Data 1, Local Data 2. Numbers MUST NOT contain 171 leading zeros; a zero value MUST be represented with a single zero. 172 For example: 64496:4294967295:2, 64496:0:0, or (64496, 111, 222). 174 5. Reserved Large BGP Community values 176 The following Global Administrator values are reserved: 0 (the first 177 ASN) [RFC7607], 65535 (UINT16_MAX) and 4294967295 (the last ASN) 178 [RFC7300]. Operators SHOULD NOT use these Global Administrator 179 values. 181 Although this document does not define any Special-Use Large BGP 182 Communities, the Global Administrator values specified above could be 183 used if there is a future need for them. 185 6. Error Handling 187 The error handling of Large BGP Communities is as follows: 189 o A Large BGP Communities attribute SHALL be considered malformed if 190 its length is not a non-zero multiple of 12. 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 o Quagga 249 The latest implementation news is tracked at 250 http://largebgpcommunities.net/ [1]. 252 9. IANA Considerations 254 IANA has made an Early Allocation of the value 32 (LARGE_COMMUNITY) 255 in the "BGP Path Attributes" registry under the "Border Gateway 256 Protocol (BGP) Parameters" group and is now asked to make that 257 Permanent. 259 10. Contributors 261 The following people contributed significantly to the content of the 262 document: 264 John Heasley 265 NTT Communications 267 Email: heas@shrubbery.net 269 11. Acknowledgments 271 The authors would like to thank Ruediger Volk, Russ White, Acee 272 Lindem, Shyam Sethuram, Jared Mauch, Joel M. Halpern, Jeffrey Haas, 273 Gunter van de Velde, Marco Marzetti, Eduardo Ascenco Reis, Mark 274 Schouten, Paul Hoogsteder, Martijn Schmidt, Greg Hankins, Bertrand 275 Duvivier, Barry O'Donovan, Grzegorz Janoszka, Linda Dunbar, Marco 276 Davids, Gaurab Raj Upadhaya, Jeff Tantsura, Teun Vink, Adam 277 Davenport, Theodore Baschak, Pier Carlo Chiodi, Nabeel Cocker, Ian 278 Dickinson, Jan Baggen, Duncan Lockwood, David Farmer, Randy Bush, Wim 279 Henderickx, Stefan Plug, Kay Rechthien, Rob Shakir, Warren Kumari, 280 Gert Doering, Thomas King, Mikael Abrahamsson, Wesley Steehouwer, 281 Sander Steffann, Brad Dreisbach, Martin Millnert, Christopher Morrow, 282 Jay Borkenhagen, Arnold Nipper, Joe Provo, Niels Bakker, Bill Fenner, 283 Tom Daly, Ben Maddison, Alexander Azimov, Brian Dickson, Peter van 284 Dijk, Julian Seifert, Tom Petch, Tom Scholl, Arjen Zonneveld, Remco 285 van Mook, Adam Chappell, Jussi Peltola, Kristian Larsson, Markus 286 Hauschild, Richard Steenbergen, David Freedman, Richard Hartmann for 287 their support, insightful review and comments. 289 12. References 291 12.1. Normative References 293 [RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities 294 Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996, 295 . 297 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 298 Requirement Levels", BCP 14, RFC 2119, 299 DOI 10.17487/RFC2119, March 1997, 300 . 302 [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet 303 Autonomous System (AS) Number Space", RFC 6793, 304 DOI 10.17487/RFC6793, December 2012, 305 . 307 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 308 Patel, "Revised Error Handling for BGP UPDATE Messages", 309 RFC 7606, DOI 10.17487/RFC7606, August 2015, 310 . 312 12.2. Informative References 314 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 315 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 316 February 2006, . 318 [RFC7300] Haas, J. and J. Mitchell, "Reservation of Last Autonomous 319 System (AS) Numbers", BCP 6, RFC 7300, 320 DOI 10.17487/RFC7300, July 2014, 321 . 323 [RFC7454] Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations 324 and Security", BCP 194, RFC 7454, DOI 10.17487/RFC7454, 325 February 2015, . 327 [RFC7607] Kumari, W., Bush, R., Schiller, H., and K. Patel, 328 "Codification of AS 0 Processing", RFC 7607, 329 DOI 10.17487/RFC7607, August 2015, 330 . 332 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 333 Code: The Implementation Status Section", BCP 205, 334 RFC 7942, DOI 10.17487/RFC7942, July 2016, 335 . 337 12.3. URIs 339 [1] http://largebgpcommunities.net 341 Authors' Addresses 343 Jakob Heitz (editor) 344 Cisco 345 170 West Tasman Drive 346 San Jose, CA 95054 347 USA 349 Email: jheitz@cisco.com 351 Job Snijders (editor) 352 NTT Communications 353 Theodorus Majofskistraat 100 354 Amsterdam 1065 SZ 355 The Netherlands 357 Email: job@ntt.net 359 Keyur Patel 360 Arrcus, Inc 362 Email: keyur@arrcus.com 364 Ignas Bagdonas 365 Equinix 366 London 367 UK 369 Email: ibagdona.ietf@gmail.com 370 Adam Simpson 371 Nokia 372 600 March Road 373 Ottawa Ontario K2K 2E6 374 Canada 376 Email: adam.1.simpson@nokia.com 378 Nick Hilliard 379 INEX 380 4027 Kingswood Road 381 Dublin 24 382 IE 384 Email: nick@inex.ie