IDR Working Group R. Raszuk Internet-Draft Cisco Systems Intended status: Standards Track J. Haas Expires: April 19, 2011 Juniper Networks R. Steenbergen nLayer Communications, Inc. B. Decraene France Telecom P. Jakma DCS, Uni. of Glasgow October 16, 2010 Wide BGP Communities Attribute draft-raszuk-wide-bgp-communities-01 Abstract Communicating various routing policies via route tagging plays an important role in external BGP peering relations. 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 realized with the use of BGP communities. Such information is important for the BGP speakers 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. 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 brings over currently defined BGP communities is the ability to specify, carry as well as use for execution operator's defined set of parameters. Specification 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- Drafts is at http://datatracker.ietf.org/drafts/current/. Raszuk, et al. Expires April 19, 2011 [Page 1] Internet-Draft wide-bgp-communities October 2010 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 April 19, 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, et al. Expires April 19, 2011 [Page 2] Internet-Draft wide-bgp-communities October 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Wide BGP Community Attribute . . . . . . . . . . . . . . . . . 4 3. Wide BGP Community Attribute Containers . . . . . . . . . . . 5 3.1. Fixed size container template . . . . . . . . . . . . . . 6 3.2. Variable size container template . . . . . . . . . . . . . 6 4. Container Type 1: Wide Community . . . . . . . . . . . . . . . 7 4.1. Container Type 1 - TTL . . . . . . . . . . . . . . . . . . 7 4.2. Container Type 1 - Length . . . . . . . . . . . . . . . . 8 4.3. Container Type 1 - Community Value . . . . . . . . . . . . 8 4.4. Container Type 1 - Source AS number . . . . . . . . . . . 8 4.5. Container Type 1 - Community Parameters . . . . . . . . . 8 5. Well Known Standard BGP Communities . . . . . . . . . . . . . 9 6. Operational considerations . . . . . . . . . . . . . . . . . . 9 7. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. Security considerations . . . . . . . . . . . . . . . . . . . 11 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 12 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 12.1. Normative References . . . . . . . . . . . . . . . . . . . 13 12.2. Informative References . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Raszuk, et al. Expires April 19, 2011 [Page 3] Internet-Draft wide-bgp-communities October 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. While encoding of 4 octet AS numbers are being addressed by [draft-ietf-idr-as4octet-extcomm-generic-subtype] neither the base BGP communities (both standard or extended) nor as4octet-extcomm- generic document define sufficient level of encoding freedom which could be of practical use. Authors believe that defining a new BGP Path Attribute which will provide ability to contain locally defined parameters will enhance current level of network policies as well as simplify BGP policy management. Proposed simple encoding will also enable to deliver a set of new network services without a need to define a new BGP extension each time. While defining a new type of any tool there is always a unique opportunity to specify a subset of well recognized behaviors. List of the most commonly used today 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 For the purposes of encoding for Wide BGP Communities a new BGP Path Attribute has been defined. The attribute type code is of the value (TBC by IANA). 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, which are either fixed or variable in size. Any given container type may appear multiple times, unless that container type's definition says Raszuk, et al. Expires April 19, 2011 [Page 4] Internet-Draft wide-bgp-communities October 2010 otherwise. 3. Wide BGP Community Attribute Containers Two container templates are defined for carrying BGP community information, to hold fixed or variably sized data. All container definitions MUST conform with one of these two templates. Containers always start with the following header: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Container header Flags are defined globally, to apply to all community container types. Bit 0: 0 => local community value 1 => registered community value 1: 0 => do not decrement TTL field across confederation boundaries 1 => decrement TTL across confederation boundaries 2...7: => ignored, preserve or set to zero. 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 propagation scope of given community across confederation boundaries. When not set (value of 0) TTL field is not consider at the sub-AS boundaries. When set (value of 1) sub-AS border router follows the same procedure reg handling TTL field as applicable to ASBR at the domain boundary. Raszuk, et al. Expires April 19, 2011 [Page 5] Internet-Draft wide-bgp-communities October 2010 3.1. Fixed size container template 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 | Value - fixed size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Fixed size type container 3.2. Variable size container template 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 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value ..... | Figure 4: Variable size type container (TLV Format) Raszuk, et al. Expires April 19, 2011 [Page 6] Internet-Draft wide-bgp-communities October 2010 4. 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 +-+-+-+-+-+-+-+-+ | 0x01 | +-+-+-+-+-+-+-+-+ |R C 0 0 0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source AS number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Registered/Local value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Parameter/s (optional, variable)... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R is the value of the registered/local bit. C is the value indicating how to treat TTL field across confederation boundaries. Figure 4: Wide BGP Community Type 1 4.1. Container Type 1 - TTL TTL: 1 octet This field represents the forwarding radius in the unit of AS hops for given Wide BGP Community. At each AS boundary when propagating given community over an EBGP session the TTL field must be decremented by value of 1 by the sending EBGP speaker. TTL with value of zero received to the ASBR over IBGP session indicates that this community must not cross an AS boundary. The special value of 0xFF indicates that the enclosed community may be always propagated over EBGP boundary. Value of 0xFF must not be decremented during propagation. The exact same procedures as described above applies also to sub- confederation boundaries when the global C flag is set to 1. Raszuk, et al. Expires April 19, 2011 [Page 7] Internet-Draft wide-bgp-communities October 2010 4.2. Container Type 1 - Length The length represents the total lengths of a given container in octets. The minimum length when no optional parameters are attached is 13 octets. 4.3. Container Type 1 - Community Value Community Value: 2 octets The Wide BGP Community value encoded in this field indicates private/local 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 BGP communities. 4.4. Container Type 1 - Source AS number Source Autonomous System number: 4 octets The Autonomous System number which indicates the originator of given Wide BGP Community. When Autonomous System is a two octet number the first two octets of this 4 octet value are to be filled with zeros. 4.5. Container Type 1 - Community Parameters Parameters: variable size Community parameter are defined to contain additional data for execution of given BGP community. Community parameter field could consist of an autonomous system number(s) which should be conditionally compared when executing given community, AS PATH prepend count to be added, local preference value to be inserted under some conditions, markers indicating number of BGP speakers traversed, cumulative IGP metrics to be used for transparent redistribution, etc... For consistent Autonomous System treatment all encoded AS numbers SHOULD be encoded as 4 octet values. When such AS 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 Parameter Autonomous System number field: 0x00000000 - to indicate "None of Autonomous Systems" and value of 0xFFFFFFFF - to indicate "All of Autonomous Systems". Raszuk, et al. Expires April 19, 2011 [Page 8] Internet-Draft wide-bgp-communities October 2010 The detailed interpretation of each set of parameters will be provided when describing given community type in a separate document or when locally defined by an operator. 5. 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. For the same reason the described registry does not intended to obsolete BGP Extended Community Attribute and any already defined and already deployed extended communities. 6. 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 Raszuk, et al. Expires April 19, 2011 [Page 9] Internet-Draft wide-bgp-communities October 2010 which are predefined as range of values - only use of one value of selected range is allowed. 7. Example An operator wishes to tag incoming routes with a policy specifying that during their advertisement to two peering ASes 2424 and 8888 or during their advertisement to peers marked as RED (0xFF0000) the routes carrying such community will be advertised with AS_PREPEND equal to 4. That can be easily accomplished by locally defining by an operator a new wide community value using type 1 proposed encoding as below: PREPEND 4 TIMES TO AS 2424 or 8888 or to peers marked as RED TTL - 0x00 LENGTH - 26 octets VALUE - 01 / 0x12 PARAMETERS - 2 x 4 octets AS number 1 x class of peers 1 octet prepend's number Raszuk, et al. Expires April 19, 2011 [Page 10] Internet-Draft wide-bgp-communities October 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 +-+-+-+-+-+-+-+-+ | 0x1 | +-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length: 26 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TTL: 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Own ASN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Community: LOCAL PREPEND ACTION CATEGORY I | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Target ASN# 2424 (0x00000978) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Target ASN# 8888 (0x000022B8) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peer color RED 0x00FF0000 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prepend #: 4 | +-+-+-+-+-+-+-+-+ 8. Security considerations All the security considerations for BGP Communities as well as for BGP RFCs apply here. 9. IANA Considerations This document defines a new BGP Path Attribute called Wide BGP Communities Attribute. For this new type IANA is to allocate new type value in the corresponding registry: Registry Name: BGP Path Attributes This document makes the following assignments for the optional, transitive Wide BGP Communities Attribute: Raszuk, et al. Expires April 19, 2011 [Page 11] Internet-Draft wide-bgp-communities October 2010 Name Type Value ---- ---------- Wide BGP Community Attribute 27 This document requests IANA to define and maintain a new registry named: "Wide BGP Communities Attribute Container Types". The pool of: 0x00-0xFF 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 0x00 Type 1 0x01 Types 2-254 to be allocated on FCFS basis Reserved 0xFF 10. Contributors The following people contributed significantly to the content of the document: 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 Raszuk, et al. Expires April 19, 2011 [Page 12] Internet-Draft wide-bgp-communities October 2010 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 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 Raszuk, et al. Expires April 19, 2011 [Page 13] Internet-Draft wide-bgp-communities October 2010 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 Jeffrey Haas Juniper Networks 1194 N.Mathilda Ave Sunnyvale, CA 94089 US Email: jhaas@pfrc.org 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 Raszuk, et al. Expires April 19, 2011 [Page 14] Internet-Draft wide-bgp-communities October 2010 Paul Jakma School of Computing Science, Uni. of Glasgow Sir Alwyn Williams Building University of Glasgow Glasgow G1 5AE UK Email: paulj@dcs.gla.ac.uk Raszuk, et al. Expires April 19, 2011 [Page 15]