Summary

  • The 28 October IDR working-group draft draft-ietf-idr-rt-derived-community-13 defines an Extended Community derived from a Route Target. It keeps the same Global Administrator and Local Administrator values but changes the sub-type. By this draft, the derived tag identifies its parent RT; it neither constrains route distribution nor causes import into a VRF. The draft is in IESG Evaluation, intended Informational, and has not become an RFC.
  • IANA already lists six RT-derived code-point assignments that cite a 2021 predecessor draft. The new draft asks to update those references and add further values. A registry entry records a code point; it does not turn a route-association label into an import instruction or show that a network has deployed one.

One VPN, ten routers, two different questions

The draft's example starts with a VPN running across ten provider-edge routers. A Route Target, RT1, is configured so those routers import VPN routes with that target into their virtual routing and forwarding tables. A different BGP route needs to be associated with the same VPN but delivered only to some of the ten routers. If the operator attaches RT1 to that second route, the existing import and distribution machinery has a reason to take it to the whole VPN. If the operator invents a new Route Target for each subset, every subset gets a new identity for what should be one VPN association. Neither choice says exactly what the operator meant.

The proposed RT-derived Extended Community is a tag for the association question. It carries the same administrator values as its parent Route Target, while its sub-type is changed to a registered derived value. A router can recover which RT it refers to. Yet the draft's Section 2 strips away the two privileges normally implied by the RT: constraining distribution and importing the route into a VRF. It cannot be carried in RFC 4684's Route Target membership NLRI, and policy matching Route Targets does not match the derived tag. That is a deliberately narrow identity, not a weaker copy of a distribution command.

The distinction is easy to lose because the administrator numbers remain the same. In BGP, a Route Target is itself an Extended Community; RFC 4360 describes it as identifying routers that may receive routes carrying it. The new tag reuses the numeric association so separate subsets can speak about the same VPN. Its changed sub-type tells the receiving policy to stop before treating that association as permission. Same value fields, different authority on the wire.

A registry can name the tag. It cannot decide its job.

The live IANA BGP Extended Communities registries already contain several RT-derived-EC assignments at sub-type 0x15 and an IPv6-address-specific type 0x0015, with references to a 2021 predecessor draft. The current draft says six assignments exist. It asks IANA to update their references, rename the EVPN entry and assign values for a UUID-based IPv6 RT counterpart and two Transport Class counterparts. Those latter assignments are requests in an Internet-Draft. Their presence in an IANA Considerations section is not a receipt for completed allocation.

Nor is 0x02 to 0x15 a universal conversion formula. The draft says that pair is common and desirable where available, then states that Table 1 establishes the correspondence. One IPv6-address-specific RT in its table has value 0x0011, with a requested derived value still to be assigned. A parser or policy that guesses permission from familiar-looking bytes instead of the exact registered type and sub-type could cross precisely the boundary the proposal draws.

The draft also refuses to define what a receiving router should do with every derived tag. A future document for each use must specify the AFI/SAFI and route types that carry it and the receiver action. Until then the tag names a relationship. It is not a command to install, import, advertise or forward anything. That separation creates useful space for reuse, but it places the next governance decision in the use-specific specification. Whoever writes that next rule decides when a label becomes behavior.

At the 28 October check, the Datatracker lists revision 13 under IESG Evaluation with an intended Informational status and an IANA review marked “Version Changed – Review Needed.” Those are process states. The public documents establish the proposed semantics and existing code points, but provide no named deployment trace or incident in which a derived tag caused an import mistake. A final RFC, IANA updates and implementation evidence would change what can be said about adoption.