Internet-Draft Canonical textual representation of BGP June 2026
Matejka Expires 20 December 2026 [Page]
Workgroup:
Inter-Domain Routing
Internet-Draft:
draft-marenamat-idr-bgp-attribute-formatting-01
Published:
Intended Status:
Standards Track
Expires:
Author:
M. Matejka
CZ.NIC

Canonical textual representation of BGP Path Attributes

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.

This document updates RFC 4940 by adding a textual tag column to the OSPFv2 Link State Type registry.

This document updates RFC 7153 by adding a textual tag column to the extended community registry.

(REMOVE THIS) This document is incomplete and needs completing the tables.

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.

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 20 December 2026.

▲

Table of Contents

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.

It is expected that these formatted values would be used inside NETCONF and RESTCONF APIs, wherever practical. Alternatives would be to send raw binary data, which would need additional parsing on the client side, or to model full structures of the attributes to the full depth, which would add significant amount of noise into both the model and the data itself.

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.

Raw attribute value: The value of the BGP attribute as received or to be sent in a BGP message.

Textual representation: A human-readable string representing a value of a BGP attribute.

Clear representation: A textual representation which is unambiguosly convertible to a raw attribute value.

Canonical representation: A clear representation assigned to a specific raw attribute value.

Formatter: The part of software implementation which accepts a raw attribute value and outputs its textual representation.

Canonical Formatter: A formatter producing canonical representations.

Parser: The part of software implementation which accepts a textual representation and outputs a raw attribute value.

3. General rules

Formatters MAY produce other textual representations if configured so. Formatters SHOULD always produce clear representations, to avoid confusion. Parsers SHOULD NOT assume a specific interpretation of a textual representation which is not clear.

Parsers SHOULD be case-insensitive. There MUST NOT be any case where a semantics was dependent on the letter case.

3.1. Basic data types

  1. Integer values SHOULD be displayed as a single integer in decimal notation with no leading zeros.

  2. Enumeration values SHOULD be displayed as the item identifier, as specified in their appropriate tables. Many of these are to be (FIXME) updated by this document, Section 11, to include such identifiers suitable for canonical representation.

    Unknown enumeration values SHOULD be displayed as a single integer in decimal notation with no leading zeros.

  3. Flags SHOULD be treated as separate values, which are either present (set to 1) or absent (set to 0). If appropriate, even an absent flag MAY be displayed. They SHOULD be represented as their flag identifiers, as specified in their appropriate tables. Many of these are to be (FIXME) updated by this document, Section 11, to include such identifiers suitable for canonical representation. Flags SHOULD be displayed in the order from the most significant to least significant bit.

    Unknown flags set to 1 SHOULD be displayed as a single integer in decimal notation with no leading zeros, representing the position of the set bit.

  4. Enumeration and Flag Identifiers have a string representation, which is a sequence of lowercase or uppercase ASCII letters, numbers and hyphens. All identifiers for one set of flags or values MUST be mutually unique, and SHOULD be all either lowercase or uppercase, not both, to achieve a consistent canonical representation.

  5. Values specified to be displayed in hexadecimal SHOULD be displayed padded by zeros to all significant bits.

  6. IPv6 addresses SHOULD be displayed in the short form, as specified in Section 2.2 of [RFC4291], paragraph 2, and if not standalone, they SHOULD be surrounded by square braces (ASCII 91 and 93).

  7. IPv4 addresses SHOULD be displayed in the standard form of four integers (see above) delimited by dots (ASCII 46).

  8. Values specified as reserved SHOULD NOT be displayed (should be skipped). If these values are set to non-default values, the whole containing attribute structure SHOULD be displayed as a sequence of octets in hexadecimal, prefixed by malformed. The implementation MAY have configuration options to ignore non-default reserved values.

4. Simple Path Attributes

The following attributes are listed simply for the sake of completeness. Their formatting is either obvious or straightforward to model coherently.

For example, many of these are just an integer, and even a very complex attribute like PMSI_TUNNEL can be modelled as a key-value structure.

Specifically, all attributes with a sub-TLV structure are expected to be modelled in a structured way.

All unknown attributes are considered to be a binary blob, and with that, simple to format.

5. 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 integers separated by single spaces (ASCII 32).

In addition to that, every AS_CONFED_SEQUENCE SHOULD be parenthesized (ASCII 40 and 41),

Boundary between two consecutive AS_SEQUENCE segments MAY be delimited by | (ASCII 124), and while the segmentation bears no semantic value, it may be handy to see when debugging corner-case router behavior.

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.

A sequence of an unknown type, if needed to be displayed, SHOULD be surrounded by square brackets (ASCII 91 and 93), and prefixed by unknown: followed by the type value as an integer.

Example: 67 01 fb fb 02 02 fb f4 fb fe in the semantics of RFC 4271 (two-octet ASNs) shall be printed out as follows: [ unknown:103 64507 ] 64500 64510

Note: The AS_SET and AS_CONFED_SET segments have been deprecated by [RFC9774]. If needed to be displayed, they SHOULD be displayed in the same way as unknown types. The implementation MAY, if configured so, replace the unknown:1 and unknown:4 by set and confed-set, respectively.

6. 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 integers 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.

Example: 65544:6767, BLACKHOLE

7. 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 the meaning and formatting of the value. While the original specification allows for registering regular single-octet types with 7-octet value, the only drafts ever seen specifying these are [I-D.knoll-idr-cos-interconnect] and [I-D.knoll-idr-qos-attribute] with last versions from 2019, and therefore it is assumed that the Type is always extended to 2 octets.

 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               |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+          Value                |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Commonly, the lower octet of the Type is called Sub-Type, as in [RFC7153].

The canonical formatting of each value is the Type displayed as an enumeration value, and then the Value split to its semantic parts, as specified in following subsections. All the parts are displayed in order, beginning with the Type identifier, and delimited by a single colon (ASCII 58).

If the Type is unknown, the whole extended community value is displayed as unknown-transitive or unknown-non-transitive followed by all eight octets of the extended community (including the type itself), delimited by colons (ASCII 58).

Example: 67 89 ab cd ef 01 23 45 would be displayed as unknown-non-transitive:67:89:ab:cd:ef:01:23:45

7.1. Future Extended Community Type definitions

Every new definition of an Extended Community Type MUST include its enumeration value identifier and a specification of canonical textual representation of the value. Hereby, a paragraph shall be appended to the Section 4 of [RFC7153]:

  • Every Sub-Type codepoint defined MUST specify a unique value of the display format type identifier, together with the appropriate canonical textual representation of the Value.

    For Sub-Type codepoints with similar semantics across multiple high octets, it is RECOMMENDED to assign similar type identifiers.

    Identifiers assigned by IANA MUST NOT begin with unknown-, experimental- or malformed-.

For experimental types, an implementation MAY locally assign an identifier beginning with experimental-, and format these appropriately.

7.2. Display format for AS2-Specific Type Values

The structure of Two-octet AS-Specific Extended Community (Type high octet 0x00 and 0x40) Value is first the two-octet AS number (Global Administrator) and then four-octet local value (Local Administrator). Both values are integers.

7.2.1. Display format for AS2-Specific BGP Data Collection Values

The actual structure of the AS2-Specific BGP Data Collection (Type 0x0008) Local Administrator value is, by [RFC4384]:

  • 2 octets of zeros (reserved)

  • 5 bits of region identifier (Section 11.4)

  • 1 bit of satellite link flag (displayed as SAT if set to 1)

  • 10 bits of country code (using two-character codes for formatting as defined in [ISO.3166-1.2006])

There are also special values which are represented by a single identifier from Section 11.4.

The parser SHOULD also accept discontinued country codes, possibly with a warning.

Example:

  • 00 08 fb f4 00 00 1a 0c is formatted as data-collection-as2:64500:AS:NP

  • 00 08 fb f6 00 00 00 06 is formatted as data-collection-as2:64500:upstream

  • 00 08 fb f8 67 67 67 67 is formatted as data-collection-as2:64500:malformed:67:67:67:67

7.3. Display format for IPv4-Specific Type Values

The structure of IPv4-Specific Extended Community (Type high octet 0x01 and 0x41) Value is first the four-octet IPv4 address (Global Administrator) and then two-octet local value (Local Administrator).

The Global Administrator value is formatted as an IPv4 address. The Local Administrator value is formatted as a decimal integer with no leading zeros, unless specified otherwise.

7.3.1. Display format for IPv4-Specific BGP Data Collection Values

The actual structure of the BGP Data Collection (Type 0x0108) Local Administrator value is, by [RFC4384]:

  • 5 bits of region identifier (Section 11.4)

  • 1 bit of satellite link flag (displayed as SAT if set to 1)

  • 10 bits of country code (using two-character codes for formatting as defined in [ISO.3166-1.2006])

There are also special values which are represented by a single identifier from Section 11.4.

The parser SHOULD also accept discontinued country codes, possibly with a warning.

Example:

  • 01 08 c0 00 02 43 1e 0c is formatted as data-collection-ipv4:192.0.2.67:AS:SAT:NP

  • 01 08 c6 33 64 2a 00 06 is formatted as data-collection-ipv4:198.51.100.42:upstream

  • 01 08 cb 00 71 67 24 43 is formatted as data-collection-ipv4:203.0.113.103:AQ:SAT:67

7.4. Display format for AS4-Specific Type values

The structure of Four-octet AS-Specific Extended Community (Type high octet 0x02 and 0x42) Value is first the four-octet AS number (Global Administrator) and then two-octet local value (Local Administrator).

The Global Administrator value is formatted as a decimal integer with no leading zeros. The Local Administrator value is formatted as a decimal integer with no leading zeros, unless specified otherwise.

7.4.1. Display format for IPv4-Specific BGP Data Collection Values

The actual structure of the BGP Data Collection (Type 0x0208) Local Administrator value is, by [RFC4384]:

  • 5 bits of region identifier (Section 11.4)

  • 1 bit of satellite link flag (displayed as SAT if set to 1)

  • 10 bits of country code (using two-character codes for formatting as defined in [ISO.3166-1.2006])

There are also special values which are represented by a single identifier from Section 11.4.

The parser SHOULD also accept discontinued country codes, possibly with a warning.

Example:

  • 02 08 00 01 00 04 1a 0c is formatted as data-collection-as4:65540:AS:NP

  • 02 08 00 01 00 06 00 06 is formatted as data-collection-as4:65542:upstream

  • 02 08 00 01 00 07 67 67 is formatted as data-collection-as4:65543:26471

7.5. Display format for Opaque Type Values

The structure of Opaque Extended Community (Type high octet 0x03 and 0x43) Value is specific for each Sub-Type, as specified in [RFC4360] and subsequent documents.

The value is often reserved and specified to be zero. Unless specified otherwise, the value is therefore not displayed at all.

Example: extranet-separation

TODO: There is no value specified in [RFC7543] at all.

7.5.1. Display format for OSPF Route Type

The actual structure of the OSPF Route Type (Type 0x0306) Value is, by [RFC4577]:

+--------+--------+--------+--------+--------+--------+
|             Area Number           |  Type  |0000000M|
+--------+--------+--------+--------+--------+--------+

The Area Number is to be formatted as dotted-decimal.

Known values of Type are specified in Section 4.2.6 of [RFC4577] as an explicit table, which is actually aligned with the IANA table later specified by [RFC4940]. Hereby the Section 4.2.6 of [RFC4577] is updated such that the OSPF Route Type encoding states:

OSPF Route type: 1 byte, using values in the Registry for OSPFv2 Link State (LS) Type, as specified by {{Section 5.5 of RFC4940}}.

The Type is to be formatted as an identifier specified in Section 11.6. An unknown value of Type is to be formatted as a decimal number with no leading zeros.

The Options shall be formatted as flags as specified in Section 3.1. Currently, the only flag specified is TYPE-2-METRIC.

7.5.2. Display format for Additional PMSI Tunnel Attribute Flags

The actual structure of the Additional PMSI Tunnel Attribute Flags Type (Type 0x0307) is, by [RFC7902], a set of 48 flags. These shall be displayed as flags as specified in Section 3.1.

This document hereby updates Section 3 of [RFC7902] by adding the following paragraph:

  • Names of the flags in the "Additional PMSI Tunnel Attribute Flags" table SHOULD consist of uppercase letters, numbers and dashes, and MUST NOT contain any whitespace.

When feasible and practical, the implementation MAY also display this extended community contents as an actual extension in the context of the PMSI Tunnel path attribute. It SHOULD be displayed together with other extended communities anyway though, to keep the notion of its actual location.

7.5.3. Display format for Context-Specific Label Space ID

The actual structure of the Context-Specific Label Space ID Type (Type 0x0308) is, by [RFC9753], a 2-octet ID-Type (enumeration, see Section 11.5) and a 4-octet ID-Value (integer).

Note: For ID-Type zero (MPLS Label), Section 4.1 of [RFC9753] does not specify the value of the bottom 12 bits of the ID-Value. This document hereby updates Section 4.1 of [RFC9753] by adding a sentence to its third paragraph (which specifies the ID-Value):

  • The remaining 12 bits are reserved and MUST be set to zero.

TODO: more EC to inspect

7.6. Display format for EVPN Extended Communities (Type 0x06)

7.6.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

7.6.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

7.6.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

8. IPv6 Address Specific Extended Community Attribute

The IPv6 Address Specific Extended Community Attribute [RFC5701] is a set of 20-octet values with a complicated structure.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x00 or 0x40  |    Sub-Type   |    Global Administrator       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Global Administrator (cont.)                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Global Administrator (cont.)                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Global Administrator (cont.)                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Global Administrator (cont.)  |    Local Administrator        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The formatting of this attribute generally follows the same principle as the EXTENDED_COMMUNITIES, specified in Section 7. Each value in the list is split to its semantic parts. All the parts are displayed in order, beginning with the Sub-Type identifier, and delimited by a single colon (ASCII 58).

If not specified otherwise, the Global Administrator field is displayed as an IPv6 address, and the Local Administrator is formatted as an integer (see Section 3.1). No alternative formatting is specified for any Sub-Type in this document.

If the Sub-Type itself is unknown, it is formatted as unknown-transitive or unknown-non-transitive followed by the actual Sub-Type value formatted as hexadecimal, and then the Global and Local Administrator values as usual,

8.1. Future IPv6 Address Specific Extended Community Sub-Type definitions

Every new definition of an IPv6 Address Specific Extended Community Sub-Type MUST include its enumeration value identifier and a specification of canonical textual representation of the value. Hereby, a paragraph shall be appended to the Section 3 of [RFC5701]:

  • Every Sub-Type codepoint defined MUST specify a unique value of the display format type identifier, together with the appropriate canonical textual representation of the Value.

    For Sub-Type codepoints with similar semantics differing only by the transitivity, it is RECOMMENDED to assign similar type identifiers.

    Identifiers assigned by IANA MUST NOT begin with unknown-, experimental- or malformed-.

For experimental types, an implementation MAY locally assign an identifier beginning with experimental-, and format these appropriately.

9. LARGE_COMMUNITY Attribute

The LARGE_COMMUNITY attribute [RFC8092] is a set of uint32 triplets. First of these is an AS number (Global Administrator), and the two others bear no special semantics.

While this attribute could be modeled easily as a set of uint32 triplets, people tend to display large communities in a similar way to Communities (Section 6) and Extended Communities (Section 7), and therefore it is acceptable to display each triplet as a set of three integers separated by colons (ASCII 58).

10. Security Considerations

There are no security considerations in formatting the path attributes.

11. IANA Considerations

11.1. BGP Well-known Communities

IANA is requested to rename the "Standby PE" BGP community value (0xFFFF0009) to STANDBY_PE.

11.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.

11.2.1. Transitive Two-Octet AS-Specific Extended Community Sub-Types

Table 1
Sub-Type Value Name Identifier
0x02 Route Target route-target-as2
0x03 Route Origin route-origin-as2
0x05 OSPF Domain Identifier ospf-domain-id-as2
0x08 BGP Data Collection data-collection-as2
0x09 Source AS source-as2
0x0A L2VPN Identifier i2vpn-id-as2

11.2.2. Transitive IPv4-Address-Specific Extended Community Sub-Types

Table 2
Sub-Type Value Name Identifier
0x02 Route Target route-target-ipv4
0x03 Route Origin route-origin-ipv4
0x05 OSPF Domain Identifier ospf-domain-id-ipv4
0x07 OSPF Router ID ospf-router-id-ipv4
0x0A L2VPN Identifier i2vpn-id-ipv4
0x0B VRF Route Import vrf-route-import-ipv4
0x12 Inter-Area P2MP Segmented Next-Hop p2mp-inter-area-segmented-nh-ipv4
0x20 MVPN SA RP-address mvpn-sa-rp-address-ipv4

The IANA is hereby requested to fix the typo at 0x07 Name.

11.2.3. Transitive Four-Octet AS-Specific Extended Community Sub-Types

Table 3
Sub-Type Value Name Identifier
0x02 Route Target route-target-as4
0x03 Route Origin route-origin-as4
0x05 OSPF Domain Identifier ospf-domain-ident-as4
0x08 BGP Data Collection data-collection-as4
0x09 Source AS source-as4

11.2.4. Transitive Opaque Extended Community Sub-Types

Table 4
Sub-Type Value Name Identifier
0x03 CP-ORF cp-orf
0x04 Extranet Source extranet-source
0x05 Extranet Separation extranet-separation
0x06 OSPF Route Type ospf-route-type
0x07 Additional PMSI Tunnel Attribute Flags pmsi-tunnel-flags
0x08 Context-Specific Label Space ID label-space-id
0x0d Default Gateway evpn-default-gateway

IANA is hereby requested to fix the reference in "Transitive Opaque Extended Community Sub-Types" table from Yakov Rekhter to [RFC7432].

(TODO)

11.2.5. EVPN Extended Community Sub-Types

Table 5
Sub-Type Value Name Identifier
0x00 MAC Mobility mac-mobility
0x01 ESI Label esi-label
0x02 ES-Import Route Target es-import-target
0x03 EVPN Router's MAC evpn-router-mac
0x04 EVPN Layer 2 Attributes evpn-layer2-attrs
0x05 E-Tree evpn-etree
0x06 DF Election evpn-df-election
0x08 ARP/ND evpn-arp-nd
0x09 Multicast Flags evpn-mc-flags
0x0A EVI-RT Type 0 evi-rt0
0x0B EVI-RT Type 1 evi-rt1
0x0C EVI-RT Type 2 evi-rt2
0x0D EVI-RT Type 3 evi-rt3
0x0F Service Carving Time evpn-sct

(TODO)

11.3. Transitive IPv6-Address-Specific Extended Community Sub-Types

In the same set of registries as Extended Communities, there is an IPv6-Address Specific Extended Community Sub-Types Registry. IANA is requested to add a column "Identifier" to this registry, which is populated as follows:

Table 6
Type Value Name Identifier
0x0002 Route Target route-target-ipv6
0x0003 Route Origin route-origin-ipv6
0x000B VRF Route Import vrf-route-import-ipv6
0x0012 Inter-Area P2MP Segmented Next-Hop p2mp-inter-area-segmented-nh-ipv6

11.4. Registry for BGP Data Collection Communities

IANA is requested to add a column "Identifier" to the BGP Data Collection Standard Communities Registry, which is populated as follows:

Table 7
Value Category Identifier
0000000000000001 Customer Routes customer
0000000000000010 Peer Routes peer
0000000000000011 Internal Routes internal
0000000000000100 Internal More Specific Routes internal-more-specific
0000000000000101 Special Purpose Routes special
0000000000000110 Upstream Routes upstream

IANA is requested to add a column "Identifier" to the Region Identifiers Registry, which is populated as follows:

Table 8
Value Category Identifier
00001 Africa AF
00010 Oceania OC
00011 Asia AS
00100 Antarctica AQ
00101 Europe EU
00110 Latin America/Caribbean Islands LAC
00111 North America NA

11.5. Registry for Context-Specific Label Space ID Type

IANA is requested to add a column "Identifier" to the Context-Specific Label Space ID Type Registry, which is populated as follows:

Table 9
Value Name Identifier
0 MPLS Label mpls-label

12. References

12.1. Normative References

[ISO.3166-1.2006]
International Organization for Standardization, "Codes for the representation of names of countries, 3rd edition", ISO Standard 3166-1, .
[RFC1997]
Chandra, R., Traina, P., and T. Li, "BGP Communities Attribute", RFC 1997, DOI 10.17487/RFC1997, , <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, , <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, , <https://www.rfc-editor.org/rfc/rfc4271>.
[RFC4291]
Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, , <https://www.rfc-editor.org/rfc/rfc4291>.
[RFC4360]
Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, , <https://www.rfc-editor.org/rfc/rfc4360>.
[RFC4384]
Meyer, D., "BGP Communities for Data Collection", BCP 114, RFC 4384, DOI 10.17487/RFC4384, , <https://www.rfc-editor.org/rfc/rfc4384>.
[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, , <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, , <https://www.rfc-editor.org/rfc/rfc4760>.
[RFC4940]
Kompella, K. and B. Fenner, "IANA Considerations for OSPF", BCP 130, RFC 4940, DOI 10.17487/RFC4940, , <https://www.rfc-editor.org/rfc/rfc4940>.
[RFC5668]
Rekhter, Y., Sangli, S., and D. Tappan, "4-Octet AS Specific BGP Extended Community", RFC 5668, DOI 10.17487/RFC5668, , <https://www.rfc-editor.org/rfc/rfc5668>.
[RFC5701]
Rekhter, Y., "IPv6 Address Specific BGP Extended Community Attribute", RFC 5701, DOI 10.17487/RFC5701, , <https://www.rfc-editor.org/rfc/rfc5701>.
[RFC6368]
Marques, P., Raszuk, R., Patel, K., Kumaki, K., and T. Yamagata, "Internal BGP as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 6368, DOI 10.17487/RFC6368, , <https://www.rfc-editor.org/rfc/rfc6368>.
[RFC7153]
Rosen, E. and Y. Rekhter, "IANA Registries for BGP Extended Communities", RFC 7153, DOI 10.17487/RFC7153, , <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, , <https://www.rfc-editor.org/rfc/rfc7432>.
[RFC7543]
Jeng, H., Jalil, L., Bonica, R., Patel, K., and L. Yong, "Covering Prefixes Outbound Route Filter for BGP-4", RFC 7543, DOI 10.17487/RFC7543, , <https://www.rfc-editor.org/rfc/rfc7543>.
[RFC7900]
Rekhter, Y., Ed., Rosen, E., Ed., Aggarwal, R., Cai, Y., and T. Morin, "Extranet Multicast in BGP/IP MPLS VPNs", RFC 7900, DOI 10.17487/RFC7900, , <https://www.rfc-editor.org/rfc/rfc7900>.
[RFC7902]
Rosen, E. and T. Morin, "Registry and Extensions for P-Multicast Service Interface Tunnel Attribute Flags", RFC 7902, DOI 10.17487/RFC7902, , <https://www.rfc-editor.org/rfc/rfc7902>.
[RFC8092]
Heitz, J., Ed., Snijders, J., Ed., Patel, K., Bagdonas, I., and N. Hilliard, "BGP Large Communities Attribute", RFC 8092, DOI 10.17487/RFC8092, , <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, , <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, , <https://www.rfc-editor.org/rfc/rfc9026>.
[RFC9753]
Li, C., Zheng, H., and S. Litkowski, "Extension for Stateful PCE to Allow Optional Processing of Path Computation Element Communication Protocol (PCEP) Objects", RFC 9753, DOI 10.17487/RFC9753, , <https://www.rfc-editor.org/rfc/rfc9753>.
[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, , <https://www.rfc-editor.org/rfc/rfc9774>.

12.2. Informative References

[I-D.knoll-idr-cos-interconnect]
Knoll, T. M., "BGP Class of Service Interconnection", Work in Progress, Internet-Draft, draft-knoll-idr-cos-interconnect-23, , <https://datatracker.ietf.org/doc/html/draft-knoll-idr-cos-interconnect-23>.
[I-D.knoll-idr-qos-attribute]
Knoll, T. M., "BGP Extended Community for QoS Marking", Work in Progress, Internet-Draft, draft-knoll-idr-qos-attribute-24, , <https://datatracker.ietf.org/doc/html/draft-knoll-idr-qos-attribute-24>.
[RFC8642]
Borkenhagen, J., Bush, R., Bonica, R., and S. Bayraktar, "Policy Behavior for Well-Known BGP Communities", RFC 8642, DOI 10.17487/RFC8642, , <https://www.rfc-editor.org/rfc/rfc8642>.

Acknowledgments

TODO acknowledge.

Jeff Haas, Ondřej Zajíček for major comments and suggestions.

Authors of BGP YANG.

Author's Address

Maria Matejka
CZ.NIC