BGP Community Container Attribute
Susan Hares, Ed.
Huawei
Ann Arbor
MI
48176
USA
shares@ndzh.com
2024
Routing Area
IDR Working Group
I-D
Internet-Draft
IDR
BGP
Route tagging plays an important role in external BGP (RFC4271) relations for communicating various routing policies between peers. It is also a 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 (original, extended or large).
This document defines a new flexible Community encoding in a BGP Attribute that enhances what can be accomplished with BGP communities. Three initial use cases for this are flow specification version 2 (FSv2) actions, routing policy distribution (rpd) actions, and wide communities.

Introduction
[RFC1997] defines the BGP Community Attribute for BGP [RFC4271]. 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 [RFC1997], 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.

Requirements Language
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

Protocol Summary
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 [I-D.ietf-idr-wide-bgp-communities] for the BGP Community Container Common Header. This draft splits the BGP Community Container Common Header away from the Wide Communmity header.

BGP Community Container Common 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) ([I-D.ietf-idr-wide-bgp-communities]
FSv2 Action Container type (0x02) ([I-D.hares-idr-fsv2-more-ip-actions]

Propagation of BGP Community Containers
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.

BGP Community Container Attribute
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.

BGP Community Container Attribute Common Header

Common container header
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:
Container Type:
2 octets with the type of community container. The value zero is reserved.
Flags:
Flags control common behavior including the transitivity of the Container.
Length:
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) ([I-D.ietf-idr-wide-bgp-communities]
- FSv2 Action Container type (0x01) ([I-D.hares-idr-fsv2-more-ip-actions]
- Routing Policy Type (0x02) {draft-ietf-idr-rpd)
See the Section 7 for information on additional type registration policies.

Flags
Bit | Value | Meaning
T | 0 | Not Transitive across administrative boundary.
| 1 | Transitive across AS and administrative boundary.
C | 0 | Not transitive across confederation boundaries.
| 1 | Transitive 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 [RFC3065] 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.

Operational Considerations
Multiple mechanisms exist for an operator to propagate actions into the network. Besides BGP Wide Communities, an operator can use the BGP Community Attribute [RFC1997], the BGP Extended Communities Attribute [RFC4360], or the BGP Large Communities Attribute [RFC8092] 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.

Error Handling

General Error Handling for BGP Community Containers
The "treat as withdraw" behavior [RFC7606] 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.

Security considerations
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.

IANA Considerations
All Registration Policies contained in this document are based on [RFC8126].

BGP Community Container Attribute
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.

BGP Community Container Values
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]

Contributors
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

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

Normative References

Informative References
[RFC1997]
[RFC4271]
[RFC2119]
[RFC8174]
[I-D.ietf-idr-wide-bgp-communities]
[I-D.hares-idr-fsv2-more-ip-actions]
[RFC3065]
[RFC4360]
[RFC8092]
[RFC7606]
[RFC8126]