idnits 2.17.1 draft-heitz-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 : ---------------------------------------------------------------------------- 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 (July 5, 2016) is 2851 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) == Outdated reference: A later version (-10) exists of draft-ietf-idr-as4octet-extcomm-generic-subtype-08 ** Obsolete normative reference: RFC 4893 (Obsoleted by RFC 6793) == Outdated reference: A later version (-07) exists of draft-ietf-idr-link-bandwidth-06 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR J. Heitz 3 Internet-Draft K. Patel 4 Intended status: Standards Track Cisco 5 Expires: January 6, 2017 J. Snijders 6 NTT 7 I. Bagdonas 8 Equinix 9 July 5, 2016 11 Large BGP Community 12 draft-heitz-idr-large-community-00 14 Abstract 16 A new type of BGP community attribute that contains communities that 17 each hold a 4-octet AS number and a 6-octet opaque field is defined. 19 Requirements Language 21 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 22 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 23 document are to be interpreted as described in [RFC2119]. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on January 6, 2017. 42 Copyright Notice 44 Copyright (c) 2016 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Large BGP Community Attribute . . . . . . . . . . . . . . . . 2 61 3. 4-Octet AS Specific Large Community . . . . . . . . . . . . . 4 62 3.1. Textual Representation . . . . . . . . . . . . . . . . . 5 63 4. Compatibility with Extended Communities . . . . . . . . . . . 5 64 5. Large Regular Communities . . . . . . . . . . . . . . . . . . 6 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 67 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 68 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 70 9.2. Informative References . . . . . . . . . . . . . . . . . 8 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 73 1. Introduction 75 A BGP Community attribute is defined that encodes 12 byte 76 communities, suitable for 4-Octet Autonomous System Numbers that 77 require a 6-Octet Local Administrator field. 79 The 2-octet AS Specific Extended Community defined in [RFC4360] has 80 been widely used. 4-octet AS numbers as defined by [RFC4893] are 81 unable to make use of this popular extended community. Subsequently, 82 [RFC5668] defined a 4-octet AS Specific Extended community. However, 83 to make room for the extra 2 octets of AS number, the Local 84 Administrator field was shrunk from 4 octets to 2. This document 85 defines a community to extend that to 6 octets. 87 To ensure rapid and smooth adoption of the new community attribute, 88 it must be as similar to the extended community as possible, only 89 bigger. 91 2. Large BGP Community Attribute 93 The Large Community Attribute is a transitive optional BGP attribute, 94 with the Type Code (suggested 41) to be assigned by IANA. The 95 attribute consists of a set of "Large Communities". All routes with 96 the Large Community attribute belong to the communities listed in the 97 attribute. 99 Each Large Community is encoded as a 12-octet quantity, as follows: 101 0 1 2 3 102 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 103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 104 |I| T | Type | Sub-Type | | 105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value + 106 | | 107 + + 108 | | 109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 111 The fields are as shown below: 113 I - IANA authority bit 115 Value 0: IANA-assignable type using the "First Come First 116 Serve" policy 118 Value 1: Part of this Type Field space is for IANA 119 assignable types using either the Standard Action or 120 the Early IANA Allocation policy. The rest of this 121 Type Field space is for Experimental use. 123 T - Transitivity field 125 Value 0: The community is transitive across all ASes. 127 Value 1: The community is transitive across AS boundaries, 128 but not across an administration boundary. An 129 administration in this sense is an arbitrary set of 130 connected ASes, possibly owned by a single 131 administration. How such an administration boundary 132 is determined is out of scope of this document. 134 Value 2: The community is transitive across Confederation 135 member AS boundaries, but not across a confederation 136 boundary or across an AS boundary that does not use 137 confederations. 139 Value 3: The community is not transitive across any AS 140 boundary, including Confederation Member AS. 142 Type - 5 bits describing how the value field is divided. One 143 type, the 4-Octet AS Specific Large Community is described 144 in this document. 146 Sub-type - describes the meaning of the value field. 148 Value - The actual information according to the sub-type. 150 The Transitivity field is only a hint to BGP speakers that do not 151 implement or understand the specific community. In some cases it 152 makes sense to send a community across one boundary but not the next. 153 An example is the Link Bandwidth Extended Community. 155 The Transitivity field is not implicitly associated with the Type and 156 Sub-Type fields the way they are in Extended Communities. The 157 Transitivity field should be set by the originator based upon 158 individual circumstances at the originator 160 3. 4-Octet AS Specific Large Community 162 This is a Large Community type with a Value field comprising 10 163 octets. 165 0 1 2 3 166 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 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 |0| T | 0| Sub-Type | Local Administrator 2 | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | Local Administrator 1 | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | Global Administrator | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 The definition of each sub-type should specify how to set the T 176 field. The Type field is 0. The Sub-Type is to be assigned by IANA 177 for individual functions. 179 The Value field consists of 2 sub-fields: 181 Global Administrator sub-field: 4 octets 183 This sub-field contains a 4-octet Autonomous System number 184 assigned by IANA. 186 Local Administrator 1 sub-field: 4 octets 188 Local Administrator 2 sub-field: 2 octets 189 The organization identified by the Autonomous System number in 190 the Global Administrator sub-field can encode any information 191 in these sub-fields. The format and meaning of the value 192 encoded in these sub-fields should be defined by the sub-type 193 of the community. 195 3.1. Textual Representation 197 The textual representation of the 4-Octet AS Specific Large Community 198 is A:B:C, where A is the Global Administrator, B is the Local 199 Administrator 1 and C is the Local Administrator 2. A ranges from 0 200 to 4294967295. B ranges from 0 to 4294967295. C ranges from 0 to 201 65535. A, B and C are plain decimal numbers without leading zeroes. 202 Each number must appear, even if it is 0. For example, "0:1:2" 203 cannot be written as ":1:2". 205 4. Compatibility with Extended Communities 207 Any 2-octet AS Specific Extended Community [RFC4360] can be converted 208 into a 4-octet AS Specific Large Community by copying: 210 o bits 1 and 2 of the Type into the Transitivity, and 212 o the Sub-Type unchanged, and 214 o the 2-octet Global Administrator into the low order octets of the 215 4-octet Global Administrator, and 217 o the 4-octet Local Administrator into the Local Administrator 1, 218 and 220 o setting the remaining octets to zero. 222 Notice that the Global Administrator and the Local Administrator 223 fields in the Large community are in the reverse order compared to 224 those in the Extended Community. This is done for better octet 225 alignment. 227 If a community contains an Autonomous System Number less than 65536 228 and a Local Administrator 2 field of zero, then it can be represented 229 either as a 4-Octet AS Specific Large Community or a 2-Octet AS 230 Specific Extended Community. These communities would be treated as 231 different, even though they hold the same information. To prevent 232 such inconsistencies, such communities SHOULD be encoded as a 2-Octet 233 Specific Extended Community. 235 Similarly, if a community contains an Autonomous System Number 236 greater than 65535 and a Local Administrator field less than 65536, 237 then it SHOULD be encoded as a 4-Octet AS Specific Extended Community 238 as per [RFC5668]. 240 5. Large Regular Communities 242 The AS portion of BGP Communities described in [RFC1997] is too small 243 to fit a 4-octet ASN. 244 [I-D.ietf-idr-as4octet-extcomm-generic-subtype] defines an Extended 245 Community sub-type to perform the same function with a 4-octet ASN. 246 Large Communities will provide the same functionality, but provide an 247 extra 4 octets of Local Administrator space. 249 6. Security Considerations 251 TBD 253 7. IANA Considerations 255 IANA is requested to assign a BGP path attribute value for the Large 256 community attribute. 258 IANA is requested to create and maintain a registry for the Type 259 field of the Large Community. This document reserves the Type value 260 0 for the 4-Octet AS Specific Large Community. 262 IANA is requested to create and maintain a registry for the Sub-Type 263 field of the 4-Octet AS Specific Large Community. The initial values 264 in the registry should be the same as those in the registry for the 265 2-octet AS Specific Extended Community. These values are reproduced 266 as follows: 268 0x02 Route Target [RFC4360] 270 0x03 Route Origin [RFC4360] 272 0x04 Link Bandwidth [I-D.ietf-idr-link-bandwidth] 274 0x05 OSPF Domain Identifier [RFC4577] 276 0x08 BGP Data Collection [RFC4384] 278 0x09 Source AS [RFC6514] 280 0x0a L2VPN Identifier [RFC6074] 282 0x10 Cisco VPN-Distinguisher [Eric_Rosen] 283 0x80 Virtual-Network Identifier Extended Community 284 [I-D.drao-bgp-l3vpn-virtual-network-overlays] 286 As the generic sub-type defined in 287 [I-D.ietf-idr-as4octet-extcomm-generic-subtype] is 4 and clashes with 288 the value for the Link Bandwidth, IANA is requested to assign a new 289 value. 291 8. Acknowledgements 293 Thanks to Russ White, Acee Lindem and Shyam Sethuram for insightful 294 review and comments. 296 9. References 298 9.1. Normative References 300 [I-D.ietf-idr-as4octet-extcomm-generic-subtype] 301 Rao, D., Mohapatra, P., and J. Haas, "Generic Subtype for 302 BGP Four-octet AS specific extended community", draft- 303 ietf-idr-as4octet-extcomm-generic-subtype-08 (work in 304 progress), June 2015. 306 [RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities 307 Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996, 308 . 310 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 311 Requirement Levels", BCP 14, RFC 2119, 312 DOI 10.17487/RFC2119, March 1997, 313 . 315 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 316 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 317 February 2006, . 319 [RFC4893] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS 320 Number Space", RFC 4893, DOI 10.17487/RFC4893, May 2007, 321 . 323 [RFC5668] Rekhter, Y., Sangli, S., and D. Tappan, "4-Octet AS 324 Specific BGP Extended Community", RFC 5668, 325 DOI 10.17487/RFC5668, October 2009, 326 . 328 9.2. Informative References 330 [I-D.drao-bgp-l3vpn-virtual-network-overlays] 331 Rao, D., Mullooly, J., and R. Fernando, "Layer-3 virtual 332 network overlays based on BGP Layer-3 VPNs", draft-drao- 333 bgp-l3vpn-virtual-network-overlays-03 (work in progress), 334 July 2014. 336 [I-D.ietf-idr-link-bandwidth] 337 Mohapatra, P. and R. Fernando, "BGP Link Bandwidth 338 Extended Community", draft-ietf-idr-link-bandwidth-06 339 (work in progress), January 2013. 341 [RFC4384] Meyer, D., "BGP Communities for Data Collection", BCP 114, 342 RFC 4384, DOI 10.17487/RFC4384, February 2006, 343 . 345 [RFC4577] Rosen, E., Psenak, P., and P. Pillay-Esnault, "OSPF as the 346 Provider/Customer Edge Protocol for BGP/MPLS IP Virtual 347 Private Networks (VPNs)", RFC 4577, DOI 10.17487/RFC4577, 348 June 2006, . 350 [RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, 351 "Provisioning, Auto-Discovery, and Signaling in Layer 2 352 Virtual Private Networks (L2VPNs)", RFC 6074, 353 DOI 10.17487/RFC6074, January 2011, 354 . 356 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 357 Encodings and Procedures for Multicast in MPLS/BGP IP 358 VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, 359 . 361 Authors' Addresses 363 Jakob Heitz 364 Cisco 365 170 West Tasman Drive 366 San Jose, CA, CA 95054 367 USA 369 Email: jheitz@cisco.com 370 Keyur Patel 371 Cisco 372 170 West Tasman Drive 373 San Jose, CA 95054 374 USA 376 Email: keyupate@cisco.com 378 Job Snijders 379 NTT Communications, Inc. 380 Theodorus Majofskistraat 100 381 Amsterdam 1065 SZ 382 NL 384 Email: job@ntt.net 386 Ignas Bagdonas 387 Equinix 388 London 389 UK 391 Email: ibagdona.ietf@gmail.com