idnits 2.17.1 draft-ietf-idr-large-community-02.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 8, 2016) is 2756 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 323 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 3 Internet-Draft Cisco 4 Intended status: Standards Track K. Patel 5 Expires: April 11, 2017 Arrcus 6 J. Snijders 7 NTT 8 I. Bagdonas 9 Equinix 10 A. Simpson 11 Nokia 12 October 8, 2016 14 Large BGP Communities 15 draft-ietf-idr-large-community-02 17 Abstract 19 This document describes the Large BGP Community 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 in 4-octet ASNs. 24 Requirements Language 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 27 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 28 document are to be interpreted as described in [RFC2119]. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on April 11, 2017. 47 Copyright Notice 49 Copyright (c) 2016 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. Large BGP Communities Attribute . . . . . . . . . . . . . . . 3 66 3. Aggregation . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 4. Textual Representation . . . . . . . . . . . . . . . . . . . 4 68 5. Reserved Large BGP Community values . . . . . . . . . . . . . 4 69 6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 5 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 71 8. Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION 5 72 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 73 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 74 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 75 11.1. Normative References . . . . . . . . . . . . . . . . . . 7 76 11.2. Informative References . . . . . . . . . . . . . . . . . 7 77 11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 7 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 80 1. Introduction 82 BGP implementations typically support a routing policy language to 83 control the distribution of routing information. Network operators 84 attach BGP communities to routes to identify intrinsic properties of 85 these routes. These properties may include information such as the 86 route origin location, or specification of a routing policy action to 87 be taken, or one that has been taken, and may apply to an individual 88 route or to a group of routes. Because BGP communities are optional 89 transitive BGP attributes, BGP communities may be acted upon or 90 otherwise used by routing policies in other Autonomous Systems (ASes) 91 on the Internet. 93 [RFC1997] BGP Communities Attributes are four-octet values split into 94 two individual two-octet words. The most significant word is usually 95 interpreted as an Autonomous System Number (ASN) and the least 96 significant word is a locally defined value whose meaning is assigned 97 by the operator of the Autonomous System in the most significant 98 word. 100 Since the adoption of four-octet ASNs [RFC6793], the BGP Communities 101 Attribute can no longer accommodate this encoding, as the 102 specification in [RFC1997] contains only four octets. This does not 103 allow operators to specify any locally significant values. 105 To address these shortcomings, this document defines a Large 106 Community BGP Attribute encoded as one or more 12-octet values, each 107 consisting of a four-octet ASN and two four-octet operator-defined 108 values, each of which can be used to denote properties or actions 109 significant to that ASN. 111 2. Large BGP Communities Attribute 113 This document creates the Large Communities BGP path attribute as an 114 optional transitive attribute of variable length. All routes with 115 the Large Communities attribute belong to the community specified in 116 the attribute. 118 The attribute consists of one or more 12-octet values. Each 12-octet 119 Large Communities value represents three 4-octet values, as follows: 121 0 1 2 3 122 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 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 124 | Global Administrator | 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126 | Local Data Part 1 | 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 128 | Local Data Part 2 | 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 Global Administrator: A four-octet namespace identifier. This 132 SHOULD be an Autonomous System Number. 134 Local Data Part 1: A four-octet operator-defined value. 136 Local Data Part 2: A four-octet operator-defined value. 138 The Global Administrator field is intended to allow different 139 Autonomous Systems to define Large Communities without collision. 140 Implementations MUST allow the operator to specify any value for the 141 Global Administrator field. 143 There is no significance to the order in which Large Communities are 144 encoded in a path attributes field and a receiving speaker MAY 145 retransmit them in an order different from which it received them. 147 Duplicate Large Communities SHOULD NOT be transmitted. A receiving 148 speaker SHOULD silently remove duplicate Large Communities from a BGP 149 UPDATE message. 151 3. Aggregation 153 If a range of routes is aggregated and the resulting aggregates 154 attribute section does not carry the ATOMIC_AGGREGATE attribute, then 155 the resulting aggregate should have a Large Communities path 156 attribute which contains all of the large communities from all of the 157 aggregated routes. 159 4. Textual Representation 161 BGP Communities [RFC1998] are usually represented in routing policy 162 languages as two individual two-octet unsigned integers separated by 163 a colon; for example, 64496:12345. 165 BGP Large Communities implementations MUST represent Large 166 Communities in a manner similar to their representation of BGP 167 Communities [RFC1998]. Large Communities MUST be represented as 168 three separate four-octet unsigned integers in decimal format with no 169 leading zeros. These integers MUST NOT be omitted, even when zero. 170 For example, 64496:4294967295:2 or 64496:0:0. 172 Vendors MAY provide other textual representations. For example, a 173 vendor's routing policy language may use a separator other than a 174 colon or may require keywords or characters prepending or postpending 175 the Large Communities attribute. Such differences are permitted. 176 However, each implementation MUST make a representation available 177 that depicts the integers in decimal and in the following order: 178 Global Administrator, Local Data Part 1, Local Data Part 2. 180 5. Reserved Large BGP Community values 182 The Large BGP Community attribute values in the following ranges are 183 reserved: 185 0:0:0 - 0:4294967295:4294967295 186 65535:0:0 - 65535:4294967295:4294967295 187 4294967295:0:0 - 4294967295:4294967295:4294967295 189 6. Error Handling 191 The error handling of Large Communities is as follows: 193 o A Large Communities BGP Path Attribute with a length of zero MUST 194 be ignored upon receipt and removed when sending. 196 o A Large Communities attribute SHALL be considered malformed if its 197 length is not a non-zero multiple of 12 bytes. 199 o A BGP UPDATE message with a malformed Large Communities attribute 200 SHALL be handled using the approach of "treat-as-withdraw" as 201 described in section 2 [RFC7606]. 203 The BGP Large Communities Global Administrator field may contain any 204 value, and a 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 Large BGP 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 Large BGP Community 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 Large BGP Community attribute. Specifying the mechanism to provide 220 such trust is beyond the scope of this document. 222 Network administrators should note the recommendations in Section 11 223 of BGP Operations and Security [RFC7454]. 225 8. Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION 227 This section records the status of known implementations of the 228 protocol defined by this specification at the time of posting of this 229 Internet-Draft, and is based on a proposal described in [RFC7942]. 230 The description of implementations in this section is intended to 231 assist the IETF in its decision processes in progressing drafts to 232 RFCs. Please note that the listing of any individual implementation 233 here does not imply endorsement by the IETF. Furthermore, no effort 234 has been spent to verify the information presented here that was 235 supplied by IETF contributors. This is not intended as, and must not 236 be construed to be, a catalog of available implementations or their 237 features. Readers are advised to note that other implementations may 238 exist. 240 As of today these vendors have produced an implementation of Large 241 BGP Community: 243 o Cisco IOS XR 245 o ExaBGP 247 o GoBGP 249 o BIRD 251 o OpenBGPD 253 The latest implementation news is tracked at 254 http://largebgpcommunities.net/ [1]. 256 9. IANA Considerations 258 IANA has made an Early Allocation of the value 30 (LARGE_COMMUNITY) 259 in the "BGP Path Attributes" registry under the "Border Gateway 260 Protocol (BGP) Parameters" group and is now asked to make that 261 Permanent. 263 10. Acknowledgments 265 The authors would like to thank Ruediger Volk, Russ White, Acee 266 Lindem, Shyam Sethuram, Jared Mauch, Joel M. Halpern, Nick Hilliard, 267 Jeffrey Haas, John Heasley, Gunter van de Velde, Marco Marzetti, 268 Eduardo Ascenco Reis, Mark Schouten, Paul Hoogsteder, Martijn 269 Schmidt, Greg Hankins, Acee Lindem, Bertrand Duvivier, Barry 270 O'Donovan, Grzegorz Janoszka, Linda Dunbar, Marco Davids, Gaurab Raj 271 Upadhaya, Jeff Tantsura, Teun Vink, Adam Davenport, Theodore Baschak, 272 Pier Carlo Chiodi, Nabeel Cocker, Ian Dickinson, Jan Baggen, Duncan 273 Lockwood, David Farmer, Randy Bush, Wim Henderickx, Stefan Plug, Kay 274 Rechthien, Rob Shakir, Warren Kumari, Gert Doering, Thomas King, 275 Mikael Abrahamsson, Wesley Steehouwer, Sander Steffann, Brad 276 Dreisbach, Martin Millnert, Christopher Morrow, Jay Borkenhagen, 277 Arnold Nipper, Joe Provo, Niels Bakker, Bill Fenner, Tom Daly, Ben 278 Maddison, Alexander Azimov, Brian Dickson, Peter van Dijk, Julian 279 Seifert, Tom Petch and Tom Scholl for their support, insightful 280 review and comments. 282 11. References 284 11.1. Normative References 286 [RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities 287 Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996, 288 . 290 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 291 Requirement Levels", BCP 14, RFC 2119, 292 DOI 10.17487/RFC2119, March 1997, 293 . 295 [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet 296 Autonomous System (AS) Number Space", RFC 6793, 297 DOI 10.17487/RFC6793, December 2012, 298 . 300 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 301 Patel, "Revised Error Handling for BGP UPDATE Messages", 302 RFC 7606, DOI 10.17487/RFC7606, August 2015, 303 . 305 11.2. Informative References 307 [RFC1998] Chen, E. and T. Bates, "An Application of the BGP 308 Community Attribute in Multi-home Routing", RFC 1998, 309 DOI 10.17487/RFC1998, August 1996, 310 . 312 [RFC7454] Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations 313 and Security", BCP 194, RFC 7454, DOI 10.17487/RFC7454, 314 February 2015, . 316 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 317 Code: The Implementation Status Section", BCP 205, 318 RFC 7942, DOI 10.17487/RFC7942, July 2016, 319 . 321 11.3. URIs 323 [1] https://largebgpcommunities.net 325 Authors' Addresses 326 Jakob Heitz 327 Cisco 328 170 West Tasman Drive 329 San Jose, CA 95054 330 USA 332 Email: jheitz@cisco.com 334 Keyur Patel 335 Arrcus, Inc 337 Email: keyur@arrcus.com 339 Job Snijders 340 NTT Communications 341 Theodorus Majofskistraat 100 342 Amsterdam 1065 SZ 343 NL 345 Email: job@ntt.net 347 Ignas Bagdonas 348 Equinix 349 London 350 UK 352 Email: ibagdona.ietf@gmail.com 354 Adam Simpson 355 Nokia 356 600 March Road 357 Ottawa Ontario K2K 2E6 358 Canada 360 Email: adam.1.simpson@nokia.com