idnits 2.17.1 draft-heitz-idr-large-community-04.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 (September 6, 2016) is 2790 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 210 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: March 10, 2017 Arrcus 6 J. Snijders 7 NTT 8 I. Bagdonas 9 Equinix 10 A. Simpson 11 Nokia 12 September 6, 2016 14 Large BGP Community 15 draft-heitz-idr-large-community-04 17 Abstract 19 A new type of BGP community attribute that contains communities that 20 each hold a 4-octet AS number and a 8-octet opaque field is defined. 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 26 document are to be interpreted as described in [RFC2119]. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on March 10, 2017. 45 Copyright Notice 47 Copyright (c) 2016 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Large BGP Community Attribute . . . . . . . . . . . . . . . . 3 64 3. Textual Representation . . . . . . . . . . . . . . . . . . . 3 65 4. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 3 66 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 67 6. Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION 4 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 69 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 70 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 9.1. Normative References . . . . . . . . . . . . . . . . . . 4 72 9.2. Informative References . . . . . . . . . . . . . . . . . 5 73 9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 5 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 76 1. Introduction 78 A Large Community attribute is defined that encodes 12 bytes 79 communities, suitable for 4-Octet Autonomous System Numbers that 80 require 8 octets of locally significant opaque data. 82 The Large Community is specifically designed to accomodate routing 83 policy related to 4-byte ASNs, as it allows operators to specify two 84 4-byte ASNs and still have room for 4 bytes for an action. For 85 example, to make a request to AS65551 to add 3 prepends when sending 86 a route to AS65536, one might add the Large Community 87 65551:303:65536. AS65551 would publish a list of large communities 88 and their associated actions. The Large Community is opaque. 90 To ensure rapid and smooth adoption of the new community attribute, 91 it must be as similar to the [RFC1997] community as possible, only 92 bigger. 94 2. Large BGP Community Attribute 96 The Large Community Attribute is a transitive optional BGP attribute, 97 with the Type Code (suggested 41) to be assigned by IANA. The 98 attribute consists of a set of Large Communities. All routes with 99 the Large Community attribute belong to the communities listed in the 100 attribute. 102 Each Large Community is encoded as a 12-octet quantity, as follows: 104 0 1 2 3 105 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 106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 107 | Autonomous System number | 108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 109 | Local Data Part 1 | 110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 111 | Local Data Part 2 | 112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 114 Autonomous System Number: This field indicates the Autonomous System 115 in which the Large Community has a meaning. 117 Local Data part 1: data set by network operator 119 Local Data part 2: data set by network operator 121 3. Textual Representation 123 The textual representation of the Large Community is A:B:C, where A 124 is the Autonomous System number, B is the Local Data part 1 and C is 125 the Local Data part 2. A ranges from 0 to 4294967295. B ranges from 126 0 to 4294967295. C ranges from 0 to 4294967295. A, B and C are 127 plain decimal non-negative integers without leading zeroes. Each 128 number must appear, even if it is 0. For example, "0:1:2" cannot be 129 written as ":1:2". The string is expected to match the following 130 regular expression: ^[0-9]+:[0-9]+:[0-9]+$ 132 4. Error Handling 134 The error handling of Large Community is as follows: 136 o The Large Community attribute SHALL be considered malformed if its 137 length is not a non-zero multiple of 12 bytes. 139 o An UPDATE message with a malformed Large Community attribute SHALL 140 be handled using the approach of "treat-as-withdraw" as described 141 in section 2 [RFC7606]. 143 5. Security Considerations 145 TBD 147 6. Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION 149 This section records the status of known implementations of the 150 protocol defined by this specification at the time of posting of this 151 Internet-Draft, and is based on a proposal described in [RFC7942]. 152 The description of implementations in this section is intended to 153 assist the IETF in its decision processes in progressing drafts to 154 RFCs. Please note that the listing of any individual implementation 155 here does not imply endorsement by the IETF. Furthermore, no effort 156 has been spent to verify the information presented here that was 157 supplied by IETF contributors. This is not intended as, and must not 158 be construed to be, a catalog of available implementations or their 159 features. Readers are advised to note that other implementations may 160 exist. 162 As of today these vendors have produced an implementation of Large 163 BGP Community: 165 o Cisco IOS XR 167 o ExaBGP 169 The latest implementation news is tracked at 170 http://largebgpcommunities.net/ [1]. 172 7. IANA Considerations 174 IANA is requested to assign a BGP path attribute value for the Large 175 Community attribute (suggested 41). 177 8. Acknowledgements 179 Thanks to Ruediger Volk, Russ White, Acee Lindem, Shyam Sethuram, 180 Jared Mauch, Joel M. Halpern and Nick Hilliard for insightful review 181 and comments. 183 9. References 185 9.1. Normative References 187 [RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities 188 Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996, 189 . 191 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 192 Requirement Levels", BCP 14, RFC 2119, 193 DOI 10.17487/RFC2119, March 1997, 194 . 196 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 197 Patel, "Revised Error Handling for BGP UPDATE Messages", 198 RFC 7606, DOI 10.17487/RFC7606, August 2015, 199 . 201 9.2. Informative References 203 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 204 Code: The Implementation Status Section", BCP 205, 205 RFC 7942, DOI 10.17487/RFC7942, July 2016, 206 . 208 9.3. URIs 210 [1] https://largebgpcommunities.net 212 Authors' Addresses 214 Jakob Heitz 215 Cisco 216 170 West Tasman Drive 217 San Jose, CA 95054 218 USA 220 Email: jheitz@cisco.com 222 Keyur Patel 223 Arrcus, Inc 225 Email: keyur@arrcus.com 227 Job Snijders 228 NTT Communications 229 Theodorus Majofskistraat 100 230 Amsterdam 1065 SZ 231 NL 233 Email: job@ntt.net 234 Ignas Bagdonas 235 Equinix 236 London 237 UK 239 Email: ibagdona.ietf@gmail.com 241 Adam Simpson 242 Nokia 243 600 March Road 244 Ottawa Ontario K2K 2E6 245 Canada 247 Email: adam.1.simpson@nokia.com