idnits 2.17.1 draft-ietf-idr-bgp-ext-communities-03.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 7 longer pages, the longest (page 2) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([BGP-4]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 90: '...tended community MUST NOT be reused as...' RFC 2119 keyword, line 230: '...ield in the Value Field MUST be unique...' RFC 2119 keyword, line 245: '...ield in the Value Field MUST be unique...' RFC 2119 keyword, line 257: '... MAY be marked as non-transitive acr...' RFC 2119 keyword, line 266: '... MUST represent the Autonomous Syste...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 68 has weird spacing: '...es with the E...' == Line 292 has weird spacing: '...tribute as de...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 1771 (ref. 'BGP-4') (Obsoleted by RFC 4271) Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Srihari R. Sangli 3 Internet Draft Procket Networks 4 Expiration Date: September 2002 5 Daniel Tappan 6 Cisco Systems 8 Yakov Rekhter 9 Juniper Networks 11 BGP Extended Communities Attribute 13 draft-ietf-idr-bgp-ext-communities-03.txt 15 1. Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as ``work in progress.'' 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 2. Abstract 38 This document describes an extension to BGP [BGP-4] which may be used 39 to provide flexible control over the distribution of routing 40 information. 42 3. Introduction 44 The Extended Community Attribute provides two important enhancements 45 over the existing BGP Community Attribute: 47 - It provides an extended range, ensuring that communities can be 48 assigned for a plethora of uses, without fear of overlap. 50 - The addition of a Type field provides structure for the 51 community space. 53 The addition of structure allows the usage of policy based on the 54 application for which the community value will be used. For example, 55 one can filter out all communities of a particular type, or allow 56 only certain values for a particular type of community. It also 57 allows one to specify whether a particular community is transitive or 58 non-transitive across Autonomous system boundary. Without structure, 59 this can only be accomplished by explicitly enumerating all community 60 values which will be denied or allowed and passed to BGP speakers in 61 neighboring ASes based on the transitive property. 63 4. BGP Extended Communities Attribute 65 The Extended Communities Attribute is a transitive optional BGP 66 attribute. The attribute consists of a set of "extended 67 communities". Each extended community is coded as an eight octet 68 value. All routes with the Extended Communities attribute belong to 69 the communities listed in the attribute. 71 The Extended Communities Attribute has Type Code 16. 73 Each Extended Community is encoded as an eight octet quantity, as 74 follows: 76 - Type Field : 1 or 2 octets 77 - Value Field : Remaining octets 79 Type Field: 81 Two classes of Type Field are introduced: Regular type and 82 Extended type. 84 The size of Type Field for Regular types is 1 octet and the 85 size of the Type Field for Extended types is 2 octets. 87 The value of the high-order octet will determine if its a 88 regular type or an extended type. The value of the high-order 89 octet of the Type Field defined as regular type (or extended 90 type) for a extended community MUST NOT be reused as the value 91 of the high-order octet of the Type Field defined as extended 92 type (or regular type). In other words, a new extended 93 community of regular type (extended type) should have unique 94 (and new) value for the high-order octet (high-order and low- 95 order octet). 97 The high-order octet of the Type Field is as shown below: 99 First bit (MSB) : IANA authority bit 100 Value 0 : IANA assignable type 101 Value 1 : Vendor-specific types 103 Second bit : Transitive bit 104 Value 0 : The community is 105 Transitive across ASes 106 Value 1 : The community is 107 Non-Transitive across ASes 109 Remaining 6 bits : Indicates the structure of the 110 community 112 Value Field: 114 The encoding of the Value Field is dependent on the "type" of 115 the community as specified by the Type Field. The encoding of 116 the community for the transitive communities should be such 117 that it is unique globally (i.e. across the Autonomous 118 Systems). 120 Two extended communities are declared equal only when entire 8 121 octets are equal. 123 The two members in the tuple should be enumerated to 124 specify any community value. Based on the value of the Type field, 125 the remaining octets of the community should be interpreted. 127 5. New BGP Extended Community Types. 129 This document introduces a few extended types and defines the Value 130 Field for those types. 132 Type 0x00: 134 This is an extended type with Type Field comprising of 2 octets 135 and Value Field comprising of 6 octets. 137 The value of the high-order octet of this extended type is 138 0x00. The low-order octet of this extended type is used to 139 indicate sub-types. 141 The Value Field consists of two sub-fields: 143 Global Administrator sub-field: 2 octets 145 This sub-field contains an Autonomous System number 146 assigned by IANA. 148 Local Administrator sub-field: 4 octets 150 The organization identified by Autonomous System number 151 in the Global Administrator sub-field, can encode any 152 information in this sub-field. The value and meaning of 153 the value encoded in this sub-field should be defined by 154 the sub-type of the community. 156 Type 0x01: 158 This is an extended type with Type Field comprising of 2 octets 159 and Value Field comprising of 6 octets. 161 The value of the high-order octet of this extended type is 162 0x01. The low-order octet of this extended type is used to 163 indicate sub-types. 165 The Value field consists of two sub-fields. 167 Global Administrator sub-field: 4 octets 169 This sub-field contains an IPv4 address assigned by IANA. 171 Local Administrator sub-field: 2 octets 173 The organization which has been assigned the IPv4 address 174 in the Global Administrator sub-field, can encode any 175 information in this sub-field. The value and meaning of 176 this value encoded in this sub-field should be defined by 177 the sub-type of the community. 179 Type 0x02: 181 This is an extended type with Type Field comprising of 2 octets 182 and Value Field comprising of 6 octets. 184 The value of the high-order octet of this extended type is 185 0x02. The low-order octet of this extended type is used to 186 indicate sub-types. 188 The Value Field consists of two sub-fields. 190 Global Administrator sub-field: 4 octets 192 This sub-field contains a 4-octets Autonomous System 193 number assigned by IANA. 195 Local Administrator sub-field: 2 octets 197 The organization identified by Autonomous System number 198 in the Global Administrator sub-field, can encode any 199 information in this sub-field. The value and meaning of 200 the value encoded in this sub-field should be defined by 201 the sub-type of the community. 203 Type 0x03: 205 This is an extended type with Type Field comprising of 2 octets 206 and Value Field comprising of 6 octets. 208 The value of the high-order octet of this extended type is 209 0x03. The low-order octet of this extended type is used to 210 indicate sub-types. 212 The Value Field contains a 6 byte value of structure with sub- 213 fields. 215 This is a generic community of extended type. The value of the 216 sub-type which should define the Value Field is to be assigned 217 by IANA. 219 6. Route Target Community 221 The Route Target Community identifies one or more routers that may 222 receive a set of routes (that carry this Community) carried by BGP. 223 This is transitive across the Autonomous system boundary. 225 The value of the Type field for the Route Target Community can be 226 0x00, 0x01 or 0x02. The value of the low-order octet of the extended 227 type field for this community is 0x02. 229 When the value of the Type field is 0x00 or 0x02, the value of the 230 Local Administrator sub-field in the Value Field MUST be unique 231 within the Autonomous system carried in the Global Administrator sub- 232 field. 234 7. Route Origin Community 236 The Route Origin Community identifies one or more routers that inject 237 a set of routes (that carry this Community) into BGP. This is 238 transitive across the Autonomous system boundary. 240 The value of the Type field for the Route Origin Community can be 241 0x00, 0x01 or 0x02. The value of the low-order octet of the extended 242 type field for this community is 0x03. 244 When the value of the Type field is 0x00 or 0x02, the value of the 245 Local Administrator sub-field in the Value Field MUST be unique 246 within the Autonomous system carried in the Global Administrator sub- 247 field. 249 8. Link Bandwidth Community 251 When a router receives a route from a directly connected external 252 neighbor (the external neighbor that is one IP hop away), and 253 advertises this route (via IBGP) to internal neighbors, as part of 254 this advertisement the router may carry the bandwidth of the link 255 that connects the router with the external neighbor. The bandwidth of 256 such a link is carried in the Link Bandwidth Community. The community 257 MAY be marked as non-transitive across the Autonomous system 258 boundary. 260 If the community is marked as non-transitive, then the value of the 261 high-order octet of the extended Type Field is 0x40, otherwise it is 262 0x00. The value of the low-order octet of the extended type field 263 for this community is 0x04. 265 The value of the Global Administrator sub-field in the Value Field 266 MUST represent the Autonomous System of the router that attaches the 267 Link Bandwidth Community. When a router receives a route with the 268 community, the router may check the AS number in the Global 269 Administrator sub-field to see if its not the local AS and hence 270 ignore the information carried in the Link Bandwidth Community. 272 The bandwidth of the link is expressed as 4 octets in IEEE floating 273 point format, units being bytes per second. It is carried in the 274 Local Administrator sub-field of the Value Field. 276 9. Operations 278 A BGP speaker may use the Extended Communities attribute to control 279 which routing information it accepts, prefers or distributes to its 280 peers. 282 A BGP speaker receiving a route that doesn't have the Extended 283 Communities attribute may append this attribute to the route when 284 propagating it to its peers. 286 A BGP speaker receiving a route with the Extended Communities 287 attribute may modify this attribute according to the local policy. 289 A BGP speaker should not propagate a non-transitive extended 290 community across the Autonomous system boundary. 292 A route may carry both the BGP Communities attribute as defined in 293 [RFC1997]), and the Extended BGP Communities attribute. In this case 294 the BGP Communities attribute is handled as specified in [RFC1997], 295 and the Extended BGP Communities attribute is handled as specified in 296 this document. 298 10. IANA Considerations 300 For the high-order octet of the Type Field, values 0x00 through 0x03 301 are assigned in this document and are defined as extended types. For 302 the combination of the high-order and low-order octets of the Type 303 Field values 0x0002-0x0004, 0x0102-0x0103, and 0x0202-0x0203 are 304 assigned in this document. 306 The Type Field values 0x04-0x3f for regular types (0x0400-0x3fff when 307 expressed as extended types) are to be assigned by IANA, using the 308 "First Come First Served" policy defined in RFC 2434. The extended 309 type field values 0x0000-0x0001, 0x0005-0x00ff, 0x0100-0x0101, 310 0x0104-0x01ff, 0x0200-0x0201, 0x0204-0x02ff and 0x0300-0x03ff are to 311 be assigned by IANA, using the "First Come First Served" policy 312 defined in RFC 2434. Type values 0x80-0xbf for regular types 313 (0x8000-0xbfff when expressed as extended types) are vendor-specific 314 types, and values in this range are not to be assigned by IANA. 316 11. Security Considerations 318 This extension to BGP does not change the underlying security issues. 320 12. Acknowledgements 322 The authors would like to thank John Hawkinson, Jeffrey Haas, Bruno 323 Rijsman for their suggestions and feedback. 325 13. References 327 [BGP-4] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 328 (BGP-4)", RFC 1771, March 1995. 330 [RFC1997] Chandra, R., Traina, P., Li, T., "BGP Communities 331 Attribute", RFC1997, August 1996. 333 14. Author Information 335 Srihari R. Sangli 336 Procket Networks, Inc. 337 1100 Cadillac Court 338 Milpitas, CA - 95035 339 e-mail: srihari@procket.com 341 Dan Tappan 342 Cisco Systems, Inc. 343 250 Apollo Drive 344 Chelmsford, MA 01824 345 e-mail: tappan@cisco.com 347 Yakov Rekhter 348 Juniper Networks, Inc. 349 1194 N. Mathilda Ave 350 Sunnyvale, CA 94089 351 e-mail: yakov@juniper.net