Summary

  • Draft -13 copies a Route Target’s administrator values into a different Extended Community subtype, but gives that copy no route-distribution or VRF-import effect.
  • The transitive copy can travel across AS boundaries; an EBGP filter keyed to the Route Target subtype may not match it.

BGP labels are small. Their job descriptions are not.

A Route Target (RT) can tell a VPN where a route belongs. In the deployed machinery, it can constrain which routers receive a route and cause a matching VRF to import it. An ordinary Extended Community can carry a related label without claiming those powers. The difference matters when a route must be associated with a VPN on only some of its provider-edge routers.

That is the case behind draft -13, updated on 28 October. Say ten provider-edge routers import VPN routes carrying RT1. Another route must be associated with that VPN on a subset of them, but its distribution is controlled by a different RT3. Reusing RT1 as the association label would suggest that every RT1-importing router should receive it. Giving each subset a different label would multiply labels for the same VPN.

The draft’s answer is a derived Extended Community: preserve the RT’s Global Administrator and Local Administrator values, change the subtype, and call the result an RT-derived EC. The values point back to the RT; the type says the copy is not itself an RT.

That distinction is explicit. Under this draft, an RT-derived EC does not constrain route propagation, import a route into a VRF, or match a policy that looks for the corresponding RT. It also cannot travel in the Route Target Membership NLRI defined by RFC 4684. The draft defines the label’s correspondence and code points. A separate document must define what a receiver does with it.

Then comes the boundary problem. The draft preserves the high-order Type Field octet, so an RT-derived EC corresponding to a transitive RT remains transitive. Absent contrary policy, it can cross AS boundaries. A policy written to filter or rewrite the RT subtype will not automatically catch the derived subtype. Same administrator and local values; different code point; different match result.

The draft records assignment of subtype 0x15 in several Extended Community registries, including transitive AS-specific forms. It does not assign that value to every possible RT format; other correspondences remain requests or placeholders. RFC 4360 explains why Extended Community type fields are useful for policy. Here, the subtype is precisely where an operator’s filter can miss the family resemblance.

An IETF Operations Directorate review of revision 13, completed on 30 October, called for a dedicated Operational Considerations section. Reviewer Gen Chen named inter-AS filtering and leakage risk, scope boundaries and legacy BGP behavior, and pointed to filtering subtype 0x15 at EBGP boundaries when its propagation is unwanted. That is a review comment, not evidence of a leak. It identifies the line between encoding a value and telling operators how it behaves in mixed networks.

As of 2 November, the draft is in IESG Evaluation and scheduled for the 5 November telechat. An informational encoding document can settle what bits correspond without settling who must filter them, what older speakers do, or how each later use should be contained. The subtype may be one byte. The policy inventory is the larger job.

Sources: draft -13 · Operations Directorate review · RFC 4360 · RFC 4684