idnits 2.17.1 draft-ietf-idr-large-community-00.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC4271], [RFC6793], [RFC1997]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 23, 2016) is 2770 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 292 Summary: 1 error (**), 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: March 27, 2017 Arrcus 6 J. Snijders 7 NTT 8 I. Bagdonas 9 Equinix 10 A. Simpson 11 Nokia 12 September 23, 2016 14 Large BGP Communities 15 draft-ietf-idr-large-community-00 17 Abstract 19 The BGP Communities Attribute [RFC1997] is heavily used by operators, 20 but is inadequate to represent large enough values, particularly 21 Four-octet Autonomous System numbers [RFC6793] plus additional 22 values. This document describes an extension to BGP [RFC4271] to 23 address this need with a new extended form of the BGP community 24 Attribute. 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 March 27, 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 Community Attribute . . . . . . . . . . . . . . . . 3 68 3. Textual Representation . . . . . . . . . . . . . . . . . . . 4 69 4. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 4 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 71 6. Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION 5 72 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 73 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 74 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 75 9.1. Normative References . . . . . . . . . . . . . . . . . . 6 76 9.2. Informative References . . . . . . . . . . . . . . . . . 7 77 9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 7 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 80 1. Introduction 82 BGP implementations typically support a routing policy language (RPL) 83 to control the distribution of routing information. Network 84 operators add BGP communities to routes via the RPL to identify 85 intrinsic differentia of a route such as its origin country or 86 specify a RPL action to be taken, or one that has been taken, on an 87 individual route or group of routes. Because BGP communities are 88 optional transitive BGP attributes, these differentia and actions 89 identified by the communities may be acted upon or otherwise utilized 90 by the RPL in any Autonomous System (AS) in the Internet, often are 91 and often the goal of adding a community is to signal an AS one or 92 more AS-hops away. 94 BGP Communities Attributes are 4-octet values split into two 2-octet 95 values where the most significant word is an Autonomous System number 96 (ASN) and the least significant word is a value whose meaning is 97 defined by operators of that Autonomous System. This operator- 98 defined value is the aforementioned differentia or RPL action. 100 Since the adoption of Four-octet ASNs [RFC6793], the BGP Communities 101 Attribute can no longer accommodate this encoding because it is only 102 large enough to hold the ASN. Some operators have also expressed a 103 need for more than 2-octets of operator-defined values. This has led 104 operators to create obtuse mappings to fit within 2-octets, the use 105 of which are tedious and error prone and still can not accommodate 106 all use-cases. 108 To address this, a Large Community BGP attribute is defined to encode 109 one or more 12-octet values each consisting of a Four-octet 110 Autonomous System Number and two 4 octet operator-defined values for 111 differentia or actions defined by that Autonomous System. 113 2. Large BGP Community Attribute 115 This document creates the Large Communities BGP path attribute as an 116 optional transitive attribute of variable length. All routes with 117 the Large Community attribute belong to the communities in the 118 attribute. 120 The Large COMMUNITIES attribute has Type Code TBD - RFC EDITOR fill- 121 in IANA assigned value. 123 The attribute consists of one or more 12-octet values. Each 12-octet 124 Large Community value represents three 4-octet values, as follows: 126 0 1 2 3 127 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 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 | Autonomous System Number | 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 | Local Data Part 1 | 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 | Local Data Part 2 | 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 Autonomous System Number: The Four-octet ASN of the operator with 137 whom definition of the final two 4-octet values lies. 139 Local Data part 1: 4-octet operator-defined value. 141 Local Data part 2: 4-octet operator-defined value. 143 3. Textual Representation 145 The textual representation of BGP Communities [RFC1997] in RPLs and 146 the networking community is known well as two 2-octet unsigned 147 integers and is often represented as such, separated a colon. For 148 example, 65000:12345 (ASN:differentia). 150 Large Communities MUST be represented similarly, as three 4-octet 151 unsigned integers with no leading zeros. An integer MUST NOT be 152 omitted, even when zero. Implementations MUST represent Large 153 Communities in RPL in a manner consistent with their representation 154 of BGP Communities [RFC1997]. For example, 65000:1:2 (ASN:Local Data 155 Part 1:Local Data Part 2) or 65000:0:0. 157 The following Large BGP Communities textual specification uses the 158 Augmented Backus-Naur Form (ABNF) notation as specified in [RFC5234]. 160 positive-digit = "1" / "2" / "3" / 161 "4" / "5" / "6" / 162 "7" / "8" / "9" 164 digit = "0" / positive-digit 166 non-zero-int = positive-digit *9digit 168 part = "0" / non-zero-int ; max value is 4294967295 170 large-community = part ":" part ":" part 172 Vendors MAY provide other textual representations. 174 4. Error Handling 176 The error handling of Large Community is as follows: 178 o A Large Community BGP Path Attribute with a length of zero MUST be 179 ignored upon receipt and removed when sending. 181 o A Large Community attribute SHALL be considered malformed if its 182 length is not a non-zero multiple of 12 bytes. 184 o A BGP UPDATE message with a malformed Large Community attribute 185 SHALL be handled using the approach of "treat-as-withdraw" as 186 described in section 2 [RFC7606]. 188 5. Security Considerations 190 This extension to BGP has similar security implications as BGP 191 Communities [RFC1997]. 193 underlying security issues. Specifically, an AS relying on the BGP 194 attributes carried in BGP must have trust in every AS in the path to 195 the source of the route, as any AS in the path may have altered or 196 deleted attributes or added false attributes. Specifying the 197 mechanism(s) to provide such trust is beyond the scope of this 198 document. 200 6. Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION 202 This section records the status of known implementations of the 203 protocol defined by this specification at the time of posting of this 204 Internet-Draft, and is based on a proposal described in [RFC7942]. 205 The description of implementations in this section is intended to 206 assist the IETF in its decision processes in progressing drafts to 207 RFCs. Please note that the listing of any individual implementation 208 here does not imply endorsement by the IETF. Furthermore, no effort 209 has been spent to verify the information presented here that was 210 supplied by IETF contributors. This is not intended as, and must not 211 be construed to be, a catalog of available implementations or their 212 features. Readers are advised to note that other implementations may 213 exist. 215 As of today these vendors have produced an implementation of Large 216 BGP Community: 218 o Cisco IOS XR 220 o ExaBGP 222 o GoBGP 224 The latest implementation news is tracked at 225 http://largebgpcommunities.net/ [1]. 227 7. IANA Considerations 229 IANA is requested to assign a BGP path attribute value for the Large 230 Community attribute. 232 8. Acknowledgements 234 The authors would like to thank Ruediger Volk, Russ White, Acee 235 Lindem, Shyam Sethuram, Jared Mauch, Joel M. Halpern, Nick Hilliard, 236 Jeffrey Haas, John Heasley, Gunter van de Velde, Marco Marzetti, 237 Eduardo Ascenco Reis, Mark Schouten, Paul Hoogsteder, Martijn 238 Schmidt, Greg Hankins, Acee Lindem, Bertrand Duvivier, Barry 239 O'Donovan, Grzegorz Janoszka, Linda Dunbar, Marco Davids, Gaurab Raj 240 Upadhaya, Jeff Tantsura, Teun Vink, Adam Davenport, Theodore Baschak, 241 Pier Carlo Chiodi, Nabeel Cocker, Ian Dickinson, Jan Baggen, Duncan 242 Lockwood, David Farmer, Randy Bush, Wim Henderickx, Stefan Plug, Kay 243 Rechthien, Rob Shakir, Warren Kumari, Gert Doering, Thomas King, 244 Mikael Abrahamsson, Wesley Steehouwer, Sander Steffann, Brad 245 Dreisbach, Martin Millnert, Christopher Morrow, Jay Borkenhagen, 246 Arnold Nipper, Joe Provo, Niels Bakker, Bill Fenner, Tom Daly, Ben 247 Maddison, Alexander Azimov, Brian Dickson and Peter van Dijk for 248 their support, insightful review and comments. 250 9. References 252 9.1. Normative References 254 [RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities 255 Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996, 256 . 258 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 259 Requirement Levels", BCP 14, RFC 2119, 260 DOI 10.17487/RFC2119, March 1997, 261 . 263 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 264 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 265 DOI 10.17487/RFC4271, January 2006, 266 . 268 [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet 269 Autonomous System (AS) Number Space", RFC 6793, 270 DOI 10.17487/RFC6793, December 2012, 271 . 273 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 274 Patel, "Revised Error Handling for BGP UPDATE Messages", 275 RFC 7606, DOI 10.17487/RFC7606, August 2015, 276 . 278 9.2. Informative References 280 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 281 Specifications: ABNF", STD 68, RFC 5234, 282 DOI 10.17487/RFC5234, January 2008, 283 . 285 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 286 Code: The Implementation Status Section", BCP 205, 287 RFC 7942, DOI 10.17487/RFC7942, July 2016, 288 . 290 9.3. URIs 292 [1] https://largebgpcommunities.net 294 Authors' Addresses 296 Jakob Heitz 297 Cisco 298 170 West Tasman Drive 299 San Jose, CA 95054 300 USA 302 Email: jheitz@cisco.com 304 Keyur Patel 305 Arrcus, Inc 307 Email: keyur@arrcus.com 309 Job Snijders 310 NTT Communications 311 Theodorus Majofskistraat 100 312 Amsterdam 1065 SZ 313 NL 315 Email: job@ntt.net 317 Ignas Bagdonas 318 Equinix 319 London 320 UK 322 Email: ibagdona.ietf@gmail.com 323 Adam Simpson 324 Nokia 325 600 March Road 326 Ottawa Ontario K2K 2E6 327 Canada 329 Email: adam.1.simpson@nokia.com