BGP Community Container Attribute

defines the BGP Community Attribute for BGP . 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 a set of one or more 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 opaque value. Since the introduction of , numerous additional mechanisms have been introduced to provide BGP Community-like functionality. Each of these mechanisms introduce a new syntax, typically covered by its encoding with the BGP Path Attribute that defines it, and a semantic space. The definition of a new BGP Path Attribute, with the ability to contain locally defined parameters enhances the current level of network policies, as well as simplify BGP policy management. The proposed encoding facilitates 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.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

This specification defines a new BGP Path Attribute, the BGP Community Container. It carries a series of BGP Community Container types, each prefaced with the BGP Community Container Common Header. The original version of this memo was created as part of for the BGP Community Container Common Header. This draft splits the BGP Community Container Common Header away from the Wide Communmity header.

The BGP Community Container Common Header permits Community-like attributes to be grouped under a single BGP Path Attribute. This provides a hierarchy for future Community-like features. It permits implementations without knowledge of a specific Community Container's format to address that Community Container by its code point. It also permits common enforcement of the Community Container's transitivity across AS boundaries without need for the implementation to understand a specific Container's implementation. This document defines the Community common container and proposes a registry for Common Container types. The following Container initial values for the container type are defined: Wide Community Container Type (0x01) ( FSv2 Action Container type (0x02) (

Propagation of BGP Community Containers is scoped to the administrative boundary. The definition of an administrative boundary consists of arbitrary set of connected ASes, possibly under control of a single entity. How such an administrative boundary is determined is out of scope of this document.

This document defines a new BGP Path Attribute, the BGP Community Container. The attribute type code is TBD1 (suggest using 34, existing BGP Community Path Attribute). The BGP Community Container attribute is an optional, transitive BGP attribute, and may be present only once in the BGP UPDATE message. The attribute contains a set of typed containers. Any given container type may appear multiple times, unless that container type's definition specifies otherwise. Each such container can have a unique propagation scope and can be subject to local filtering.

Containers always start with the following common 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 |T|C| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The BGP Community Container Common Header contains following encoding: 2 octets with the type of community container. The value zero is reserved. Flags control common behavior including the transitivity of the Container. Length of the Container header and content. This document defines the Community common container and proposes a registry for Common Container types. The following Container initial values for the container type are defined: Wide Community Container Type (0x00) ( FSv2 Action Container type (0x01) ( Routing Policy Type (0x02) {draft-ietf-idr-rpd) See the for information on additional type registration policies. Bit Value Meaning T0Not Transitive across administrative boundary. 1Transitive across AS and administrative boundary. C0Not transitive across confederation boundaries. 1Transitive across confederation boundaries. 3..7- RESERVED - MUST be zero when originated and SHOULD be ignored upon receipt. Flags are defined globally and apply to all container types. Bit 0 (T bit) Transitivity bit: When not set (value 0), the community in the container is not transitive across administrative boundary. When set (value 1), the community in the container is transitive across all administrative boundaries. Bit 1 (C bit) BGP Confederation bit: The confederation bit is used to manage the propagation scope of a given container across Member-AS confederation boundary. When not set (value 0) community is not transitive across confederation Member-AS boundary. When set (value of 1) indicates that community in a given container is transitive across Member-AS confederation boundary. The Reserved field MUST be set to zero when originated and SHOULD be ignored upon receipt. The Length field represents the total length (in octets) of a given container including its header.

Multiple mechanisms exist for an operator to propagate actions into the network. Besides BGP Wide Communities, an operator can use the BGP Community Attribute , the BGP Extended Communities Attribute , or the BGP Large Communities Attribute to achieve similar objectives. Care should be taken when using more than one of these tools. The interaction between the different community attributes is out of the scope of this document.

The "treat as withdraw" behavior MUST be executed for any malformed Community Containers, including their contents or presence of the BGP Community Container Attribute or given community TLV more then once in the BGP Update Message.

The security considerations for BGP Communities or BGP Extended Communities apply to BGP Community Containers. Transitive BGP Community Container communities could unintentionally spread far from their origin. If a router receives many routes from multiple sources on the Internet with different communities, it could cause significant processing burden or memory usage. To prevent this, it is RECOMMENDED that routers should be configured to strip unexpected communities from received routes.

All Registration Policies contained in this document are based on .

This document defines a new BGP Path Attribute called BGP Community Container Attribute. For this new type IANA is requested to allocate a new value in the corresponding registry: Registry Name: BGP Path Attributes This document makes the following assignments for the optional, transitive BGP Community Container Attribute:

Name value reference ---- ------ ------------- BGP Community Container Attribute TBD1 [this document] Since the original community definition used Attribute value was assigned via the original work, this work should reuse this attribute value.

This document requests IANA to define and maintain a new registry named: "BGP Community Container Types". The pool of: 0x0000..0xFFFF has been defined for its allocations.

Registration procedures: 0x0000 : Reserved. 0x0001-0x00FF : IETF Review. 0x0100-0xFF00 : First Come First Served. 0xFF01-0xFFFE : Experimental Use. 0xFFFF : Reserved.

Values: 0x0001 : BGP FSv2 Actions [this document] [draft-hares-ip-more-actions] 0x0002 : BGP routing policy [this document] distribution [draft-ietf-idr-rpd] 0x0003 : BGP Wide Communities [this document] [draft-ietf-idr-wide-bgp-communities]

The following people contributed significantly to the original Community attribute for the wide community.

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

Shane Amante Apple, Inc. 1 Infinite Loop Cupertino, CA, 95014 USA amante@apple.com

Shane Amante Paul Jakma Huawei Ireland Research Centre Georges Court,Dublin D02 R156 Ireland paul@jakma.org

Andrew Lange Nokia 777 E. Middlefield Road Mountain View, CA 94043 USA andrew.lange@nokia.com

Bruno Decraene Orange bruno.decraene@orange.com

Robert Raszuk Arrcus 2077 Gateway Place San Jose, CA 95110 USA robert@raszuk.net

Jeffrey Haas Juniper Networks 1194 N.Mathilda Ave Sunnyvale, CA 94089 USA jhaas@juniper.net

This document owes draft-lange-flexible-bgp-communities a debt for the inspiration of many features contained herein.