Extended Communities Derived from Route Targets

Introduction Consider a VPN with 10 PEs. A Route Target (say RT1) 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. 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, we want a different Extended Community value. There can be multiple subsets of nodes each needing to bind some advertisement to the VPN. So using e.g. RT3 for binding would mean that we end up with a lot of different binding communities for the same VPN, when we would like one value to represent the association. Thus we want and use a new Extended Community to represent this binding. 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. We call this 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 the RT-derived Extended Community derived from it have the same encoding apart from the sub-type, and carry the same Global Administrator and Local Administrator values. 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 therefore the same Global Administrator format and the same transitivity - and the same Value Field, and differ only in the sub-type. An Extended Community is derived from a Route Target by replacing the Route Target's sub-type with that of its corresponding RT-derived-EC; the Route Target is recovered by the reverse replacement. 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 does 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 formating 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 state: the AFI/SAFI and route types on which the RT-derived EC is carried; what a receiver does on the basis of receiving it .

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 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 above 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 is therefore appropriate for the corresponding RT-derived EC. Documents specifying a use of RT-derived ECs are expected to state the trust assumptions under which the correspondence they define is valid.

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.