idnits 2.17.1 draft-ietf-idr-bgp-ext-communities-02.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 89: '...tended community MUST NOT be reused as...' RFC 2119 keyword, line 229: '... the Value Field MUST be unique within...' RFC 2119 keyword, line 243: '... the Value Field MUST be unique within...' RFC 2119 keyword, line 261: '... MUST represent the Autonomous Syste...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 67 has weird spacing: '...es with the E...' == Line 287 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. -------------------------------------------------------------------------------- 1 Network Working Group Srihari R. Sangli 2 Internet Draft Procket Networks 3 Expiration Date: April 2002 4 Daniel Tappan 5 Cisco Systems 7 Yakov Rekhter 8 Juniper Networks 10 BGP Extended Communities Attribute 12 draft-ietf-idr-bgp-ext-communities-02.txt 14 1. Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as ``work in progress.'' 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 2. Abstract 37 This document describes an extension to BGP [BGP-4] which may be used 38 to provide flexible control over the distribution of routing 39 information. 41 3. Introduction 43 The Extended Community Attribute provides two important enhancements 44 over the existing BGP Community Attribute: 46 - It provides an extended range, ensuring that communities can be 47 assigned for a plethora of uses, without fear of overlap. 49 - The addition of a Type field provides structure for the 50 community space. 52 The addition of structure allows the usage of policy based on the 53 application for which the community value will be used. For example, 54 one can filter out all communities of a particular type, or allow 55 only certain values for a particular type of community. It also 56 allows one to specify whether a particular community is transitive or 57 non-transitive across Autonomous system boundary. Without structure, 58 this can only be accomplished by explicitly enumerating all community 59 values which will be denied or allowed and passed to BGP speakers in 60 neighboring ASes based on the transitive property. 62 4. BGP Extended Communities Attribute 64 The Extended Communities Attribute is a transitive optional BGP 65 attribute. The attribute consists of a set of "extended 66 communities". Each extended community is coded as an eight octet 67 value. All routes with the Extended Communities attribute belong to 68 the communities listed in the attribute. 70 The Extended Communities Attribute has Type Code 16. 72 Each Extended Community is encoded as an eight octet quantity, as 73 follows: 75 - Type Field : 1 or 2 octets 76 - Value Field : Remaining octets 78 Type Field: 80 Two classes of Type Field are introduced: Regular type and 81 Extended type. 83 The size of Type Field for Regular types is 1 octet and the 84 size of the Type Field for Extended types is 2 octets. 86 The value of the high-order octet will determine if its a 87 regular type or an extended type. The value of the high-order 88 octet of the Type Field defined as regular type (or extended 89 type) for a extended community MUST NOT be reused as the value 90 of the high-order octet of the Type Field defined as extended 91 type (or regular type). In other words, a new extended 92 community of regular type (extended type) should have unique 93 (and new) value for the high-order octet (high-order and low- 94 order octet). 96 The high-order octet of the Type Field is as shown below: 98 First bit (MSB) : IANA authority bit 99 Value 0 : IANA assignable type 100 Value 1 : Vendor-specific types 102 Second bit : Transitive bit 103 Value 0 : The community is 104 Transitive across ASes 105 Value 1 : The community is 106 Non-Transitive across ASes 108 Remaining 6 bits : Indicates the structure of the 109 community 111 Value Field: 113 The encoding of the Value Field is dependent on the "type" of 114 the community as specified by the Type Field. The encoding of 115 the community for the transitive communities should be such 116 that it is unique globally (i.e. across the Autonomous 117 Systems). 119 Two extended communities are declared equal only when entire 8 120 octets are equal. 122 The two members in the tuple should be enumerated to 123 specify any community value. Based on the value of the Type field, 124 the remaining octets of the community should be interpreted. 126 5. New BGP Extended Community Types. 128 This document introduces a few extended types and defines the Value 129 Field for those types. 131 Type 0x00: 133 This is an extended type with Type Field comprising of 2 octets 134 and Value Field comprising of 6 octets. 136 The value of the high-order octet of this extended type is 137 0x00. The low-order octet of this extended type is used to 138 indicate sub-types. 140 The Value Field consists of two sub-fields: 142 Global Administrator sub-field: 2 octets 144 This sub-field contains an Autonomous System number 145 assigned by IANA. 147 Local Administrator sub-field: 4 octets 149 The organization identified by Autonomous System number 150 in the Global Administrator sub-field, can encode any 151 information in this sub-field. The value and meaning of 152 the value encoded in this sub-field should be defined by 153 the sub-type of the community. 155 Type 0x01: 157 This is an extended type with Type Field comprising of 2 octets 158 and Value Field comprising of 6 octets. 160 The value of the high-order octet of this extended type is 161 0x01. The low-order octet of this extended type is used to 162 indicate sub-types. 164 The Value field consists of two sub-fields. 166 Global Administrator sub-field: 4 octets 168 This sub-field contains an IPv4 address assigned by IANA. 170 Local Administrator sub-field: 2 octets 172 The organization which has been assigned the IPv4 address 173 in the Global Administrator sub-field, can encode any 174 information in this sub-field. The value and meaning of 175 this value encoded in this sub-field should be defined by 176 the sub-type of the community. 178 Type 0x02: 180 This is an extended type with Type Field comprising of 2 octets 181 and Value Field comprising of 6 octets. 183 The value of the high-order octet of this extended type is 184 0x02. The low-order octet of this extended type is used to 185 indicate sub-types. 187 The Value Field consists of two sub-fields. 189 Global Administrator sub-field: 4 octets 191 This sub-field contains a 4-octets Autonomous System 192 number assigned by IANA. 194 Local Administrator sub-field: 2 octets 196 The organization identified by Autonomous System number 197 in the Global Administrator sub-field, can encode any 198 information in this sub-field. The value and meaning of 199 the value encoded in this sub-field should be defined by 200 the sub-type of the community. 202 Type 0x03: 204 This is an extended type with Type Field comprising of 2 octets 205 and Value Field comprising of 6 octets. 207 The value of the high-order octet of this extended type is 208 0x03. The low-order octet of this extended type is used to 209 indicate sub-types. 211 The Value Field contains a 6 byte value of structure with sub- 212 fields. 214 This is a generic community of extended type. The value of the 215 sub-type which should define the Value Field is to be assigned 216 by IANA. 218 6. Route Target Community 220 The Route Target Community identifies one or more routers that may 221 receive a set of routes (that carry this Community) carried by BGP. 222 This is transitive across the Autonomous system boundary. 224 The value of the Type field for the Route Target Community is 0x00 or 225 0x01. The value of the low-order octet of the extended type field 226 for this community is 0x02. 228 When the value of the Type field is 0x00, the value of the Local 229 Administrator sub-field in the Value Field MUST be unique within the 230 Autonomous system carried in the Global Administrator sub-field. 232 7. Route Origin Community 234 The Route Origin Community identifies one or more routers that inject 235 a set of routes (that carry this Community) into BGP. This is 236 transitive across the Autonomous system boundary. 238 The value of the Type field for the Route Origin Community is 0x00 or 239 0x01. The value of the low-order octet of the extended type field 240 for this community is 0x03. 242 When the value of the Type field is 0x00, the value of the Local 243 Administrator sub-field in the Value Field MUST be unique within the 244 Autonomous system carried in the Global Administrator sub-field. 246 8. Link Bandwidth Community 248 When a router receives a route from a directly connected external 249 neighbor (the external neighbor that is one IP hop away), and 250 advertises this route (via IBGP) to internal neighbors, as part of 251 this advertisement the router may carry the bandwidth of the link 252 that connects the router with the external neighbor. The bandwidth of 253 such a link is carried in the Link Bandwidth Community. The community 254 is non-transitive across the Autonomous system boundary. 256 The value of the high-order octet of the extended Type Field is 0x40. 257 The value of the low-order octet of the extended type field for this 258 community is 0x04. 260 The value of the Global Administrator sub-field in the Value Field 261 MUST represent the Autonomous System of the router that attaches the 262 Link Bandwidth Community. When a router receives a route with the 263 community, the router may check the AS number in the Global 264 Administrator sub-field to see if its not the local AS and hence 265 ignore the information carried in the Link Bandwidth Community. 267 The bandwidth of the link is expressed as 4 octets in IEEE floating 268 point format, units being bytes per second. It is carried in the 269 Local Administrator sub-field of the Value Field. 271 9. Operations 273 A BGP speaker may use the Extended Communities attribute to control 274 which routing information it accepts, prefers or distributes to its 275 peers. 277 A BGP speaker receiving a route that doesn't have the Extended 278 Communities attribute may append this attribute to the route when 279 propagating it to its peers. 281 A BGP speaker receiving a route with the Extended Communities 282 attribute may modify this attribute according to the local policy. 284 A BGP speaker should not propagate a non-transitive extended 285 community across the Autonomous system boundary. 287 A route may carry both the BGP Communities attribute as defined in 288 [RFC1997]), and the Extended BGP Communities attribute. In this case 289 the BGP Communities attribute is handled as specified in [RFC1997], 290 and the Extended BGP Communities attribute is handled as specified in 291 this document. 293 10. IANA Considerations 295 For the high-order octet of the Type Field, values 0x00 through 0x03 296 are assigned in this document and are defined as extended types. For 297 the low-order octet of the Type Field, values 0x02 through 0x04 are 298 assigned in this document. 300 The Type Field values 0x04-0x3f for regular types (0x0400-0x3fff when 301 expressed as extended types) are to be assigned by IANA, using the 302 "First Come First Served" policy defined in RFC 2434. The extended 303 type field values 0x0005-0x00ff, 0x0104-0x01ff, 0x0200-0x02ff and 304 0x0300-0x03ff are to be assigned by IANA, using the "First Come First 305 Served" policy defined in RFC 2434. Type values 0x80-0xbf for regular 306 types (0x8000-0xbfff when expressed as extended types) are vendor- 307 specific types, and values in this range are not to be assigned by 308 IANA. 310 11. Security Considerations 312 This extension to BGP does not change the underlying security issues. 314 12. Acknowledgements 316 The authors would like to thank John Hawkinson, Jeffrey Haas for 317 their feedback. 319 13. References 321 [BGP-4] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 322 (BGP-4)", RFC 1771, March 1995. 324 [RFC1997] Chandra, R., Traina, P., Li, T., "BGP Communities 325 Attribute", RFC1997, August 1996. 327 14. Author Information 329 Srihari R. Sangli 330 Procket Networks, Inc. 331 1100 Cadillac Court 332 Milpitas, CA - 95035 333 e-mail: srihari@procket.com 335 Dan Tappan 336 Cisco Systems, Inc. 337 250 Apollo Drive 338 Chelmsford, MA 01824 339 e-mail: tappan@cisco.com 341 Yakov Rekhter 342 Juniper Networks, Inc. 343 1194 N. Mathilda Ave 344 Sunnyvale, CA 94089 345 e-mail: yakov@juniper.net