Canonical textual representation of BGP Path Attributes
draft-marenamat-idr-bgp-attribute-formatting-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Maria Matějka | ||
| Last updated | 2026-05-30 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources |
GitHub Repository
|
||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-marenamat-idr-bgp-attribute-formatting-00
Inter-Domain Routing M. Matejka
Internet-Draft CZ.NIC
Intended status: Best Current Practice 30 May 2026
Expires: 1 December 2026
Canonical textual representation of BGP Path Attributes
draft-marenamat-idr-bgp-attribute-formatting-00
Abstract
Various implementations of the Border Gateway Protocol (BGP) use
different formats for displaying the Path Attributes. This document
defines the preferred textual formatting which is recommended for the
implementations to use for human interfaces.
To achieve consistent value formatting, this document formally
updates RFC 9026 by canonicalizing the well-known community name
formats.
This document updates RFC 4360, RFC 4577, RFC 7432, and ... by
specifying the canonical textual formatting of extended communities
specified there.
About This Document
This note is to be removed before publishing as an RFC.
The latest revision of this draft can be found at
https://marenamat.github.io/ietf-draft-marenamat-idr-bgp-attribute-
formatting/draft-marenamat-idr-bgp-attribute-formatting.html. Status
information for this document may be found at
https://datatracker.ietf.org/doc/draft-marenamat-idr-bgp-attribute-
formatting/.
Discussion of this document takes place on the Inter-Domain Routing
Working Group mailing list (mailto:idr@ietf.org), which is archived
at https://mailarchive.ietf.org/arch/browse/idr/. Subscribe at
https://www.ietf.org/mailman/listinfo/idr/.
Source for this draft and an issue tracker can be found at
https://github.com/marenamat/ietf-draft-marenamat-idr-bgp-attribute-
formatting.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Matejka Expires 1 December 2026 [Page 1]
Internet-Draft Canonical textual representation of BGP May 2026
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 1 December 2026.
Copyright Notice
Copyright (c) 2026 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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3
3. Simple Path Attributes . . . . . . . . . . . . . . . . . . . 3
4. AS_PATH Attribute . . . . . . . . . . . . . . . . . . . . . . 4
5. COMMUNITIES Attribute . . . . . . . . . . . . . . . . . . . . 4
6. EXTENDED_COMMUNITIES Attribute . . . . . . . . . . . . . . . 5
6.1. Display format for AS-Specific and IPv4-Specific Type
values . . . . . . . . . . . . . . . . . . . . . . . . . 5
6.2. Display format for Opaque Extended Community (Type 0x03 and
0x43) . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6.2.1. Default Gateway Extended Community . . . . . . . . . 6
6.3. Display format for EVPN Extended Communities (Type
0x06) . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6.3.1. ESI Label Extended Community . . . . . . . . . . . . 6
6.3.2. ES-Import Route Target Extended Community . . . . . . 6
6.3.3. MAC Mobility Extended Community . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8.1. BGP Well-known Communities . . . . . . . . . . . . . . . 7
8.2. Registries for BGP Extended Communities . . . . . . . . . 7
Matejka Expires 1 December 2026 [Page 2]
Internet-Draft Canonical textual representation of BGP May 2026
8.2.1. EVPN Extended Community Sub-Types . . . . . . . . . . 7
8.2.2. Transitive Two-Octet AS-Specific Extended Community
Sub-Types . . . . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . 9
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
Over 30 years of BGP existence have created a difference in router
user interfaces. While diversity is a good thing, displaying the
same route attributes differently leads to user confusion and
elevated need for learning vendor specifics. With the advent of
APIs, often based on NETCONF and YANG, a need for canonical
representation has arised.
While most attributes are either a value, or a structure of values,
which can be easily modeled by YANG, with complex attributes like
extended communities, there is a lot of subvariants and semantics in
their values. Users and implementations usually format these values
in a structured form which is hard to be modeled by YANG.
This document aims to summarize all of these in one place and
specifies a standard way of defining canonical formatting for new BGP
path attributes.
Deprecated and historic attributes are out of scope of this document.
2. Conventions and Definitions
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.
3. Simple Path Attributes
The following attributes, are listed simply for the sake of
completeness. Their formatting is simple and easy to model
coherently.
* Type 1 - ORIGIN
* Type 3 - NEXT_HOP
Matejka Expires 1 December 2026 [Page 3]
Internet-Draft Canonical textual representation of BGP May 2026
* Type 4 - MULTI_EXIT_DISC (MED)
* Type 5 - LOCAL_PREF
* Type 6 - ATOMIC_AGGREGATE
* Type 7 - AGGREGATOR
* Type 9 - ORIGINATOR_ID
* Type 10 - CLUSTER_LIST
4. AS_PATH Attribute
The AS_PATH attribute contains segments of ASN values. While this
attribute is technically possible to be modelled coherently by YANG,
there are situations where the AS_PATH value is expected to be
rendered as a whole. In such cases, the contents of each segment
SHOULD be displayed as decimal values separated by single spaces
(ASCII 32).
In addition to that, boundary between two AS_SEQUENCE segments MAY be
delimited by | (ASCII 124), and AS_CONFED_SEQUENCE SHOULD be
parenthesized (ASCII 40 and 41).
Example: (65501 65502) 65503 65504 | 65505 65506 65506 65506
This would be an AS_CONFED_SEQUENCE of 65501 and 65502 followed by
AS_SEQUENCE of 65503 and 65504, and another AS_SEQUENCE containing
65505 and then 65506 three times.
TODO: ABNF here?
5. COMMUNITIES Attribute
The COMMUNITIES attribute [RFC1997] is a set of uint32 values, which
are semantically a pair of an AS number and an arbitrary uint16
value. Following the syntax used in [RFC8642] and in vast majority
of current implementations, the value SHOULD be formatted as two
decimal values with no leading zeros, joined by a single colon (ASCII
58) with no whitespace.
In addition to that, it is RECOMMENDED to format well-known
communities as their string name.
For the sake of formatting consistency, the "Standby PE" as defined
in [RFC9026] is hereby renamed to STANDBY_PE. The semantics stays
the same.
Matejka Expires 1 December 2026 [Page 4]
Internet-Draft Canonical textual representation of BGP May 2026
TODO: ABNF here?
6. EXTENDED_COMMUNITIES Attribute
The EXTENDED_COMMUNITIES attribute [RFC4360] is a set of uint64
values with a complicated structure. Copying a modified schema from
Section 2 of [RFC4360], the Type denotes how the value is further
split into sub-values, and the Sub-Type denotes the meaning.
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 | Sub-Type | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In general, the display format consists of the sub-type identifier
followed by a colon and then formatted values, separated by colons
(ASCII 58). Each sub-type has a string representation, which is a
sequence of lowercase ascii letters, numbers and hyphens. The sub-
type identifiers MUST be unique to the extent that the identifier
together with the display format allows to determine the Type and
Sub-Type values.
Every new definition of a Extended Community Type or Sub-Type SHOULD
include a canonical textual representation of the value.
The following sections specify how the already specified Extended
Community variants are expected to be formatted. The syntax is
either reflecting the current practice adopted by the majority of
vendors, or trying to unify the formatting where no majority exists.
6.1. Display format for AS-Specific and IPv4-Specific Type values
Two-Octet AS-Specific Extended Community (Type 0x00 and 0x40)
([RFC4360]) Sub-Type identifier followed by the ASN (Global
Administrator) and local value (Local Administrator)
Example: route-target:65499:42
IPv4-Address-Specific Extended Community (Type 0x01 and 0x41)
([RFC4360]) Sub-Type identifier followed by the IPv4 address (Global
Administrator) and local value (Local Administrator)
Example: route-origin:192.0.2.67:42
Matejka Expires 1 December 2026 [Page 5]
Internet-Draft Canonical textual representation of BGP May 2026
Four-Octet AS-Specific Extended Community (Type 0x02 and 0x42)
([RFC5668]) Sub-Type identifier followed by the ASN (Global
Administrator) with an L suffix, and local value (Local
Administrator). While it's possible, in some cases, to
distinguish between four-octet and two-octet ASN without the
suffix, it SHOULD be used in all cases to avoid confusion.
Example: route-target:65544L:22, route-origin:65511L:12345
6.2. Display format for Opaque Extended Community (Type 0x03 and 0x43)
Specified in [RFC4360].
(TODO)
6.2.1. Default Gateway Extended Community
Specified in Section 7.8 of [RFC7432]. Formatted as evpn-default-
gateway with no colons.
6.3. Display format for EVPN Extended Communities (Type 0x06)
6.3.1. ESI Label Extended Community
Specified in Section 7.5 of [RFC7432]. Formatted as esi-label
followed by flags and label value.
Flags: S for Single-Active, A for All-Active
Example: esi-label:A:67
6.3.2. ES-Import Route Target Extended Community
Specified in Section 7.6 of [RFC7432]. Formatted as es-import-target
followed by the ES-Import value formatted as single bytes in
hexadecimal notation.
Example: es-import-target:fe:ed:0d:b8:1e:a9
6.3.3. MAC Mobility Extended Community
Specified in Section 7.7 of [RFC7432]. Formatted as mac-mobility
followed by flags and sequence number.
Flags: S for sticky/static, nothing otherwise
Example: mac-mobility:S:67, mac-mobility::42
Matejka Expires 1 December 2026 [Page 6]
Internet-Draft Canonical textual representation of BGP May 2026
7. Security Considerations
There are no security considerations in formatting the path
attributes.
8. IANA Considerations
8.1. BGP Well-known Communities
IANA is requested to rename the "Standby PE" BGP community value
(0xFFFF0009) to STANDBY_PE.
8.2. Registries for BGP Extended Communities
IANA is requested to add a column "Identifier" to all the Sub-Type
registries as specified in Section 5.2 of [RFC7153]. The identifiers
MUST NOT be reused in any other Sub-Type registries, unless
explicitly specified.
The following data should be used to fill the newly added columns.
8.2.1. EVPN Extended Community Sub-Types
+================+========================+==================+
| Sub-Type Value | Name | Identifier |
+================+========================+==================+
| 0x00 | MAC Mobility | mac-mobility |
+----------------+------------------------+------------------+
| 0x01 | ESI Label | esi-label |
+----------------+------------------------+------------------+
| 0x02 | ES-Import Route Target | es-import-target |
+----------------+------------------------+------------------+
Table 1
8.2.2. Transitive Two-Octet AS-Specific Extended Community Sub-Types
+================+========================+===================+
| Sub-Type Value | Name | Identifier |
+================+========================+===================+
| 0x02 | Route Target | route-target |
+----------------+------------------------+-------------------+
| 0x03 | Route Origin | route-origin |
+----------------+------------------------+-------------------+
| 0x05 | OSPF Domain Identifier | ospf-domain-ident |
+----------------+------------------------+-------------------+
Table 2
Matejka Expires 1 December 2026 [Page 7]
Internet-Draft Canonical textual representation of BGP May 2026
9. References
9.1. Normative References
[RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities
Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996,
<https://www.rfc-editor.org/rfc/rfc1997>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/rfc/rfc4271>.
[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
Communities Attribute", RFC 4360, DOI 10.17487/RFC4360,
February 2006, <https://www.rfc-editor.org/rfc/rfc4360>.
[RFC4577] Rosen, E., Psenak, P., and P. Pillay-Esnault, "OSPF as the
Provider/Customer Edge Protocol for BGP/MPLS IP Virtual
Private Networks (VPNs)", RFC 4577, DOI 10.17487/RFC4577,
June 2006, <https://www.rfc-editor.org/rfc/rfc4577>.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760,
DOI 10.17487/RFC4760, January 2007,
<https://www.rfc-editor.org/rfc/rfc4760>.
[RFC5668] Rekhter, Y., Sangli, S., and D. Tappan, "4-Octet AS
Specific BGP Extended Community", RFC 5668,
DOI 10.17487/RFC5668, October 2009,
<https://www.rfc-editor.org/rfc/rfc5668>.
[RFC7153] Rosen, E. and Y. Rekhter, "IANA Registries for BGP
Extended Communities", RFC 7153, DOI 10.17487/RFC7153,
March 2014, <https://www.rfc-editor.org/rfc/rfc7153>.
[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based
Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February
2015, <https://www.rfc-editor.org/rfc/rfc7432>.
Matejka Expires 1 December 2026 [Page 8]
Internet-Draft Canonical textual representation of BGP May 2026
[RFC8092] Heitz, J., Ed., Snijders, J., Ed., Patel, K., Bagdonas,
I., and N. Hilliard, "BGP Large Communities Attribute",
RFC 8092, DOI 10.17487/RFC8092, February 2017,
<https://www.rfc-editor.org/rfc/rfc8092>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC9026] Morin, T., Ed., Kebler, R., Ed., and G. Mirsky, Ed.,
"Multicast VPN Fast Upstream Failover", RFC 9026,
DOI 10.17487/RFC9026, April 2021,
<https://www.rfc-editor.org/rfc/rfc9026>.
[RFC9774] Kumari, W., Sriram, K., Hannachi, L., and J. Haas,
"Deprecation of AS_SET and AS_CONFED_SET in BGP",
RFC 9774, DOI 10.17487/RFC9774, May 2025,
<https://www.rfc-editor.org/rfc/rfc9774>.
9.2. Informative References
[RFC8642] Borkenhagen, J., Bush, R., Bonica, R., and S. Bayraktar,
"Policy Behavior for Well-Known BGP Communities",
RFC 8642, DOI 10.17487/RFC8642, August 2019,
<https://www.rfc-editor.org/rfc/rfc8642>.
Acknowledgments
TODO acknowledge.
Jeff Haas for pushing me this direction.
Authors of BGP YANG.
Author's Address
Maria Matejka
CZ.NIC
Email: ietf.org@jmq.cz
Matejka Expires 1 December 2026 [Page 9]