]> CZ.NIC

ietf.org@jmq.cz

Routing Inter-Domain Routing text representation BGP attributes communities 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 The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Inter-Domain Routing Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

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.

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 when, and only when, they appear in all capitals, as shown here.

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

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?

COMMUNITIES Attribute The COMMUNITIES attribute 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 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 is hereby renamed to STANDBY_PE. The semantics stays the same. TODO: ABNF here?

EXTENDED_COMMUNITIES Attribute The EXTENDED_COMMUNITIES attribute is a set of uint64 values with a complicated structure. Copying a modified schema from , the Type denotes how the value is further split into sub-values, and the Sub-Type denotes the meaning. 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.

Display format for AS-Specific and IPv4-Specific Type values

Two-Octet AS-Specific Extended Community (Type 0x00 and 0x40) ()

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

Sub-Type identifier followed by the IPv4 address (Global Administrator) and local value (Local Administrator)

Example: route-origin:192.0.2.67:42

Four-Octet AS-Specific Extended Community (Type 0x02 and 0x42) ()

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

Display format for Opaque Extended Community (Type 0x03 and 0x43) Specified in . (TODO)

Default Gateway Extended Community Specified in . Formatted as evpn-default-gateway with no colons.

Display format for EVPN Extended Communities (Type 0x06)

ESI Label Extended Community Specified in . Formatted as esi-label followed by flags and label value. Flags: S for Single-Active, A for All-Active Example: esi-label:A:67

ES-Import Route Target Extended Community Specified in . 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

MAC Mobility Extended Community Specified in . 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

Security Considerations There are no security considerations in formatting the path attributes.

IANA Considerations

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

Registries for BGP Extended Communities IANA is requested to add a column "Identifier" to all the Sub-Type registries as specified in . 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.

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

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

References Normative References This document describes an extension to BGP which may be used to pass additional information to both neighboring and remote BGP peers. [STANDARDS-TRACK] This document discusses the Border Gateway Protocol (BGP), which is an inter-Autonomous System routing protocol. The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASes) that reachability information traverses. This information is sufficient for constructing a graph of AS connectivity for this reachability from which routing loops may be pruned, and, at the AS level, some policy decisions may be enforced. BGP-4 provides a set of mechanisms for supporting Classless Inter-Domain Routing (CIDR). These mechanisms include support for advertising a set of destinations as an IP prefix, and eliminating the concept of network "class" within BGP. BGP-4 also introduces mechanisms that allow aggregation of routes, including aggregation of AS paths. This document obsoletes RFC 1771. [STANDARDS-TRACK] This document describes the "extended community" BGP-4 attribute. This attribute provides a mechanism for labeling information carried in BGP-4. These labels can be used to control the distribution of this information, or for other applications. [STANDARDS-TRACK] Many Service Providers offer Virtual Private Network (VPN) services to their customers, using a technique in which customer edge routers (CE routers) are routing peers of provider edge routers (PE routers). The Border Gateway Protocol (BGP) is used to distribute the customer's routes across the provider's IP backbone network, and Multiprotocol Label Switching (MPLS) is used to tunnel customer packets across the provider's backbone. This is known as a "BGP/MPLS IP VPN". The base specification for BGP/MPLS IP VPNs presumes that the routing protocol on the interface between a PE router and a CE router is BGP. This document extends that specification by allowing the routing protocol on the PE/CE interface to be the Open Shortest Path First (OSPF) protocol. This document updates RFC 4364. [STANDARDS-TRACK] This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols (e.g., IPv6, IPX, L3VPN, etc.). The extensions are backward compatible - a router that supports the extensions can interoperate with a router that doesn't support the extensions. [STANDARDS-TRACK] This document defines a new type of a BGP extended community, which carries a 4-octet Autonomous System (AS) number. [STANDARDS-TRACK] This document reorganizes the IANA registries for the type values and sub-type values of the BGP Extended Communities attribute and the BGP IPv6-Address-Specific Extended Communities attribute. This is done in order to remove interdependencies among the registries, thus making it easier for IANA to determine which codepoints are available for assignment in which registries. This document also clarifies the information that must be provided to IANA when requesting an allocation from one or more of these registries. These changes are compatible with the existing allocations and thus do not affect protocol implementations. The changes will, however, impact the "IANA Considerations" sections of future protocol specifications. This document updates RFC 4360 and RFC 5701. This document describes procedures for BGP MPLS-based Ethernet VPNs (EVPN). The procedures described here meet the requirements specified in RFC 7209 -- "Requirements for Ethernet VPN (EVPN)". This document describes the BGP Large Communities attribute, an extension to BGP-4. This attribute provides a mechanism to signal opaque information within separate namespaces to aid in routing management. The attribute is suitable for use with all Autonomous System Numbers (ASNs) including four-octet ASNs. This document defines Multicast Virtual Private Network (VPN) extensions and procedures that allow fast failover for upstream failures by allowing downstream Provider Edges (PEs) to consider the status of Provider-Tunnels (P-tunnels) when selecting the Upstream PE for a VPN multicast flow. The fast failover is enabled by using "Bidirectional Forwarding Detection (BFD) for Multipoint Networks" (RFC 8562) and the new BGP Attribute, BFD Discriminator. Also, this document introduces a new BGP Community, Standby PE, extending BGP Multicast VPN (MVPN) routing so that a C-multicast route can be advertised toward a Standby Upstream PE. BCP 172 (i.e., RFC 6472) recommends not using AS_SET and AS_CONFED_SET AS_PATH segment types in the Border Gateway Protocol (BGP). This document advances that recommendation to a standards requirement in BGP; it prohibits the use of the AS_SET and AS_CONFED_SET path segment types in the AS_PATH. This is done to simplify the design and implementation of BGP and to make the semantics of the originator of a BGP route clearer. This will also simplify the design, implementation, and deployment of various BGP security mechanisms. This document updates RFC 4271 by deprecating the origination of BGP routes with AS_SET (Type 1 AS_PATH segment) and updates RFC 5065 by deprecating the origination of BGP routes with AS_CONFED_SET (Type 4 AS_PATH segment). Finally, it obsoletes RFC 6472. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References Well-known BGP communities are manipulated differently across various current implementations, resulting in difficulties for operators. Network operators should deploy consistent community handling across their networks while taking the inconsistent behaviors from the various BGP implementations into consideration. This document recommends specific actions to limit future inconsistency: namely, BGP implementors must not create further inconsistencies from this point forward. These behavioral changes, though subtle, actually update RFC 1997.

Acknowledgments TODO acknowledge. Jeff Haas for pushing me this direction. Authors of BGP YANG.