Extended Communities Derived from Route Targets

Introduction Consider a Virtual Private Network (VPN) with 10 Provider Edge devides (PEs). A Route Target (say RT1) is configured for the VPN, and all PEs import VPN routes with RT1 into their corresponding VPN Routing and Forwarding tables (VRFs). The RT is an Extended Community (say EC1), with its sub-type being 0x02. While RT1 and EC1 have the same encoding, typically, when Route Target is mentioned, its property of being able to control the route propagation and importation is implied. When Extended Community is mentioned, 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 Subsequent Address Family Identifier (SAFI) or 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. To control the propagation to those PEs, a different Route Target (say RT3) is attached to the route. For those PEs to associate the route with the VPN, an Extended Community (say EC2) is attached. While it is tempting to just use the existing (RT1/EC1) for marking this restricted distribution information as being associated with the VPN, this has the drawback of implying the distribution is to all the PEs in the VPN. As that is not desired, a different Extended Community value is needed. There can be multiple subsets of nodes each needing to bind some advertisement to the VPN. So using e.g. RT3 for binding would lead to a lot of different binding communities for the same VPN, while a single new Extended Community to represent this binding is desired. While EC2 can be any Extended Community (that is not an 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. This is called a Route-Target-derived Extended Community, or RT-derived EC, with a new sub-type assigned specifically for this purpose (). The purpose of this document is to describe the derivation of Extended Communities from Route Targets, to describe how the resulting Extended Communities differ from Route Targets, and to record the code points assigned for them so that other documents have a stable reference. This document does not specify how RT-derived ECs are used - what a receiver does on the basis of receiving one is left to the documents specifying each use.

RT-derived Extended Communities A Route Target Extended Community and its corresponding RT-derived Extended Community have the same length and the same Value field. Their encodings differ only in the registered sub-type or Type value identified in . They differ in what that value means. A Route Target identifies the set of routers that may receive a set of routes, and in deployment it both constrains the distribution of routes carrying it and causes those routes to be imported into VRFs configured to import it. An RT-derived EC carries the Route Target's value without either property: it identifies the Route Target from which it is derived and nothing more. The presence of an RT-derived EC on a route has no effect, by virtue of this document, on the propagation of that route or on its importation into any VRF. An RT-derived EC cannot be carried in the Route Target membership NLRI of , so it cannot be used to constrain route distribution by that mechanism, and policy that matches Route Targets will not match the corresponding RT-derived EC. Any effect that an RT-derived EC has on the handling of a route is defined by the document specifying that use of it. For an Extended Community type for which a Route Target is registered, a corresponding "RT-derived-EC" sub-type may be registered. Where no RT-derived-EC sub-type is registered for a Route Target, the derivation is not defined for that Route Target. An RT-derived EC and the Route Target for which it is registered are counterparts. They have the same length, the same high-order octet of the Type field, and an identical Value field. Derivation replaces only the second octet, using the correspondence in ; all other octets are copied unchanged. This preserves the transitivity indication and every bit of the original value. The reverse replacement recovers the corresponding Route Target. Route Targets are commonly assumed to be registered with sub-type 0x02, and RT-derived-ECs with sub-type 0x15. That is a convention rather than a property of the mechanism: the correspondence between a Route Target and its RT-derived-EC is established by , not by the sub-type values themselves. Registering both at those values where it is available is desirable, and the existing/requested assignments do so wherever possible, but nothing depends on it. The IANA registries for Extended Community sub-type values are organized per Extended Community type . For the IPv6-Address-Specific Extended Community , the registry records the two high-order octets as a single Type value rather than recording the sub-type separately, so the assignments below appear there as type values 0x0002 and 0x0015 rather than as sub-type values 0x02 and 0x15. The operation on the wire is the same in both cases. The following correspondence is listed based on the existing and requested assignments (). The name of the Route Target and that of the derived Extended Community are omitted due to formatting limitations. Registry RT Value Derived Value Transitive Two-Octet AS-Specific Sub-Types 0x02 0x15 Transitive Four-Octet AS-Specific Sub-Types 0x02 0x15 Transitive IPv4-Address-Specific Sub-Types 0x02 0x15 Non-Transitive Opaque Sub-Types 0x02 0x15 EVPN Sub-Types 0x02 0x15 Transitive IPv6-Address-Specific Types 0x0002 0x0015 Transitive IPv6-Address-Specific Types 0x0011 TBD1 Transitive Transport Class Sub-Types 0x02 TBD2 Non-Transitive Transport Class Sub-Types 0x02 TBD3 This document does not specify how RT-derived ECs are used. A document specifying a use of RT-derived ECs is expected to identify the applicable AFI/SAFI and route types, describe the receiver's processing, and specify how multiple or conflicting RT-derived ECs and missing local associations are handled. It is also expected to state the trust assumptions for that use, as discussed in . .

IANA Considerations IANA has assigned a new sub-type "RT-derived-EC" with value 0x15 in the following registries in the Border Gateway Protocol (BGP) Extended Communities registry group : 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 This document requests IANA to change the "RT-derived-EC" in the EVPN Extended Community Sub-Types registry to "ES-Import RT-derived-EC". IANA has also assigned a new type "RT-derived-EC" with value 0x0015 in the following registry: Transitive IPv6-Address-Specific Extended Community Types This document requests IANA to change the reference for the above six assignments to this document. This document requests IANA to assign a new Type value (TBD1, 0x0016 suggested) for "UUID-RT-derived-EC" in the Transitive IPv6-Address-Specific Extended Community Types registry. This document additionally requests IANA to assign a new sub-type "RT-derived-EC" with value (TBD2/TBD3, 0x15 suggested) in the following registries: Transitive Transport Class Extended Community Sub-Types Non-Transitive Transport Class Extended Community Sub-Types

Security Considerations This document describes a way to derive an Extended Community from a Route Target Extended Community and does not specify how derived Extended Communities are used. Security considerations arising from a particular use of RT-derived ECs are addressed in the document specifying that use. The following consideration arises from the derivation itself. Because the derivation preserves the high-order octet of the Type Field, an RT-derived EC corresponding to a transitive Route Target is itself transitive and will, absent policy to the contrary, propagate across AS boundaries. Route Targets are commonly filtered or rewritten at AS boundaries, but such policy matches on the Route Target code point and will not match the corresponding RT-derived EC; nor can an RT-derived EC be constrained by the mechanism of . An RT-derived EC received from an external peer whose value corresponds to a locally configured Route Target may therefore cause a receiving router to interpret it inappropriately. The same boundary policy that an operator applies to a Route Target should therefore be applied to the corresponding RT-derived EC as well: the filtering or rewriting should be done the same way to the RT-derived ECs. Documents specifying a use of RT-derived ECs are expected to state the trust assumptions under which the correspondence they define is valid. In addition, the filtering guidance in the Security Considerations of is applicable for this document as well.

Operational Considerations Besides the operational considerations that the document for a specific use case should provide, a general consideration is related to the filtering or rewriting of RTs mentioned in : policies with RT filtering or rewritting should filter or rewrite the corresponding derived Extended Communities as well.

Acknowledgements The authors thank Ketan Talaulikar and Robert Raszuk for their valuable comments and suggestions.

Appendix A. An Example Use Case Section 9.5 "EVI-RT Extended Community" of describes a situation similar to the above. As a solution, four EVPN specific EVI-RT ECs are defined, each mapping to a type of Route Target for the corresponding EVPN instance. As a theoretical alternative, an RT-derived EC described in this document could be used instead - just derive a generic EC from the EVI RT. Note that this document does not attempt to change the existing procedures in , but merely use it for illustration purposes.