idnits 2.17.1 draft-ramachandra-bgp-ext-communities-09.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 1 longer page, the longest (page 1) being 362 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 209: '... the Value Field MUST be unique within...' RFC 2119 keyword, line 223: '... the Value Field MUST be unique within...' RFC 2119 keyword, line 241: '... MUST represent the Autonomous Syste...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 66 has weird spacing: '...es with the E...' == Line 267 has weird spacing: '...tribute as de...' == Line 275 has weird spacing: '...e Field value...' == Line 277 has weird spacing: '...es) are to be...' -- 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 (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Srihari Ramachandra 2 Internet Draft Daniel Tappan 3 Expiration Date: December 2001 Cisco Systems 5 Yakov Rekhter 6 Juniper Networks 8 BGP Extended Communities Attribute 10 draft-ramachandra-bgp-ext-communities-09.txt 12 1. Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026 except that the right to 16 produce derivative works is not granted. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as ``work in progress.'' 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 2. Abstract 36 This document describes an extension to BGP [BGP-4] which may be used 37 to provide flexible control over the distribution of routing 38 information. 40 3. Introduction 42 The Extended Community Attribute provides two important enhancements 43 over the existing BGP Community Attribute: 45 - It provides an extended range, ensuring that communities can be 46 assigned for a plethora of uses, without fear of overlap. 48 - The addition of a Type field provides structure for the 49 community space. 51 The addition of structure allows the application of policy based on 52 the application for which the community value will be used. For 53 example, one can filter out all communities of a particular type, or 54 allow only certain values for a particular type of community. It also 55 allows one to specify whether a particular community is transitive or 56 non-transitive across Autonomous system boundary. Without structure 57 this can only be accomplished by explicitly enumerating all community 58 values which will be denied or allowed and passed to BGP speakers in 59 neighboring ASes based on the transitive property. 61 4. BGP Extended Communities Attribute 63 The Extended Communities Attribute is a transitive optional BGP 64 attribute. The attribute consists of a set of "extended 65 communities". Each extended community is coded as an eight octet 66 value. All routes with the Extended Communities attribute belong to 67 the communities listed in the attribute. 69 The Extended Communities Attribute has Type Code 16. 71 Each Extended Community is encoded as an eight octet quantity, as 72 follows: 74 - Type Field : 1 or 2 octets 75 - Value Field : Remaining octets 77 Type Field: 79 The value of the high-order octet will determine if its a 80 regular type or extended type. The size of Type Field for 81 regular types is 1 octet and the size of the Type Field for 82 extended types is 2 octets. 84 The high-order octet of the Type Field is as shown below: 86 First bit (MSB) : IANA authority bit 87 Value 0 : IANA assignable type 88 Value 1 : Vendor-specific types 90 Second bit : Transitive bit 91 Value 0 : The community is 92 Transitive across ASes 93 Value 1 : The community is 94 Non-Transitive across ASes 96 Remaining 6 bits : Indicates the structure of the 97 community 99 For regular types, values of the Type Field 0 through 0x3f 100 inclusive are assignable by IANA. The values 0x80 through 0xbf 101 inclusive are vendor-specific. 103 For extended types, values of the Type Field 0 through 0x3fff 104 inclusive are assignable by IANA. The values 0x8000 through 105 0xbfff inclusive are vendor-specific. 107 Value Field: 109 The encoding of the Value Field is dependent on the "type" of 110 the community as specified by the Type Field. The encoding of 111 the community for the transitive communities should be such 112 that it is unique globally (i.e. across the Autonomous 113 Systems). 115 Two extended communities are declared equal only when entire 8 116 octets are equal. 118 The two members in the tuple should be enumerated to 119 specify any community value. Based on the value of the Type field, 120 the remaining octets of the community should be interpreted. 122 5. New BGP Extended Community Types. 124 This document introduces few extended types and defines the Value 125 Field for those types. 127 Type 0x00: 129 This is an extended type with Type Field comprising of 2 octets 130 and Value Field comprising of 6 octets. 132 The value of the high-order octet of this extended type is 133 0x00. The low-order octet of this extended type is used to 134 indicate subtypes. 136 The Value Field consists of two subfields: 138 Global Administrator subfield: 2 octets 140 This subfield contains an Autonomous System number 141 assigned by IANA. 143 Local Administrator subfield: 4 octets 145 The organization identified by Autonomous System number 146 in the Global Administrator subfield, can encode any 147 information in this subfield. The value and meaning of 148 the value encoded in this subfield should be defined by 149 the subtype of the community. 151 Type 0x01: 153 This is an extended type with Type Field comprising of 2 octets 154 and Value Field comprising of 6 octets. 156 The value of the high-order octet of this extended type is 157 0x01. The low-order octet of this extended type is used to 158 indicate subtypes. 160 The Value field consists of two subfields. 162 Global Administrator subfield: 4 octets 164 This subfield contains an IPv4 address assigned by IANA. 166 Local Administrator subfield: 2 octets 168 The organization which has been assigned the IPv4 address 169 in the Global Administrator subfield, can encode any 170 information in this subfield. The value and meaning of 171 this value encoded in this subfield should be defined by 172 the subtype of the community. 174 Type 0x02: 176 This is an extended type with Type Field comprising of 2 octets 177 and Value Field comprising of 6 octets. 179 The value of the high-order octet of this extended type is 180 0x02. The low-order octet of this extended type is used to 181 indicate subtypes. 183 The Value Field consists of two subfields. 185 Global Administrator subfield: 4 octets 187 This subfield contains a 4-octets Autonomous System 188 number assigned by IANA. 190 Local Administrator subfield: 2 octets 192 The organization identified by Autonomous System number 193 in the Global Administrator subfield, can encode any 194 information in this subfield. The value and meaning of 195 the value encoded in this subfield should be defined by 196 the subtype of the community. 198 6. Route Target Community 200 The Route Target Community identifies one or more routers that may 201 receive a set of routes (that carry this Community) carried by BGP. 202 This is transitive across the Autonomous system boundary. 204 The value of the Type field for the Route Target Community is 0x00 or 205 0x01. The value of the low-order octet of the extended type field 206 for this community is 0x02. 208 When the value of the Type field is 0x00, the value of the Local 209 Administrator subfield in the Value Field MUST be unique within the 210 Autonomous system carried in the Global Administrator subfield. 212 7. Route Origin Community 214 The Route Origin Community identifies one or more routers that inject 215 a set of routes (that carry this Community) into BGP. This is 216 transitive across the Autonomous system boundary. 218 The value of the Type field for the Route Origin Community is 0x00 or 219 0x01. The value of the low-order octet of the extended type field 220 for this community is 0x03. 222 When the value of the Type field is 0x00, the value of the Local 223 Administrator subfield in the Value Field MUST be unique within the 224 Autonomous system carried in the Global Administrator subfield. 226 8. Link Bandwidth Community 228 When a router receives a route from a directly connected external 229 neighbor (the external neighbor that is one IP hop away), and 230 advertises this route (via IBGP) to internal neighbors, as part of 231 this advertisement the router may carry the bandwidth of the link 232 that connects the router with the external neighbor. The bandwidth of 233 such a link is carried in the Link Bandwidth Community. The community 234 is non-transitive across the Autonomous system boundary. 236 The value of the high-order octet of the extended Type Field is 0x40. 237 The value of the low-order octet of the extended type field for this 238 community is 0x04. 240 The value of the Global Administrator subfield in the Value Field 241 MUST represent the Autonomous System of the router that attaches the 242 Link Bandwidth Community. When a router receives a route with the 243 community, the router may check the AS number in the Global 244 Administrator subfield to see if its if its not the local AS and 245 hence ignore the information carried in the Link Bandwidth Community. 247 The bandwidth of the link is expressed as 4 octets in IEEE floating 248 point format, units being bytes per second. It is carried in the 249 Local Administrator subfield of the Value Field. 251 9. Operations 253 A BGP speaker may use the Extended Communities attribute to control 254 which routing information it accepts, prefers or distributes to its 255 peers. 257 A BGP speaker receiving a route that doesn't have the Extended 258 Communities attribute may append this attribute to the route when 259 propagating it to its peers. 261 A BGP speaker receiving a route with the Extended Communities 262 attribute may modify this attribute according to the local policy. 264 A BGP speaker should not propagate the non-transitive extended 265 community across the Autonomous system boundary. 267 A route may carry both the BGP Communities attribute as defined in 268 [RFC1997]), and the Extended BGP Communities attribute. In this case 269 the BGP Communities attribute is handled as specified in [RFC1997], 270 and the Extended BGP Communities attribute is handled as specified in 271 this document. 273 10. IANA Considerations 275 The Type Field values 0x00 and 0x01 are assigned in this document. 276 Type Field values 2-0x3fff for extended-types (2-0x3f for regular 277 types) are to be assigned by IANA, using the "First Come First 278 Served" policy defined in RFC 2434. Type values 0x8000-0xbfff for 279 extended-types (0x80-0xbf for regular-types) are for vendor-specific 280 types, and values in this range are not to be assigned by IANA. 282 11. Security Considerations 284 This extension to BGP does not change the underlying security issues. 286 12. Acknowledgements 288 The authors would like to thank John Hawkinson, Jeffrey Haas for 289 their feedback. 291 13. References 293 [BGP-4] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP- 294 4)", RFC 1771, March 1995. 296 [RFC1997] Chandra, R., Traina, P., Li, T., "BGP Communities 297 Attribute", RFC1997, August 1996. 299 14. Author Information 301 Srihari Ramachandra 302 Cisco Systems, Inc. 303 170 West Tasman Drive 304 San Jose, CA 95134 305 e-mail: rsrihari@cisco.com 307 Dan Tappan 308 Cisco Systems, Inc. 309 250 Apollo Drive 310 Chelmsford, MA 01824 311 e-mail: tappan@cisco.com 313 Yakov Rekhter 314 Juniper Networks, Inc. 315 1194 N. Mathilda Ave 316 Sunnyvale, CA 94089 317 e-mail: yakov@juniper.net