Extended Communities Derived from Route Targets

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 17 May 2025.¶

Copyright Notice

Copyright (c) 2024 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

Consider a VPN with 10 PEs. A Route Target (say RT1) [RFC4360] is configured for the VPN and all PEs will import VPN routes with RT1 into their corresponding VRF. The RT is an Extended Community (say EC1), with its sub-type being 0x02. While RT1 and EC1 have the same encoding, typically when we mention a Route Target, its property of being able to control the route propagation and importation is implied. When we just mention an Extended Community, that property is not implied.¶

Now consider that another BGP route needs to be imported by some but not all those PEs into their VRF. The route could be of any SAFI/type (it may not need to be a VPN prefix), but it needs to be associated with the VPN on those PEs. The exact meaning of "association" here does not matter, but the key is that those PEs need to know that the route is related to that VPN. Some examples of the association are given in Section 3.1 and Section 3.2.¶

To control the propagation to those PEs, a different Route Target (say RT3) is attached to the route. For those PE to associate the route with the VPN, an Extended Community (say EC2) is attached. Even though RT1/EC1 is already used for route importation into the VPN, EC2 needs to be different from RT1/EC1, because if EC1 was used, the route would be propagated to and imported by all the 10 PEs. EC2 cannot be the same as RT3 either, because there could be other routes to be propagated to those same set of PEs yet those other routes are not related to the VPN.¶

While EC2 can be any Extended Community (that is not a RT) configured on the originating and receiving PEs to map it to the VPN, it is convenient if EC2 is derived from the RT1/EC1, e.g. the sub-type of RT1/EC1 is changed to a new known value while everything else remains the same. We call this a Route Target derived Extended Community, or RT-derived EC. A new sub-type is assigned specifically for this purpose (see IANA considerations).¶

This document only specifies a way to derive an Extended Community from a Route Target Extended Community using IANA-assigned Extended Community sub-types (or Extended Community Type in case of IPv6-Address-Specific Extended Community [RFC5701]). Any protocol/feature that can take advantages of the convenience of generic derivation may use them, or not use them at its own discretion, and how they are used is outside the scope of this document.¶

2. Route Target Type/sub-type Conventions

It may be expected by some people that Route Targets are Extended Communities with sub-type 0x02 (or with Type 0x0002 in case of IPv6 Address Specific Extended Community). However, the only official specification are in [RFC7153] [RFC7432] and are only for the following types:¶

• Type 0x00 (Transitive Two-Octet AS-Specific EC)¶

• Type 0x01 (Transitive IPv4-Address-Specific EC)¶

• Type 0x02 (Transitive Four-Octet AS-Specific EC)¶

• Type 0x06 (EVPN AS-Specific EC)¶

• Type 0x0002 (Transitive IPv6-Address-Specific Route Target)¶

• Type 0x0011 (Transitive IPv6-Address-Specific EC, UUID-based Route Target))¶

While it may be desired to follow the unwritten convention and assign sub-type 0x02 for future Route Targets of future types of ECs, there is no guarantee of that. For example, Type 0x0011 is assigned for UUID-based Route Target that imposes as an IPv6 Address Specific EC (even though UUID is not an IPv6 address).¶

IANA has assigned sub-type 0x15 (or Type 0x0015 in case of IPv6 Address Specific EC) to indicate an EC is derived from a Route Target that has sub-type 0x02 (or type 0x0002 in case of IPv6 Address Specific EC).¶

All those can only be registered with the known types listed above. When a new type is defined and registered, the corresponding 0x02 sub-type may be registered for Route Target purpose or for something else, and there is no guarantee that the 0x15 sub-type will not be registered for something else as well (than for RT derivation). As a result, the mapping between sub-type 0x02 and 0x15, type 0x0002 and 0x0015, type 0x0011 and TBD are only defined for the known types listed above.¶

Of course, when a new type of extended community is defined and registered, and a sub-type under this new type is registered for Route Target purposes, it is suggested to also register a sub-type for derivation purposes.¶

3. Use Cases

The following are a few examples of use cases. To reiterate, these are example scenarios where generic RT-derived ECs could be used (when the routes to which they are attached provide enough context). It is not the intention of this document to mandate that it must be used.¶

"Using the TRTS translated from the IRTS is necessary in order to
refrain from importing "route-filter" VRF routes into VPN VRFs that
would import the same route-targets.  The translaation from the IRTS
is done as follows.  For a given IRT, the equivalent translated RT
(TRT) is constructed by means of swapping the value of the low-order
octet of the Type field for the IRT (as specified in
[I-D.ietf-idr-rt-derived-community])."

4. Security Considerations

This document specifies a way to derive an Extended Community from a Route Target Extended Community and does not specify how derived Extended Communities are used. As a result, this document does not need security considerations. Any potential security concerns need be addressed by documents that specify the actual usage.¶

5. IANA Assignments

This document requests IANA to assign a new Type value (0x0016 suggested) for "UUID-RT-derived-EC".¶

IANA has assign a new sub-type "RT-derived-EC" with value 0x15 in the following registries:¶

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

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

• Transitive IPv4-Address-Specific Extended Community Sub-Types¶

• Non-Transitive Opaque Extended Community Sub-Types¶

• EVPN Extended Community Sub-Types¶

IANA has also assigned a new type "RT-derived-EC" with value 0x0015 in the following registry:¶

• Transitive IPv6-Address-Specific Extended Community Types¶

If and when additional Extended Community types are defined with a Route Target sub-type, the "RT-derived-EC" sub-type may also be registered for those new types, preferably with the same value.¶

6. Acknowledgements

The authors thank Robert Raszuk for his valuable comments and suggestions.¶

Authors' Addresses