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

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

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.

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

Simple Path Attributes The following attributes are listed simply for the sake of completeness. Their formatting is either obvious or straightforward 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
• Type 22 – PMSI_TUNNEL
• Type 23 – Tunnel Encapsulation
• Type 24 – Traffic Engineering
• Type 26 – AIGP
• Type 27 – PE Distinguisher Labels
• Type 29 – Link State
• Type 33 – BGPsec Path
• Type 35 – Only to Customer
• Type 37 – SFP
• Type 38 – BFD Discriminator
• Type 40 – Prefix-SID
• Type 41 – BIER
• Type 128 – ATTR_SET

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.

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

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 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 is hereby renamed to STANDBY_PE. The semantics stays the same. Example: 65544:6767, BLACKHOLE

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 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 and with last versions from 2019, and therefore it is assumed that the Type is always extended to 2 octets. Commonly, the lower octet of the Type is called Sub-Type, as in . 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

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 :

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

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.

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 :

• 2 octets of zeros (reserved)
• 5 bits of region identifier ()
• 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 )

There are also special values which are represented by a single identifier from . 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

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.

Display format for IPv4-Specific BGP Data Collection Values The actual structure of the BGP Data Collection (Type 0x0108) Local Administrator value is, by :

• 5 bits of region identifier ()
• 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 )

There are also special values which are represented by a single identifier from . 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

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.

Display format for IPv4-Specific BGP Data Collection Values The actual structure of the BGP Data Collection (Type 0x0208) Local Administrator value is, by :

• 5 bits of region identifier ()
• 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 )

There are also special values which are represented by a single identifier from . 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

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 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 at all.

Display format for OSPF Route Type The actual structure of the OSPF Route Type (Type 0x0306) Value is, by : The Area Number is to be formatted as dotted-decimal. Known values of Type are specified in as an explicit table, which is actually aligned with the IANA table later specified by . Hereby the is updated such that the OSPF Route Type encoding states: The Type is to be formatted as an identifier specified in . 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 . Currently, the only flag specified is TYPE-2-METRIC.

Display format for Additional PMSI Tunnel Attribute Flags The actual structure of the Additional PMSI Tunnel Attribute Flags Type (Type 0x0307) is, by , a set of 48 flags. These shall be displayed as flags as specified in . This document hereby updates 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.

Display format for Context-Specific Label Space ID The actual structure of the Context-Specific Label Space ID Type (Type 0x0308) is, by , a 2-octet ID-Type (enumeration, see ) and a 4-octet ID-Value (integer). Note: For ID-Type zero (MPLS Label), does not specify the value of the bottom 12 bits of the ID-Value. This document hereby updates 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

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

IPv6 Address Specific Extended Community Attribute The IPv6 Address Specific Extended Community Attribute is a set of 20-octet values with a complicated structure. The formatting of this attribute generally follows the same principle as the EXTENDED_COMMUNITIES, specified in . 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 ). 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,

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 :

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

LARGE_COMMUNITY Attribute The LARGE_COMMUNITY attribute 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 () and Extended Communities (), and therefore it is acceptable to display each triplet as a set of three integers separated by colons (ASCII 58).

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.

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

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

Transitive IPv4-Address-Specific Extended Community Sub-Types

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.

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

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

Transitive Opaque Extended Community Sub-Types

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

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

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:

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

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:

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:

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

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:

Value	Name	Identifier
0	MPLS Label	mpls-label

Registry for OSPFv2 Link State (LS) Type IANA is requested to add a column "Identifier" to the OSPFv2 Link State (LS) Type, as specified in , which is populated as follows:

Value	Description	Identifier
1	Router-LSA	router
2	Network-LSA	network
3	Summary-LSA (IP network)	summary
4	Summary-LSA (ASBR)	summary-asbr
5	AS-external-LSA	as-external
6	Group-membership-LSA	group-membership
7	NSSA AS-external LSA	nssa-as-external
9	Link-scoped Opaque LSA	link-opaque
10	Area-scoped Opaque LSA	area-opaque
11	AS-scoped Opaque LSA	as-opaque

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 specification defines the addressing architecture of the IP Version 6 (IPv6) protocol. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses. This document obsoletes RFC 3513, "IP Version 6 Addressing Architecture". [STANDARDS-TRACK] BGP communities (RFC 1997) are used by service providers for many purposes, including tagging of customer, peer, and geographically originated routes. Such tagging is typically used to control the scope of redistribution of routes within a provider's network and to its peers and customers. With the advent of large-scale BGP data collection (and associated research), it has become clear that the information carried in such communities is essential for a deeper understanding of the global routing system. This memo defines standard (outbound) communities and their encodings for export to BGP route collectors. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. 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 memo creates a number of OSPF registries and provides guidance to IANA for assignment of code points within these registries. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document defines a new type of a BGP extended community, which carries a 4-octet Autonomous System (AS) number. [STANDARDS-TRACK] Current specifications of BGP Extended Communities (RFC 4360) support the IPv4 Address Specific Extended Community, but do not support an IPv6 Address Specific Extended Community. The lack of an IPv6 Address Specific Extended Community may be a problem when an application uses the IPv4 Address Specific Extended Community, and one wants to use this application in a pure IPv6 environment. This document defines a new BGP attribute, the IPv6 Address Specific Extended Community, that addresses this problem. The IPv6 Address Specific Extended Community is similar to the IPv4 Address Specific Extended Community, except that it carries an IPv6 address rather than an IPv4 address. [STANDARDS TRACK] This document defines protocol extensions and procedures for BGP Provider/Customer Edge router iteration in BGP/MPLS IP VPNs. These extensions and procedures have the objective of making the usage of the BGP/MPLS IP VPN transparent to the customer network, as far as routing information is concerned. [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 defines a new Outbound Route Filter (ORF) type, called the Covering Prefixes ORF (CP-ORF). CP-ORF is applicable in Virtual Hub-and-Spoke VPNs. It also is applicable in BGP/MPLS Ethernet VPN (EVPN) networks. Previous RFCs specify the procedures necessary to allow IP multicast traffic to travel from one site to another within a BGP/MPLS IP VPN (Virtual Private Network). However, it is sometimes desirable to allow multicast traffic whose source is in one VPN to be received by systems that are in another VPN. This is known as a "Multicast VPN (MVPN) extranet". This document updates RFCs 6513, 6514, and 6625 by specifying the procedures that are necessary in order to provide extranet MVPN service. The BGP-based control procedures for Multicast Virtual Private Networks (MVPNs) make use of a BGP attribute known as the "P-Multicast Service Interface (PMSI) Tunnel" attribute. The attribute contains a one-octet "Flags" field. The purpose of this document is to establish an IANA registry for the assignment of the bits in this field. Since the "Flags" field contains only eight bits, this document also defines a new BGP Extended Community, "Additional PMSI Tunnel Attribute Flags", that can be used to carry additional flags for the "P-Multicast Service Interface (PMSI) Tunnel" attribute. This document updates RFC 6514. 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. This document introduces a mechanism to mark some of the Path Computation Element Communication Protocol (PCEP) objects as optional during PCEP message exchange, so the stateful Path Computation Element (PCE) model can relax some constraints during path computation and setup. This document introduces this relaxation to stateful PCE, and it updates RFC 8231. 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. International Organization for Standardization 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. This document focuses on Class of Service Interconnection at inter- domain interconnection points. It specifies two new transitive attributes, which enable adjacent peers to signal Class of Service Capabilities and certain Class of Service admission control Parameters. The new "CoS Capability" is deliberately kept simple and denotes the general EF, AF Group BE and LE forwarding support across the advertising AS. The second "CoS Parameter Attribute" is of variable length and contains a more detailed description of available forwarding behaviours using the PHB id Code encoding. Each PHB id Code is associated with rate and size based traffic parameters, which will be applied in the ingress AS Border Router for admission control purposes to a given forwarding behaviour. This document specifies a simple signalling mechanism for inter- domain QoS marking using several instances of a new BGP Extended Community. Class based packet marking and forwarding is currently performed independently within ASes. The new QoS marking community makes the targeted Per Hop Behaviour within the IP prefix advertising AS and the currently applied marking at the interconnection point known to all access and transit ASes. This enables individual (re-)marking and possibly forwarding treatment adaptation to the original QoS class setup of the respective originating AS. The extended community provides the means to signal QoS markings on different layers, which are linked together in QoS Class Sets. It provides inter-domain and cross-layer insight into the QoS class mapping of the source AS with minimal signalling traffic.

Acknowledgments TODO acknowledge. Jeff Haas, Ondřej Zajíček for major comments and suggestions. Authors of BGP YANG.