idnits 2.17.1 draft-heitz-idr-large-community-01.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 18, 2016) is 2832 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 19, 2017 J. Snijders 6 NTT 7 I. Bagdonas 8 Equinix 9 July 18, 2016 11 Large BGP Community 12 draft-heitz-idr-large-community-01 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 19, 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. Equivalence with Extended Communities . . . . . . . . . . . . 5 64 5. RT Constraint . . . . . . . . . . . . . . . . . . . . . . . . 6 65 6. Large Regular Communities . . . . . . . . . . . . . . . . . . 6 66 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 67 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 68 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 69 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 10.1. Normative References . . . . . . . . . . . . . . . . . . 7 71 10.2. Informative References . . . . . . . . . . . . . . . . . 8 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 74 1. Introduction 76 A BGP Community attribute is defined that encodes 14 byte 77 communities, suitable for 4-Octet Autonomous System Numbers that 78 require a 8-Octet Local Administrator field. 80 The 2-octet AS Specific Extended Community defined in [RFC4360] has 81 been widely used. 4-octet AS numbers as defined by [RFC4893] are 82 unable to make use of this popular extended community. Subsequently, 83 [RFC5668] defined a 4-octet AS Specific Extended community. However, 84 to make room for the extra 2 octets of AS number, the Local 85 Administrator field was shrunk from 4 octets to 2. This document 86 defines a community to extend that to 8 octets. 88 To ensure rapid and smooth adoption of the new community attribute, 89 it must be as similar to the extended community as possible, only 90 bigger. 92 2. Large BGP Community Attribute 94 The Large Community Attribute is a transitive optional BGP attribute, 95 with the Type Code (suggested 41) to be assigned by IANA. The 96 attribute consists of a set of "Large Communities". All routes with 97 the Large Community attribute belong to the communities listed in the 98 attribute. 100 Each Large Community is encoded as a 14-octet quantity, as follows: 102 0 1 2 3 103 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 104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 105 |I| T | Type | Sub-Type | | 106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value + 107 | | 108 + + 109 | | 110 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 111 | | 112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 114 The fields are as shown below: 116 I - IANA authority bit 118 Value 0: IANA-assignable type using the "First Come First 119 Serve" policy 121 Value 1: Part of this Type Field space is for IANA 122 assignable types using either the Standard Action or 123 the Early IANA Allocation policy. The rest of this 124 Type Field space is for Experimental use. 126 T - Transitivity field 128 Value 0: The community is transitive across all ASes. 130 Value 1: The community is transitive across AS boundaries, 131 but not across an administration boundary. An 132 administration in this sense is an arbitrary set of 133 connected ASes, possibly owned by a single 134 administration. How such an administration boundary 135 is determined is out of scope of this document. 137 Value 2: The community is transitive across Confederation 138 member AS boundaries, but not across a confederation 139 boundary or across an AS boundary that does not use 140 confederations. 142 Value 3: The community is not transitive across any AS 143 boundary, including Confederation Member AS. 145 Type - 5 bits describing how the value field is divided. One 146 type, the 4-Octet AS Specific Large Community is described 147 in this document. 149 Sub-type - describes the meaning of the value field. 151 Value - The actual information according to the sub-type. 153 The Transitivity field is only a hint to BGP speakers that do not 154 implement or understand the specific community. In some cases it 155 makes sense to send a community across one boundary but not the next. 156 An example is the Link Bandwidth Extended Community. 158 The Transitivity field is not implicitly associated with the Type and 159 Sub-Type fields the way they are in Extended Communities. The 160 Transitivity field should be set by the originator based upon 161 individual circumstances at the originator 163 3. 4-Octet AS Specific Large Community 165 This is a Large Community type with a Value field comprising 12 166 octets. 168 0 1 2 3 169 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 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 |0| T | 2 | Sub-Type | Global Administrator : 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 : Global Administrator (cont.) | Local Administrator 1 : 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 : Local Administrator 1 (cont.) | Local Administrator 2 : 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 : Local Administrator 2 (cont.) | 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 The definition of each sub-type should specify how to set the T 181 field. The Type field is 2. The Sub-Type is to be assigned by IANA 182 for individual functions. 184 The Value field consists of 3 sub-fields: 186 Global Administrator sub-field: 4 octets 188 This sub-field contains a 4-octet Autonomous System number 189 assigned by IANA. 191 Local Administrator 1 sub-field: 4 octets 192 Local Administrator 2 sub-field: 4 octets 194 The organization identified by the Autonomous System number in 195 the Global Administrator sub-field can encode any information 196 in these sub-fields. The format and meaning of the value 197 encoded in these sub-fields should be defined by the sub-type 198 of the community. 200 3.1. Textual Representation 202 The textual representation of the 4-Octet AS Specific Large Community 203 is A:B:C, where A is the Global Administrator, B is the Local 204 Administrator 1 and C is the Local Administrator 2. A ranges from 0 205 to 4294967295. B ranges from 0 to 4294967295. C ranges from 0 to 206 4294967295. A, B and C are plain decimal non-negative integers 207 without leading zeroes. Each number must appear, even if it is 0. 208 For example, "0:1:2" cannot be written as ":1:2". 210 4. Equivalence with Extended Communities 212 A 4-octet AS Specific Extended Community [RFC5668] is equivalent to a 213 4-octet AS Specific Large Community if: 215 o bits 1 and 2 of the Extended community Type field is equal to the 216 Transitivity, and 218 o the Sub-Types are semantically equivalent, and 220 o the Global Administrators are equal, and 222 o the Extended Community Local Administrator left shifted by 16 bits 223 is equal to the Local Administrator 1, and 225 o Local Administrator 2 is zero. 227 A 2-octet AS Specific Extended Community [RFC4360] is equivalent to a 228 4-octet AS Specific Large Community if: 230 o bits 1 and 2 of the Extended community Type field is equal to the 231 Transitivity, and 233 o the Sub-Types are semantically equivalent, and 235 o the Global Administrators are equal, and 237 o the Extended Community Local Administrator is equal to the Local 238 Administrator 1, and 240 o Local Administrator 2 is zero. 242 If a community contains an Autonomous System Number less than 65536 243 and a Local Administrator value less than 2^32, then it can be 244 represented either as a 4-Octet AS Specific Large Community or a 245 2-Octet AS Specific Extended Community. These communities would be 246 treated as different, even though they hold the same information. To 247 prevent such inconsistencies, such communities SHOULD be encoded as a 248 2-Octet Specific Extended Community. 250 Similarly, if a community contains an Autonomous System Number 251 greater than 65535 and a Local Administrator value less than 65536, 252 then it SHOULD be encoded as a 4-Octet AS Specific Extended Community 253 as per [RFC5668]. 255 5. RT Constraint 257 RT Constraint is defined in [RFC4684]. If RT Constraint is to be 258 used with Large Community Route Targets, then the maximum length of 259 an RT Constraint prefix needs to be increased to 144 bits. 261 An RT Constraint prefix made from a 4-Octet AS Specific Extended 262 Community is directly comparable to an RT Constraint prefix made from 263 a 4-Octet AS Specific Large Community 265 6. Large Regular Communities 267 The AS portion of BGP Communities described in [RFC1997] is too small 268 to fit a 4-octet ASN. 269 [I-D.ietf-idr-as4octet-extcomm-generic-subtype] defines an Extended 270 Community sub-type to perform the same function with a 4-octet ASN. 271 Large Communities will provide the same functionality, but provide an 272 extra 6 octets of Local Administrator space. 274 7. Security Considerations 276 TBD 278 8. IANA Considerations 280 IANA is requested to assign a BGP path attribute value for the Large 281 community attribute. 283 IANA is requested to create and maintain a registry for the Type 284 field of the Large Community. This document reserves the Type value 285 0 for the 4-Octet AS Specific Large Community. 287 IANA is requested to create and maintain a registry for the Sub-Type 288 field of the 4-Octet AS Specific Large Community. The initial values 289 in the registry should be the same as those in the registry for the 290 2-octet AS Specific Extended Community. These values are reproduced 291 as follows: 293 0x02 Route Target [RFC4360] 295 0x03 Route Origin [RFC4360] 297 0x04 Link Bandwidth [I-D.ietf-idr-link-bandwidth] 299 0x05 OSPF Domain Identifier [RFC4577] 301 0x08 BGP Data Collection [RFC4384] 303 0x09 Source AS [RFC6514] 305 0x0a L2VPN Identifier [RFC6074] 307 0x10 Cisco VPN-Distinguisher [Eric_Rosen] 309 0x80 Virtual-Network Identifier Extended Community 310 [I-D.drao-bgp-l3vpn-virtual-network-overlays] 312 As the generic sub-type defined in 313 [I-D.ietf-idr-as4octet-extcomm-generic-subtype] is 4 and clashes with 314 the value for the Link Bandwidth, IANA is requested to assign a new 315 value. 317 9. Acknowledgements 319 Thanks to Russ White, Acee Lindem and Shyam Sethuram for insightful 320 review and comments. 322 10. References 324 10.1. Normative References 326 [I-D.ietf-idr-as4octet-extcomm-generic-subtype] 327 Rao, D., Mohapatra, P., and J. Haas, "Generic Subtype for 328 BGP Four-octet AS specific extended community", draft- 329 ietf-idr-as4octet-extcomm-generic-subtype-08 (work in 330 progress), June 2015. 332 [RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities 333 Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996, 334 . 336 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 337 Requirement Levels", BCP 14, RFC 2119, 338 DOI 10.17487/RFC2119, March 1997, 339 . 341 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 342 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 343 February 2006, . 345 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, 346 R., Patel, K., and J. Guichard, "Constrained Route 347 Distribution for Border Gateway Protocol/MultiProtocol 348 Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual 349 Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684, 350 November 2006, . 352 [RFC4893] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS 353 Number Space", RFC 4893, DOI 10.17487/RFC4893, May 2007, 354 . 356 [RFC5668] Rekhter, Y., Sangli, S., and D. Tappan, "4-Octet AS 357 Specific BGP Extended Community", RFC 5668, 358 DOI 10.17487/RFC5668, October 2009, 359 . 361 10.2. Informative References 363 [I-D.drao-bgp-l3vpn-virtual-network-overlays] 364 Rao, D., Mullooly, J., and R. Fernando, "Layer-3 virtual 365 network overlays based on BGP Layer-3 VPNs", draft-drao- 366 bgp-l3vpn-virtual-network-overlays-03 (work in progress), 367 July 2014. 369 [I-D.ietf-idr-link-bandwidth] 370 Mohapatra, P. and R. Fernando, "BGP Link Bandwidth 371 Extended Community", draft-ietf-idr-link-bandwidth-06 372 (work in progress), January 2013. 374 [RFC4384] Meyer, D., "BGP Communities for Data Collection", BCP 114, 375 RFC 4384, DOI 10.17487/RFC4384, February 2006, 376 . 378 [RFC4577] Rosen, E., Psenak, P., and P. Pillay-Esnault, "OSPF as the 379 Provider/Customer Edge Protocol for BGP/MPLS IP Virtual 380 Private Networks (VPNs)", RFC 4577, DOI 10.17487/RFC4577, 381 June 2006, . 383 [RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, 384 "Provisioning, Auto-Discovery, and Signaling in Layer 2 385 Virtual Private Networks (L2VPNs)", RFC 6074, 386 DOI 10.17487/RFC6074, January 2011, 387 . 389 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 390 Encodings and Procedures for Multicast in MPLS/BGP IP 391 VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, 392 . 394 Authors' Addresses 396 Jakob Heitz 397 Cisco 398 170 West Tasman Drive 399 San Jose, CA 95054 400 USA 402 Email: jheitz@cisco.com 404 Keyur Patel 405 Cisco 406 170 West Tasman Drive 407 San Jose, CA 95054 408 USA 410 Email: keyupate@cisco.com 412 Job Snijders 413 NTT Communications, Inc. 414 Theodorus Majofskistraat 100 415 Amsterdam 1065 SZ 416 NL 418 Email: job@ntt.net 420 Ignas Bagdonas 421 Equinix 422 London 423 UK 425 Email: ibagdona.ietf@gmail.com