IDR Working Group R. Raszuk Internet-Draft Cisco Systems Intended status: Standards Track H. Gredler Expires: January 5, 2011 Juniper Networks July 4, 2010 Wide BGP Communities draft-raszuk-wide-bgp-communities-00 Abstract Communicating various routing policies via route tagging plays an important role in external BGP peering relations. The most common tool used today to attach various information about routes is realized with the use of BGP communities. Such information is important for the peering AS to perform some mutually agreed actions without the need to maintain a separate offline database for each pair of prefix and an associated with it requested set of action entries. The problem arises for customers which are assigned a 4 octet AS numbers as current definition of BGP communities are of total of 4 octets in length. This document proposes the solution to this problem by defining new type of BGP Extended Community attribute which is to be used to pass routing policy information between peers. Such new type could be used to pass existing routing policies which are communicated today by Internet Service Providers in standard BGP Community Attribute which have two octet AS numbers as well as those which already got assigned 4 octet AS numbers from their respected Internet routing registries. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." Raszuk & Gredler Expires January 5, 2011 [Page 1] Internet-Draft wide-bgp-communities July 2010 This Internet-Draft will expire on January 5, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Raszuk & Gredler Expires January 5, 2011 [Page 2] Internet-Draft wide-bgp-communities July 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Wide BGP Community . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Wide BGP Community . . . . . . . . . . . . . . . . . . . . 5 3. Globally significant pre-defined values . . . . . . . . . . . 7 3.1. Well Known Standard BGP Communities . . . . . . . . . . . 7 3.2. Registered pre-defined Wide BGP Communities . . . . . . . 7 3.2.1. General Registered Wide BGP Communities . . . . . . . 8 3.2.2. Advertisement control Registered Wide BGP Communities . . . . . . . . . . . . . . . . . . . . . 10 3.2.3. AS source marking Registered Wide BGP Communities . . 12 3.2.4. Return path influencing Registered Wide BGP Communities . . . . . . . . . . . . . . . . . . . . . 13 3.2.5. AS_PATH modifying Registered Wide BGP Communities . . 14 3.2.6. Geographic source marking Registered Wide BGP Communities . . . . . . . . . . . . . . . . . . . . . 16 3.2.7. Local Preference Registered Wide BGP Communities . . . 17 3.2.8. AS_PATH TTL Registered Wide BGP Communities . . . . . 18 4. Encoding examples . . . . . . . . . . . . . . . . . . . . . . 19 5. Operational considerations . . . . . . . . . . . . . . . . . . 20 6. Security considerations . . . . . . . . . . . . . . . . . . . 20 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 23 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 10.1. Normative References . . . . . . . . . . . . . . . . . . . 24 10.2. Informative References . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 Raszuk & Gredler Expires January 5, 2011 [Page 3] Internet-Draft wide-bgp-communities July 2010 1. Introduction RFC 1997 [RFC1997] defines a BGP Community Attribute to be used as a tool to contain in BGP update message various additional information about routes which may help to automate peering administration. As defined in RFC 1997 [RFC1997] BGP Communities attribute consists of one or more sets of four octet values, where each one of them specifies a different community. Except two reserved ranges the encoding of community values mandates that first two octets are to contain the Autonomous System number followed by next two octets containing locally defined value. With the introduction of 4-octet Autonomous System numbers by RFC 4893 [RFC4893] it became obvious that BGP Communities as specified in RFC 1997 will not be able to accommodate new AS encoding. In fact RFC 4893 explicitly recommends use of four octets AS specific extended communities as a way to encode new 4 octet AS numbers. Unfortunately both the RFC 4893 as well as proposal for new extended community encoding which would contain 4 octet AS numbers do not define a new sub-type value which would allow to carry routing policies in BGP extended communities. Authors believe that defining a new regular type of BGP Extended Communities for both two-octet and four-octet Autonomous System addresses a real operational problem of today's networks or of internet exchange points operators. While defining a new type of any tool there is always a unique opportunity to specify a subset of well recognized behaviors. Second part of this document lists the most commonly used today BGP communities as well as provides a new registry for future definitions. 2. Wide BGP Community The BGP Extended Communities attribute as defined in RFC 4360 [RFC4360] is a transitive optional BGP attribute with the Type Code 16 and consists of a set of extended communities of the following format: Raszuk & Gredler Expires January 5, 2011 [Page 4] Internet-Draft wide-bgp-communities July 2010 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type high | Type low(*) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (*) Present for Extended types only, used for the Value field otherwise. Figure1: The Extended Community Attribute For the purposes of encoding for Wide BGP Communities a new extended community type has been defined below. 2.1. Wide BGP Community Wide BGP Community is a BGP Extended Community of a regular type with Type Field comprising of 1 octet and Value Field comprising of 7 octets. Wide BGP Community is encoded as follows: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x06 or 0x46 | ACTIONS | 2 or 4 octet AS number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2 or 4 octet AS number | Community Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure2: Wide BGP Community For the purpose of scoping propagation of Wide BGP Communities across Autonomous System boundaries document recommends to define two values. The value of the high type of this regular extended community is 0x06 which indicates transitiveness across Autonomous System boundaries and 0x46 to indicate non-transitiveness across an Autonomous System boundary. *Values are to be confirmed by IANA* The remaining 7 octets are encoded as follows: ACTIONS: 1 octet Raszuk & Gredler Expires January 5, 2011 [Page 5] Internet-Draft wide-bgp-communities July 2010 1 2 3 4 5 6 7 8 +---+---+---+---+---+---+---+---+ | ACTIONS | +---+---+---+---+---+---+---+---+ Figure2: Wide BGP Community Actions 1 octet The Actions octet allows for explicit indication of the requested execution meaning or level of attached Wide BGP Community value. 0x00 - Default action. No special handling. 0x01 - Informational Only Support Indicator - Used to signal that attached Wide BGP Community is supported by given Autonomous System. That is particularly useful for AS specific Wide BGP Communities which are to be executed on remote transit domains or target domains. No execution is required on Wide BGP Communities propagate with this Action flag. 0x02 - Mandatory Execution - Indicates that an action encoded in attached Wide BGP Community is of mandatory execution type and therefor if given community is recognized it must be executed. If not executed for example due to local policy the bgp update message containing such Wide BGP Community must be dropped. However it needs to be pointed that as BGP communities are optional by design and therefor could be filtered at any network boundary the semantics of this action do not change that. The specified action does not change the base definition of BGP communities. 0x03..0x7F - Reserved for future extensions 0x80..0xFF - Open for operator's own use 2 or 4 octet Autonomous System number: 4 octets The Autonomous System number which indicates the originator of given Wide BGP Community or the target Autonomous System number given Wide BGP Community may be referring to. When Autonomous System is a two octet number the first two octets of this 4 octet value are to be filled with zeros. Two special values are reserved in the Autonomous System number field: 0x00000000 - to indicate "None of Autonomous Systems" and value of 0xFFFFFFFF - to indicate "All of Autonomous Systems". The detailed interpretation will be provided when describing each Raszuk & Gredler Expires January 5, 2011 [Page 6] Internet-Draft wide-bgp-communities July 2010 given community type which would intend to utilize the reserved Autonomous System number. Community Value: 2 octets The Wide BGP Community value encoded in this field indicates private or registered Wide BGP Community type which defines what set of actions a router is requested or recommended to take upon reception of routes with such tags. 3. Globally significant pre-defined values 3.1. Well Known Standard BGP Communities According to RFC 1997 as well as to IANA's Well-Known BGP Communities registry today the following BGP communities are defined to have global significance: 0xFFFF0000 planned-shut [draft-francois-bgp-gshut] 0xFFFFFF01 NO_EXPORT [RFC1997] 0xFFFFFF02 NO_ADVERTISE [RFC1997] 0xFFFFFF03 NO_EXPORT_SUBCONFED [RFC1997] 0xFFFFFF04 NOPEER [RFC3765] This document recommends for simplicity as well as for avoidance of backward compatibility issues the continued use of BGP Standard Community Attribute type 8 as defined in RFC 1997 to distribute non Autonomous System specific Well-Known BGP Communities. 3.2. Registered pre-defined Wide BGP Communities It has been requested numerous times to have a globally unified way to express some particular Autonomous System based routing policies. When defining a new way to encode bgp communities we have an opportunity to define set of new registered routing policies and route markings which could be passed between Autonomous Systems resulting in their common interpretation. This document will request IANA to define and maintain a new registry for pre-defined Wide BGP Communities. The reserved pool of AS#: 0xB000-0xFFFF (20479 values) has been defined for their allocations. The allocation policy is on a first come first served basis. It is recommended that an implementation supports by an explicit Raszuk & Gredler Expires January 5, 2011 [Page 7] Internet-Draft wide-bgp-communities July 2010 enabling all defined below Registered Wide BGP Communities. Depending on the BGP implementation support it is recommended that an implementation would support Registered Wide BGP Communities without breaking static or dynamic peer/update groups. However it needs to be pointed out that support of all Registered Wide BGP Communities is not mandatory. It will be perfectly valid for any BGP implementation to support only subset of Wide BGP Communities. It is strongly advised that each Autonomous System does an inbound verification of received Wide BGP Communities from all of its EBGP peers before accepting them and propagating within their own domain. The document does not mandate nor enforces that given registered type value of Wide BGP Community would be of transitive 0x06 or non- transitive 0x46 type. It is for the operator to determine the propagation scope of such community when appending it to routing information. However the document will provide a transitiveness scope recommendation to defined communities. The following Wide BGP Communities have global significance and their execution should be uniformly implemented by any BGP speaker supporting given set of Wide BGP Communities. In general there are two kinds of semantics for Autonomous System number present in the body of Registered Wide BGP Community: SRC_AS which indicates that the value corresponds to the Autonomous System number which constructed and appended given community and PARAM_AS which indicates that execution of given community is depended on evaluation of Autonomous System number present in this community. Unless explicitly indicated otherwise the Autonomous System number inserted into Wide BGP Communities are of SRC_AS type. 3.2.1. General Registered Wide BGP Communities Format: NAME (type_code) Recommended scope of use: local-domain or multi-domain. Recommended post execution action: "execute and drop" or "execute and forward" or "N/A". Description. SRC_AS:BLACKHOLE (AS:0xB000) Raszuk & Gredler Expires January 5, 2011 [Page 8] Internet-Draft wide-bgp-communities July 2010 Scope: multi-domain. Post exec: execute and forward. All transit traffic to destinations for which advertised routes carry such Wide BGP Community containing this value should be dropped. It is recommended that specified Autonomous System number should be eligible and verified by BGP Origin Validation functionality to advertise given BGP destinations. SRC_AS:BLACKHOLE_FROM_PEER (AS:0xB001) Scope: multi-domain. Post exec: execute and forward. All transit traffic to destinations for which advertised routes carry such Wide BGP Community containing this value should be dropped when coming from peers. It is recommended that specified Autonomous System number should be eligible and verified by BGP Origin Validation functionality to advertise given BGP destinations. SRC_AS:BLACKHOLE_FROM_UPSTREAM (AS:0xB002) Scope: multi-domain. Post exec: execute and forward. All transit traffic to destinations for which advertised routes carry such Wide BGP Community containing this value should be dropped when coming from upstream providers. It is recommended that specified Autonomous System number should be eligible and verified by BGP Origin Validation functionality to advertise given BGP destinations. SRC_AS:SOURCE_BLACKHOLE (AS:0xB003) Scope: multi-domain. Post exec: execute and forward. All transit traffic which source addresses have been tagged by such Wide BGP Community should be dropped. It is recommended that specified Autonomous System number should be eligible and verified by BGP Origin Validation functionality to advertise given BGP destinations. Raszuk & Gredler Expires January 5, 2011 [Page 9] Internet-Draft wide-bgp-communities July 2010 SRC_AS:SOURCE_DO_RPF (AS:0xB004) Scope: multi-domain. Post exec: execute and forward. All transit traffic which source addresses have been tagged by such Wide BGP Community should be subject to Reverse Path Forwarding check when crossing Autonomous System boundaries. Autonomous System number specified in the body of this community should directly indicate the peering interfaces on which such RPF check should be performed. SRC_AS:HIGH_PRIORITY_PREFIX (AS:0xB005) Scope: local-domain. Post exec: N/A (tagging only). BGP prefixes carrying such Wide BGP Community should be advertised to restarting peers before other prefixes received by given BGP speaker. SRC_AS:ATTACK_TARGET (AS:0xB006) Scope: multi-domain. Post exec: N/A (tagging only) The ATTACK_TARGET Registered Wide BGP Community indicates that BGP prefixes carrying such community are receiving unusual amount of unwanted traffic most likely due to some form of network attack. Network devices capable of analyzing and mitigating such attacks can use such community as a hint on what destinations to focus the most. 3.2.2. Advertisement control Registered Wide BGP Communities PARAM_AS:NO_ADVERTISE (AS:0xB080) Scope: multi-domain. Post exec: N/A - Entire update get's dropped. All routes received which carry such Wide BGP Community containing this value MUST NOT be advertised to BGP peer which Autonomous System number has been listed in the body of this community. Raszuk & Gredler Expires January 5, 2011 [Page 10] Internet-Draft wide-bgp-communities July 2010 Semantically specifying the reserved Autonomous System value of 0xFFFFFFFF (Any AS) would be an equivalent of using NO_ADVERTISE Well-Known Standard BGP Community Attribute. PARAM_AS:ADVERTISE_TO (AS:0xB081) Scope: multi-domain. Post exec: execute and drop. All routes received carrying such Wide BGP Community containing this value MUST ONLY be advertised to BGP peer which Autonomous System number is specified in the body of this community. SRC_AS:ADVERTISE_NO_PEER (AS:0xB082) Scope: multi-domain. Post exec: execute and drop All routes advertised by an Autonomous System carrying such Wide BGP Community containing this value should NOT be advertised to any of its peering partners. SRC_AS:ADVERTISE_NO_UPSTREAM (AS:0xB083) Scope: multi-domain. Post exec: execute and drop All routes advertised by an Autonomous System carrying such Wide BGP Community containing this value should NOT be advertised to any of its upstream providers. SRC_AS:ADVERTISE_NO_CUSTOMER (AS:0xB084) Scope: multi-domain. Post exec: execute and drop All routes advertised by an Autonomous System carrying such Wide BGP Community containing this value should NOT be advertised to any of its customers. PARAM_AS:ADVERTISE_TO_SET_NO_EXPORT (AS:0xB085) Raszuk & Gredler Expires January 5, 2011 [Page 11] Internet-Draft wide-bgp-communities July 2010 Scope: multi-domain. Post exec: execute and drop All routes received carrying such Wide BGP Community containing this value MUST ONLY be advertised to BGP peer which Autonomous System number is specified in the body of this community. If not already present during advertisement NO_EXPORT Standard BGP Community should be inserted. 3.2.3. AS source marking Registered Wide BGP Communities SRC_AS:FROM_PEER (AS:0xB100) Scope: local-domain. Post exec: N/A (tagging only) Autonomous System may attach this community to routes received from their EBGP peers to later, when advertising them outside the domain, apply or relax local policies only on such group of destinations. SRC_AS:FROM_CUSTOMER (AS:0xB101) Scope: local-domain. Post exec: N/A (tagging only) Autonomous System may attach this community to routes received from their EBGP peers to later, when advertising them outside the domain, apply or relax local policies only on such group of destinations. SRC_AS:INTERNAL (AS:0xB102) Scope: local-domain. Post exec: N/A (tagging only) Autonomous System may attach this community to routes originated in their own domain to later, when advertising them outside the domain, apply or relax local policies only on such group of destinations. SRC_AS:FROM_UPSTREAM (AS:0xB103) Raszuk & Gredler Expires January 5, 2011 [Page 12] Internet-Draft wide-bgp-communities July 2010 Scope: local-domain. Post exec: N/A (tagging only) Autonomous System may attach this community to routes received from their EBGP peers to later, when advertising them outside the domain, apply or relax local policies only on such group of destinations. SRC_AS:FROM_IX (AS:0xB104) Scope: local-domain. Post exec: N/A (tagging only) Autonomous System may attach this community to routes received from their EBGP peering sessions with the Internet Exchange peers or with Route Server to later, when advertising them outside the domain, apply or relax local policies only on such group of destinations. PARAM_AS:LEARNED_FROM (AS:0xB105) Scope: local-domain. Post exec: N/A (tagging only) Autonomous System may attach this community to routes received from their EBGP peer by explicitly tagging routes with their peer's Autonomous System number instead of inserting their own local AS number. 3.2.4. Return path influencing Registered Wide BGP Communities PARAM_AS:PATH_HINT (AS:0xB180) Scope: multi-domain. Post exec: execute and forward. Autonomous System receiving such Wide BGP Community value should prefer for BGP prefixes received with such community (for example by increasing value of local preference on ingress), a BGP path which traverses Autonomous System number which has been specified in this community. PARAM_AS:PATH_NEGATIVE_HINT (AS:0xB181) Raszuk & Gredler Expires January 5, 2011 [Page 13] Internet-Draft wide-bgp-communities July 2010 Scope: multi-domain. Post exec: execute and forward. Autonomous System receiving such Wide BGP Community value should prefer for BGP prefixes received with such community (for example by decreasing value of local preference on ingress), a BGP path which DOES NOT traverses Autonomous System number which has been specified in the body of this community. 3.2.5. AS_PATH modifying Registered Wide BGP Communities PARAM_AS:PREPEND_BY (AS:0xB200..0xB20F) Scope: multi-domain. Post exec: execute and drop. The Autonomous System specified in the body of such Wide BGP Community should prepend 1..15 times its own Autonomous System number when advertising routes tagged with this community to all of its external peers. Value of 0xB200 indicates the support for AS:PREPEND_BY Wide BGP Community and values of 0xB201..0xB20F indicate the required number of 1..15 prepended Autonomous System numbers. PARAM_AS:PREPEND_TO (AS:0xB210..0xB21F) Scope: multi-domain. Post exec: execute and drop. A BGP domain receiving routes tagged with this community should prepend 1..15 times its own Autonomous System number when advertising them to an Autonomous System indicated in the body of this community. Value of 0xB210 indicates the support for AS: PREPEND_TO Wide BGP Community and values of 0xB211..0xB21F indicate the required number of 1..15 prepended Autonomous System numbers. After execution this community should be removed from further bgp propagation. SRC_AS:PREPEND_UPSTREAM (AS:0xB220..0xB22F) Scope: multi-domain. Post exec: execute and drop. Raszuk & Gredler Expires January 5, 2011 [Page 14] Internet-Draft wide-bgp-communities July 2010 An Autonomous System when advertising routes tagged with this community value should prepend 1..15 times its own Autonomous System number when advertising them to all of its upstream providers. Value of 0xB220 indicates the support for AS: PREPEND_UPSTREAM Wide BGP Community and values of 0xB221..0xB22F indicate the required number of 1..15 prepended Autonomous System numbers. This community should not be propagated to EBGP neighbors. SRC_AS:PREPEND_PEERS (AS:0xB230..0xB23F) Scope: multi-domain. Post exec: execute and drop. An Autonomous System advertising routes tagged with this community should prepend 1..15 times its own Autonomous System number when advertising them to all of its peers. Value of 0xB230 indicates the support for AS:PREPEND_PEERS Wide BGP Community and values of 0xB231..0xB23F indicate the required number of 1..15 prepended Autonomous System numbers. This community should not be propagated to EBGP neighbors. SRC_AS:PREPEND_CUSTOMERS (AS:0xB240..0xB24F) Scope: multi-domain. Post exec: execute and drop. An Autonomous System advertising routes tagged with this community should prepend 1..15 times its own Autonomous System number when advertising them to all of its customers. Value of 0xB240 indicates the support for AS:PREPEND_CUSTOMERS Wide BGP Community and values of 0xB241..0xB24F indicate the required number of 1..15 prepended Autonomous System numbers. This community should not be propagated to EBGP neighbors. PARAM_AS:REPLACE_BY (AS:0xB250) Scope: multi-domain. Post exec: execute and drop. All routes marked with such Wide BGP Community advertised by an Autonomous System to all of its external peers should have any occurrence of an Autonomous System number specified replaced with advertising domain's local Autonomous System number. After execution this community should be removed from further bgp Raszuk & Gredler Expires January 5, 2011 [Page 15] Internet-Draft wide-bgp-communities July 2010 propagation. 3.2.6. Geographic source marking Registered Wide BGP Communities SRC_AS:PEER_ROUTE (AS:0xB280..0xB28F) Scope: local-domain or multi-domain. Post exec: N/A (tagging only). Autonomous System may mark routes received from their peers by constructing Wide BGP Community to contain their Autonomous System number and well-known pre-defined geographic localization community value as per below mapping table: 0xB280 - North America 0xB281 - Central America 0xB282 - South America 0xB283 - Europe 0xB284 - Asia 0xB285 - Japan 0xB286 - ANZ 0xB287 - Africa 0xB288 - Unspecified Region 0xB289 .. 0xB28F - Free SRC_AS:UPSTREAM_ROUTE (AS:0xB290..0xB29F) Scope: local-domain or multi-domain. Post exec: N/A (tagging only). Autonomous System may mark routes received from their upstreams by constructing Wide BGP Community to contain their Autonomous System number and well-known pre-defined geographic localization community value as per below mapping table: Raszuk & Gredler Expires January 5, 2011 [Page 16] Internet-Draft wide-bgp-communities July 2010 0xB290 - North America 0xB291 - Central America 0xB292 - South America 0xB293 - Europe 0xB294 - Asia 0xB295 - Japan 0xB296 - ANZ 0xB297 - Africa 0xB298 - Unspecified Region 0xB299 .. 0xB29F - Free SRC_AS:CUSTOMER_ROUTE (AS:0xB2A0..0xB2AF) Scope: local-domain or multi-domain. Post exec: N/A (tagging only). Autonomous System may mark routes received from their customers by constructing Wide BGP Community to contain their Autonomous System number and well-known pre-defined geographic localization community value as per below mapping table: 0xB2A0 - North America 0xB2A1 - Central America 0xB2A2 - South America 0xB2A3 - Europe 0xB2A4 - Asia 0xB2A5 - Japan 0xB2A6 - ANZ 0xB2A7 - Africa 0xB2A8 - Unspecified Region 0xB2A9 .. 0xB2AF - Free 3.2.7. Local Preference Registered Wide BGP Communities SRC_AS:LOCAL_PREF (AS:0xB300..0xB30F) Scope:multi-domain. Post exec: execute and drop. Autonomous System may suggest to its EBGP neighbor the following relative adjustments to the value of local preference as specified by given domain's local policy. The below table indicates the values of recommended increment and decrement local preference normalized by X. X is used by local domain operator to normalize absolute increment or decrement values for a given policies. Raszuk & Gredler Expires January 5, 2011 [Page 17] Internet-Draft wide-bgp-communities July 2010 0xB300 - Used to indicate support for AS:LOCAL_PREF 0xB301 - Decrement Local Pref by X*20 0xB302 - Decrement Local Pref by X*40 0xB303 - Decrement Local Pref by X*60 0xB304 - Decrement Local Pref by X*80 0xB305 - Decrement Local Pref by X*100 0xB306 - Increment Local Pref by X*20 0xB307 - Increment Local Pref by X*40 0xB308 - Increment Local Pref by X*60 0xB309 - Increment Local Pref by X*80 0xB30A - Increment Local Pref by X*100 0xB30B - Unallocated 0xB30C - Unallocated 0xB30D - Unallocated 0xB30E - Unallocated 0xB30F - Unallocated 3.2.8. AS_PATH TTL Registered Wide BGP Communities SRC_AS:AS_PATH_TTL (AS:0xB310..0xB31F) Scope: multi-domain. Post exec: execute and forward. Autonomous System may suggest to drop advertised prefix by any transit network if its AS_PATH attribute length would be equal or greater to encoded value both inbound or outbound of EBGP session. The below table indicates the value of recommended encoding of AS_PATH length which should result in prefix drop: Raszuk & Gredler Expires January 5, 2011 [Page 18] Internet-Draft wide-bgp-communities July 2010 0xB310 - Used to indicate support for AS:AS_PATH_TTL 0xB311 - Drop if AS_PATH >= 1 0xB312 - Drop if AS_PATH >= 2 0xB313 - Drop if AS_PATH >= 3 0xB314 - Drop if AS_PATH >= 4 0xB315 - Drop if AS_PATH >= 5 0xB316 - Drop if AS_PATH >= 6 0xB317 - Drop if AS_PATH >= 7 0xB318 - Drop if AS_PATH >= 8 0xB319 - Drop if AS_PATH >= 9 0xB31A - Drop if AS_PATH >= 10 0xB31B - Drop if AS_PATH >= 11 0xB31C - Drop if AS_PATH >= 12 0xB31D - Drop if AS_PATH >= 13 0xB31E - Drop if AS_PATH >= 14 0xB31F - Drop if AS_PATH >= 15 4. Encoding examples The 0xBBBB non mandatory and transitive Wide BGP Community encoding by AS 1 would be of below form: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x06 | 0x00 | 0x0000 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x0001 | 0xBBBB | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The same 0xBBBB Wide BGP Community, but non-transitive and mandatory encoding by AS 131072 would be of below form: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x46 | 0x80 | 0x0002 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x00 | 0x00 | 0xBBBB | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Raszuk & Gredler Expires January 5, 2011 [Page 19] Internet-Draft wide-bgp-communities July 2010 5. Operational considerations Having two different ways to propagate locally assigned BGP communities, one via use of Standard BGP Community attribute and the other one via use of Wide BGP Community may seem to potentially cause problems when considering propagation of conflicting actions. However it needs to be noticed and pointed out that today even within Standard BGP Communities operator or operators may append similar conflicting information to already existing community propagation tool set. It is therefor recommended that any implementation when supporting both standard and wide BGP communities will allow for their easy inbound and outbound policing. For the actual execution all communities should be treated as union and if supported by an implementation their execution permission are to be a local configuration matter. When advertising as well as during insertion of Wide BGP Communities which are predefined as range of values - only use of one value of selected range is allowed. 6. Security considerations All the security considerations for BGP Communities as well as for BGP Extended Communities RFCs apply here. 7. IANA Considerations This document defines a new regular type of BGP Extended Communities Attribute called Wide BGP Communities. For this new type IANA is to allocate new type values in the corresponding registries: Registry Name: BGP Extended Communities Type - regular, transitive This document makes the following assignments for the regular, transitive Wide BGP Communities: Name Type Value ---- ---------- Wide BGP Community 0x06 Registry Name: BGP Extended Communities Type - regular, non- Raszuk & Gredler Expires January 5, 2011 [Page 20] Internet-Draft wide-bgp-communities July 2010 transitive This document makes the following assignments for the regular, non- transitive Wide BGP Communities: Name Type Value ---- ---------- Wide BGP Community 0x46 This document requests IANA to define and maintain a new registry named: "Registered Wide BGP Communities Actions". The reserved pool of AS#:0x00-0x80 has been defined for its allocations. The allocation policy is on a first come first served basis. This document makes the following assignments for the Registered Wide BGP Community Actions values: Name Type Value ---- ---------- Default action 0x00 Informational Only Support Indicator 0x01 Mandatory 0x02 Reserved for further allocations 0x03..0x7F Open for operator's own use 0x80..0xFF This document requests IANA to define and maintain a new registry named: "Registered Wide BGP Communities Values". The reserved pool of AS#:0xB000-0xFFFF has been defined for its allocations. The allocation policy is on a first come first served basis. This document makes the following assignments for the Registered Wide BGP Community values: Name Type Value ---- ---------- BLACKHOLE 0xB000 BLACKHOLE_FROM_PEER 0xB001 BLACKHOLE_FROM_UPSTREAM 0xB002 SOURCE_BLACKHOLE 0xB003 SOURCE_DO_RPF 0xB004 Raszuk & Gredler Expires January 5, 2011 [Page 21] Internet-Draft wide-bgp-communities July 2010 HIGH_PRIORITY_PREFIX 0xB005 ATTACK_TARGET 0xB006 General_Free_Pool 0xB007..0xB07F NO_ADVERTISE 0xB080 ADVERTISE_TO 0xB081 ADVERTISE_NO_PEER 0xB082 ADVERTISE_NO_UPSTREAM 0xB083 ADVERTISE_NO_CUSTOMER 0xB084 ADVERTISE_TO_SET_NO_EXPORT 0xB085 Advertising_Free_Pool 0xB086..0xB0FF FROM_PEER 0xB100 FROM_CUSTOMER 0xB101 INTERNAL 0xB102 FROM_UPSTREAM 0xB103 FROM_IX 0xB104 LEARNED_FROM 0xB105 Marking_Free_Pool 0xB106..0xB17F PATH_HINT 0xB180 PATH_NEGATIVE_HINT 0xB181 Path_Control_Free_Pool 0xB182..0xB1FF PREPEND_BY 0xB201..0xB20F PREPEND_TO 0xB211..0xB21F PREPEND_UPSTREAM 0xB221..0xB22F PREPEND_PEERS 0xB231..0xB23F PREPEND_CUSTOMERS 0xB241..0xB24F REPLACE_BY 0xB250 AS_Path_Modify_Free_Pool 0xB251..0xB27F PEER_ROUTE 0xB280..0xB28F UPSTREAM_ROUTE 0xB290..0xB29F CUSTOMER_ROUTE 0xB2A0..0xB2AF Geo_Free_Pool 0xB2B0..0xB2FF LOCAL_PREF 0xB300..0xB30A Local_Pref_Unallocated 0xB30B..0xB30F AS_PATH_TTL 0xB310..0xB31F Free_Pool 0xB320..0xFFFF Raszuk & Gredler Expires January 5, 2011 [Page 22] Internet-Draft wide-bgp-communities July 2010 8. Contributors The following people contributed significantly to the content of the document: Bruno Decraene France Telecom 38-40 rue du General Leclerc 92794 Issi Moulineaux cedex 9 France Email: bruno.decraene@orange-ftgroup.com Shintaro Kojima OTEMACHI 1st. SQUARE EAST TOWER, 3F 1-5-1, Otemachi, Chiyoda-ku, Tokyo 100-0004 Japan Email: koji@mfeed.ad.jp Juan Alcaide Cisco Systems Research Triangle Park, NC United States Email: jalcaide@cisco.com Burjiz Pithawala Cisco Systems 170 West Tasman Dr San Jose, CA United States Email: bpithaw@cisco.com Saku Ytti TDC Oy Mechelininkatu 1a 00094 TDC Finland Email: ytti@tdc.net Raszuk & Gredler Expires January 5, 2011 [Page 23] Internet-Draft wide-bgp-communities July 2010 9. Acknowledgments Authors would like to thank Enke Chen, Keyur Patel, Pedro Marques and Alton Lo for their valuable input. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006. [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, February 2006. 10.2. Informative References [RFC1997] Chandrasekeran, R., Traina, P., and T. Li, "BGP Communities Attribute", RFC 1997, August 1996. [RFC1998] Chen, E. and T. Bates, "An Application of the BGP Community Attribute in Multi-home Routing", RFC 1998, August 1996. [RFC4384] Meyer, D., "BGP Communities for Data Collection", BCP 114, RFC 4384, February 2006. [RFC4893] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS Number Space", RFC 4893, May 2007. [RFC5668] Rekhter, Y., Sangli, S., and D. Tappan, "4-Octet AS Specific BGP Extended Community", RFC 5668, October 2009. Authors' Addresses Robert Raszuk Cisco Systems 170 West Tasman Drive San Jose, CA 95134 US Email: raszuk@cisco.com Raszuk & Gredler Expires January 5, 2011 [Page 24] Internet-Draft wide-bgp-communities July 2010 Hannes Gredler Juniper Networks 1194 N.Mathilda Ave Sunnyvale, CA 94089 US Email: hannes@juniper.net Raszuk & Gredler Expires January 5, 2011 [Page 25]