Canonical textual representation of BGP Path Attributes

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

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¶

• 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.¶

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

7. Security Considerations

There are no security considerations in formatting the path attributes.¶

8. IANA Considerations

9. References

Acknowledgments

TODO acknowledge.¶

Jeff Haas for pushing me this direction.¶

Authors of BGP YANG.¶

Author's Address