IDR Working Group R. Raszuk, Ed. Internet-Draft Cisco Systems Intended status: Standards Track J. Haas, Ed. Expires: January 12, 2012 Juniper Networks S. Amante Level 3 Communications, LLC R. Steenbergen nLayer Communications, Inc. B. Decraene France Telecom P. Jakma Uni. of Glasgow July 11, 2011 Wide BGP Communities Attribute draft-raszuk-wide-bgp-communities-02 Abstract Route tagging plays an important role in external BGP relations, in communicating various routing policies between peers. It is also a very common best practice among operators to propagate various additional information about routes intra-domain. The most common tool used today to attach various information about routes is through the use of BGP communities. Such information is important to allow BGP speakers to perform some mutually agreed upon actions without the need to maintain a separate offline database for each tuple of prefix and associated set of action entries. This document defines a new encoding which will enhance and simplify what can be accomplished today with the use of BGP communities. The most important addition this specification makes over currently defined BGP communities is the ability to specify, carry as well as use for execution an operator's defined set of parameters. It also provides an extensible platform for any new community encoding needs in the future. 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- Raszuk, et al. Expires January 12, 2012 [Page 1] Internet-Draft wide-bgp-communities July 2011 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." This Internet-Draft will expire on January 12, 2012. Copyright Notice Copyright (c) 2011 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, et al. Expires January 12, 2012 [Page 2] Internet-Draft wide-bgp-communities July 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Wide BGP Community Attribute . . . . . . . . . . . . . . . . . 4 2.1. Wide BGP Community Attribute Container Header . . . . . . 5 2.2. Wide Community Atoms . . . . . . . . . . . . . . . . . . . 6 3. Container Type 1: Wide Community . . . . . . . . . . . . . . . 7 3.1. Community Value . . . . . . . . . . . . . . . . . . . . . 8 3.2. Source AS Number . . . . . . . . . . . . . . . . . . . . . 8 3.3. Target AS Number . . . . . . . . . . . . . . . . . . . . . 8 3.4. Wide Community Target(s) TLV . . . . . . . . . . . . . . . 8 3.5. Wide Community Parameter(s) TLV . . . . . . . . . . . . . 9 3.6. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4. Well Known Standard BGP Communities . . . . . . . . . . . . . 10 5. Operational considerations . . . . . . . . . . . . . . . . . . 10 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6.1. Example Wide Community Definition . . . . . . . . . . . . 11 6.2. Example Wide Community Encoding . . . . . . . . . . . . . 11 7. Security considerations . . . . . . . . . . . . . . . . . . . 13 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 9. Change History . . . . . . . . . . . . . . . . . . . . . . . . 14 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 12.1. Normative References . . . . . . . . . . . . . . . . . . . 15 12.2. Informative References . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Raszuk, et al. Expires January 12, 2012 [Page 3] Internet-Draft wide-bgp-communities July 2011 1. Introduction RFC 1997 [RFC1997] defines the BGP Community Attribute. This attribute is used as a tool to carry additional information in BGP routes which may help to automate peering administration. The BGP Communities Attribute consists of one or more sets of four octet values, where each specifies a different community. Except for two reserved ranges, the encoding of community values mandates that the first two octets are to contain the Autonomous System number, with the next two octets containing some 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. While the encoding of 4 octet AS numbers is being addressed by [draft-ietf-idr-as4octet-extcomm-generic-subtype], neither the base BGP communities (standard or extended) nor as4octet-extcomm-generic document define a sufficient level of encoding freedom which could be of practical use. The authors believe that defining a new BGP Path Attribute, with the ability to contain locally defined parameters will enhance the current level of network policies, as well as simplify BGP policy management. The proposed simple encoding will also facilitate the delivery of new network services without a need to define a new BGP extension each time. When defining any new type of tool there is always a unique opportunity to specify a subset of well recognized behaviors. Lists of the current most commonly used BGP communities, as well as provision for a new registry for future definitions will be contained in a separate document. 2. Wide BGP Community Attribute This document defines a new BGP Path Attribute, the Wide BGP Community. The attribute type code is (TBA by IANA). The Wide BGP Community Attribute is an optional, transitive BGP attribute, and may be present only once in the update message. The attribute contains a number of typed containers. Any given container type may appear multiple times, unless that container type's definition specifies otherwise. Raszuk, et al. Expires January 12, 2012 [Page 4] Internet-Draft wide-bgp-communities July 2011 2.1. Wide BGP Community Attribute Container Header Containers always start with the following header: 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 | Flags | TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +------+-------+----------------------------------------------------+ | Bit | Value | Meaning | +------+-------+----------------------------------------------------+ | 0 | 0 | Local community value. | | | 1 | Registered community value. | | 1 | 0 | Do not decrement TTL field across confederation | | | | boundaries. | | | 1 | Decrement TTL field across confederation | | | | boundaries. | | 2..7 | - | SHOULD be zero. | +------+-------+----------------------------------------------------+ Flags are defined globally, to apply to all wide community container types. Table 1: Flags Bit 0 set (value 1) indicates that the given container carries a Wide BGP Community which is registered with IANA. When not set (value 0) it indicates that community value which follows is locally assigned with a local meaning. Ignored bits SHOULD be preserved in any received containers, or set to 0 otherwise. Bit 1 is used to manage the propagation scope of a given Wide BGP Community across confederation boundaries. When not set (value of 0), the TTL field is not considered at the sub-AS boundaries. When set (value of 1), sub-AS border router follows the same procedure regarding the handling of the TTL field as applicable to ASBR at the domain boundary. The TTL field represents the forwarding radius, in units of AS hops, for the given Wide BGP Community. A TTL value of zero indicates that this wide community must not cross any further AS boundaries. At each AS boundary, when propagating a given wide community over an EBGP session, the TTL field MUST be decremented by the sending EBGP Raszuk, et al. Expires January 12, 2012 [Page 5] Internet-Draft wide-bgp-communities July 2011 speaker. The exact same decrement procedures described above apply also to sub-confederation boundaries when the global C flag is set to 1. The special value of 0xFF indicates that the enclosed community may always be propagated over an EBGP boundary. A TTL value of 0xFF MUST NOT be decremented during propagation. The length represents the total lengths of a given container in octets. 2.2. Wide Community Atoms Wide BGP communities will act on and hence need to encode some distinct atoms of data. These are encoded as Sub-TLVs, where each Sub-TLV has the following format: 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 +-+-+-+-+-+-+-+-+ | Sub-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Sub-Type field contains a value of 0-254. The value 255 is reserved for future use. The sub-TLV types are to be assigned and maintained by IANA registry. The length represents the total length of a given sub-TLV in octets. The value field contains the sub-TLV value. Supported format of the sub-TLVs can be: Raszuk, et al. Expires January 12, 2012 [Page 6] Internet-Draft wide-bgp-communities July 2011 - Type 1: 4 octets : Autonomous System number - Type 2: 1..5 octets : IPv4 prefix (1 octet prefix length + prefix) - Type 3: 1..17 octets : IPv6 prefix (1 octet prefix length + prefix) - Type 4: 1..4 octets : Integer - Type 5: variable : UTF-8 String - Type 6: 4 octets : IEEE Floating Point Number - Type 7: variable : Grouping Container (for logical AND) The semantics of a given atom will depend on the context it is used as defined by the containing wide community. For consistent treatment, all AS numbers MUST be encoded as 4 octet values. When encoding a two octet ASes, the first two octets of this four octet value MUST be filled with zeros. Two special values are reserved for the Autonomous System atom: 0x00000000 - to indicate "No Autonomous Systems". 0xFFFFFFFF - to indicate "All Autonomous Systems". The Grouping Container is intended for use for Wide Community Targets. Targets typically have a "match any" behavior. When a Grouping Container is present in a target, all contained atoms must match for the community to be applied. 3. Container Type 1: Wide Community Wide BGP Community Type 1 container is of variable size and 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Registered/Local Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source AS Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Target AS Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Wide Community Target(s) TLV (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Wide Community Parameter(s) TLV (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Wide BGP Community Type 1 Raszuk, et al. Expires January 12, 2012 [Page 7] Internet-Draft wide-bgp-communities July 2011 3.1. Community Value Community Value: 4 octets The Wide BGP Community value indicates what set of actions a router is requested to take upon reception of a route containing this community. The semantics of this value depend on whether this is a private/local community (when R is 0) or registered (when R is 1). 3.2. Source AS Number Source Autonomous System Number: 4 octets The Autonomous System number which indicates the originator of this Wide BGP Community. When the Autonomous System is a two octet number the first two octets of this 4 octet value MUST be filled with zeros. 3.3. Target AS Number Target Autonomous System Number: 4 octets The Autonomous System number that indicates the context of the Registered/Local Value. When the value is a Registered Value (and thus registered with IANA), this field MUST be 0. When the wide community is locally registered, the Target Autonomous System Number indicates the AS that defines the format of this wide community for the given Local Value. (In other words, value 1 will likely refer to different formats for AS 1 vs. AS 2.) 3.4. Wide Community Target(s) TLV Type: 1 The Wide Community Target(s) TLV has the same format as a Wide Community atom. Wide Community Targets define the matching criteria for the community. A given wide community may have a number of targets that it applies to. The semantics of these targets will vary on a per community basis. Depending on the definition of the community, targets may be optional. The value field of the Wide Community Target(s) TLV is a series of Raszuk, et al. Expires January 12, 2012 [Page 8] Internet-Draft wide-bgp-communities July 2011 Wide Community Atom TLVs. The semantics of any given atom TLV MUST be part of the definition of a given Wide Community. Typically, Wide Community Targets consist of a series of atoms that have "match any" semantics. Thus, if any given target matches per the semantics of that atom for the community, the community is considered to match and the action defined by the community should be executed. The Grouping Container atom permits a set of atoms with semantics defined by the community to be nested. The Grouping Container atom is considered to be a matching target if, and only if, all of its contained atoms match per the semantics of the community. If the semantics of a given atom is undefined for the community in question, it MUST be ignored. If an atom with undefined semantics is part of a Grouping Container, the entire container MUST be ignored. When no targets are required by the definition of a given Wide Community, the Wide Community Target TLV SHOULD NOT be encoded in the community. Implementations MUST be prepared to accept a Wide Community Target TLV with an empty value field. 3.5. Wide Community Parameter(s) TLV Type: 2 The Wide Community Parameter(s) TLV has the same format as a Wide Community atom. A given wide community may have parameters which are used as inputs for executing actions defined for that community. These parameters, and any constraints implied by the parameters, MUST be defined by the wide community definition. Parameters consist of an ordered set of atom sub-TLVs. The semantics of any specific positional instance of an atom MUST be defined by the wide community. If it is the case that a paramter for a given community is of an unexpected type, the community MUST be ignored. If it is the case that there are too many or two few parameters for a given community, the community MUST be ignored. When no parameters are required by the definition of a given Wide Community, the Wide Community Paramters TLV SHOULD NOT be encoded in the community. Implementations MUST be prepared to accept a Wide Community Parameter TLV with an empty value field. Raszuk, et al. Expires January 12, 2012 [Page 9] Internet-Draft wide-bgp-communities July 2011 3.6. Usage The detailed interpretation of the targets or parameters SHALL be provided when describing given community type in a separate document or when locally defined by an operator. 4. Well Known Standard BGP Communities According to RFC 1997, as well as IANA's Well-Known BGP Communities registry, 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. For the same reason, this document does not intended to obsolete the currently defined and deployed BGP Extended Communities. 5. Operational considerations Having two different ways to propagate locally assigned BGP communities, one via the use of Standard BGP Communities and the other one via the use of Wide BGP Communities, may seem to potentially cause problems when considering propagation of conflicting actions. However, even at present, an operator may append Standard BGP Communities with conflicting information. It is therefore recommended that any implementation, in supporting both standard and Wide BGP communities, allow for their easy inbound and outbound processing. The actual execution of all communities should be treated as a union and, if supported by an implementation, their execution permissions are to be a local configuration matter. 6. Example Raszuk, et al. Expires January 12, 2012 [Page 10] Internet-Draft wide-bgp-communities July 2011 6.1. Example Wide Community Definition An operator wishes to locally define a Wide Community with the semantics of permitting AS_PATH prepending with targets that include AS numbers of peer ASes and peers who have been marked with a set of defined "color" strings. Target semantics: Grouping containers MAY be used. The Autonomous System Number atom refers to the target peer AS Number. The UTF-8 String atom refers to a peer "color". The values are constrained to the strings "red", "green" or "blue". The semantics of all other atoms are undefined for this community. Parameter semantics: The parameter TLV shall consist of exactly one integer value that is constrained to have a value of 2..8. 6.2. Example Wide Community Encoding AS_PATH prepend 4 TIMES TO AS 2424, AS 8888, to peers marked as "red" or to peers marked "blue" AND AS 1111. Use TTL 0 to request the receiving router to not propagate this wide community. Locally community value (flag bit 0 = 0). Do not decrement TTL field across confederation boundaries (0) Local community 1 for sample AS 64512. Raszuk, et al. Expires January 12, 2012 [Page 11] Internet-Draft wide-bgp-communities July 2011 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Container Type 1 (1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 0| +-+-+-+-+-+-+-+-+ | TTL: 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length: 34 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Community: LOCAL PREPEND ACTION CATEGORY 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Own ASN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Target ASN# 64512 (0x0000FC00) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Target TLV (1)| Length: 23 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type ASN (1) | Length: 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Target ASN# 2424 (0x00000978) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type ASN (1) | Length: 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Target ASN# 8888 (0x000022B8) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type Str (5) | Length: 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peer color "red" | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Target Grp (7)| Length: 12 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type Str (5) | Length: 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peer color "blue" | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type ASN (1) | Length: 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Target ASN# 1111 (0x00000457) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Param TLV (2) | Length: 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type INT (4) | Length: 1 | Prepend #: 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Raszuk, et al. Expires January 12, 2012 [Page 12] Internet-Draft wide-bgp-communities July 2011 7. Security considerations All the security considerations for BGP Communities as well as for BGP RFCs apply here. 8. IANA Considerations This document defines a new BGP Path Attribute called Wide BGP Community Attribute. For this new type IANA is to allocate a new value in the corresponding registry: Registry Name: BGP Path Attributes This document makes the following assignments for the optional, transitive Wide BGP Communities Attribute: Name Type Value ---- ---------- Wide BGP Community Attribute TBA This document requests IANA to define and maintain a new registry named: "Wide BGP Communities Attribute Container Types". The pool of: 0x0000-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 Wide BGP Communities Attribute Types values: Name Type Value ---- ---------- Reserved 0x0000 Type 1 0x0001 Types 2-1023 to be allocated using IETF Consensus Types 1024-64511 to be allocated first come, first served Types 64512-65534 are reserved for experimental use Reserved 0xFFFF This document requests IANA to define and maintain a new registry named: "Wide BGP Communities sub-TLV types". The pool of 0x0000- 0xFFFF has been defined for its allocations. This document defines type 1. Types 2-1024 are to be allocated using an IETF Consensus policy. Types 1024-64511 are to be allocated on a first come, first served basis. Types 64512-65534 are to be reserved for experimental Raszuk, et al. Expires January 12, 2012 [Page 13] Internet-Draft wide-bgp-communities July 2011 use. This document makes the following assignments for the Wide BGP Communities sub-TLV type values: Name Type Value ---- ---------- Reserved 0x00 AS Number 0x01 IPv4 Prefix 0x02 IPv6 Prefix 0x03 Integer 0x04 UTF-8 string 0x05 IEEE Floating Point Value 0x06 Container Group 0x07 Reserved 0xFF 9. Change History Changes since from -01 to -02: The Type field has been expanded to 2 octets. The Length field has been moved to the common header. Changed format to use TLVs. Added atom TLV to define well defined syntactic items. Added TLVs to distinguish targets from parameters. Various editorial changes to language. 10. Contributors The following people contributed significantly to the content of the document: Raszuk, et al. Expires January 12, 2012 [Page 14] Internet-Draft wide-bgp-communities July 2011 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 11. Acknowledgments Authors would like to thank Enke Chen, Pedro Marques and Alton Lo for their valuable input. 12. References 12.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 Raszuk, et al. Expires January 12, 2012 [Page 15] Internet-Draft wide-bgp-communities July 2011 Communities Attribute", RFC 4360, February 2006. 12.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 (editor) Cisco Systems 170 West Tasman Drive San Jose, CA 95134 US Email: raszuk@cisco.com Jeffrey Haas (editor) Juniper Networks 1194 N.Mathilda Ave Sunnyvale, CA 94089 US Email: jhaas@juniper.net Raszuk, et al. Expires January 12, 2012 [Page 16] Internet-Draft wide-bgp-communities July 2011 Shane Amante Level 3 Communications, LLC 1025 Eldorado Blvd Broomfield, CO 80021 US Email: shane@level3.net Richard A Steenbergen nLayer Communications, Inc. 209 W Jackson Blvd Chicago, IL 60606 US Email: ras@nlayer.net Bruno Decraene France Telecom 38-40 rue du General Leclerc Issi Moulineaux cedex 9 92794 France Email: bruno.decraene@orange-ftgroup.com Paul Jakma University of Glasgow School of Computing Science Sir Alwyn Williams Building University of Glasgow Glasgow G12 8QQ UK Email: paulj@dcs.gla.ac.uk Raszuk, et al. Expires January 12, 2012 [Page 17]