| Internet-Draft | BGP Community Container | October 2024 |
| Hares | Expires 7 April 2025 | [Page] |
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. Two initial use cases are wide communities and flow specification version 2 (FSv2) actions upon a filter match.¶
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 https://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 7 April 2025.¶
Copyright (c) 2024 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 (https://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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
[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.¶
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.¶
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.¶
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 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 TBD.¶
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:¶
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]¶
See the Section 7 for information on additional type registration policies.¶
| 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.¶
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.¶
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.¶
The security considerations for BGP Communities [RFC1997] or BGP Extended Communities [RFC4360] 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 [RFC8126].¶
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 Type Value ---- ---------- BGP Community Container Attribute TBD [this document]¶
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 Wide Community [this document]
0x0002 : BGP FSv2 Actions [this document]
¶
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.¶