Summary

  • RFC 10039 defines the optional transitive D-PATH attribute for EVPN and IPVPN inter-subnet routes. A gateway can reject re-export when the path contains one of its local DOMAIN-IDs, and route selection can prefer the shortest D-PATH after Local Preference.
  • D-PATH describes declared control-plane history. It does not authenticate a domain, prove that redundant gateways share the same configuration, preserve every attribute, establish hardware forwarding, or show that tenant traffic arrived.
  • A defensible rollout keeps six receipts separate: DOMAIN-ID configuration, route import and re-origination, attribute propagation, best-path decision, RIB/FIB realization, and bidirectional tenant tests.

A new RFC closes one loop and opens an audit question

RFC 10039, published in September 2026 as a Proposed Standard, addresses a modern tenant-network problem. An IP prefix may be carried as an EVPN route in one domain and as a VPN-IPv4 or VPN-IPv6 route in another. A gateway PE imports the route into an IP-VRF, changes the encapsulation context, and re-originates reachability for the adjacent domain.

With two gateways, the same prefix can return. One gateway may learn an IPVPN route, turn it into an EVPN prefix route, and a second gateway may feed it back into IPVPN. Ordinary AS_PATH logic is not sufficient to describe every such domain transition. RFC 10039 therefore assigns BGP Path Attribute code 36 to Domain Path, or D-PATH.

The wire object is precise. D-PATH is optional and transitive. It contains an ordered sequence of <DOMAIN-ID:ISF_SAFI_TYPE> entries. The SAFI component records whether the gateway received the route through EVPN, IPVPN or a local ISF source; loop detection compares the DOMAIN-ID regardless of that informational value.

That precision is the first receipt, not the verdict.

DOMAIN-ID is configured identity, not authenticated identity

All gateway PEs attached to one domain must use the same DOMAIN-ID. A gateway connecting two domains must use two distinct values. Where a tenant spans operators, identifiers must be unique enough to avoid collisions. Yet the format deliberately permits an ASN, an IPv4-shaped value or another opaque value. It is a coordination key, not a signature.

A false duplicate can be destructive. If one domain accidentally reuses another's value, a gateway can label a legitimate route as looped, prevent re-export and discard useful reachability. If redundant gateways use different values for the same domain, a returning route may evade the intended check. A clean D-PATH display proves only what the participating speakers encoded under their current configuration.

The configuration receipt must therefore name the tenant or peering scope, gateway, software generation, effective DOMAIN-ID, adjacent domain, change authority and activation time. Comparing intended configuration with operational readback across every redundant gateway is not paperwork beside the protocol. It is the condition that gives the protocol record a coherent meaning.

Re-origination breaks the illusion of transparent transit

A gateway does not merely forward an unchanged UPDATE. It imports an eligible route into the IP-VRF and originates a route for another AFI/SAFI and encapsulation context. Under Uniform Propagation Mode it prepends the domain from which the route was received. If a received D-PATH already contains a locally configured DOMAIN-ID, the route is flagged looped and cannot be exported onward.

Under the default No Propagation Mode, attributes are re-initialized and D-PATH is not propagated. That reduces the reach of imported attributes, but RFC 10039 warns that redundant gateways can then remain vulnerable to loops unless other policy works. Uniform Propagation Mode retains a bounded set—such as AS_PATH, D-PATH, MED, AIGP and selected communities—while excluding or re-initializing Route Targets, encapsulation information and EVPN-specific communities where their old meaning would be unsafe.

Neither mode means “copy everything.” Only the selected best path's attributes should normally cross the boundary. An audit must compare the received route, the IP-VRF import, the route chosen for re-origination, the outbound attribute set and the adjacent receiver's view. Otherwise a path shown at the destination can conceal where another attribute was removed, reset or rewritten.

Shorter changes preference; it does not measure quality

RFC 10039 inserts one comparison immediately after Local Preference. Among eligible EVPN and non-EVPN ISF candidates, paths without the shortest D-PATH are removed. A route with no D-PATH counts as length zero. Standard BGP selection then continues. Later rules can prefer EVPN Route Type 2 over Route Type 5, and ECMP remains conditional on local policy.

The domain count is therefore a bounded selection input. It is not latency, capacity, cost, administrative trust or physical diversity. The RFC's example can select an EVPN path with one domain entry over an IPVPN path with two even when their AS_PATH and MED suggest a different story. That is correct under the specified order; it is not evidence that the chosen path is better for an application.

The best-path receipt must record all candidates, their Local Preference, D-PATH members, AFI/SAFI, route type, ordinary BGP attributes, policy epoch and rejection reason. A screenshot of the winner erases the choice it claims to explain.

The forwarding plane belongs to a later reality layer

Once a route is selected, packets follow the forwarding rules of that route's AFI/SAFI. An EVPN choice may invoke EVPN-specific recursive resolution; an IPVPN-only PE cannot use all of those facilities. Labels, SIDs, tunnels, adjacency state and hardware resources remain local execution objects.

That is why a loop-free RIB is not a delivered service. The prefix may fail recursive next-hop resolution. A label or SID may be missing or stale. Different line cards may carry different generations. The return path may choose another gateway. MTU, policy, security or the tenant endpoint may still fail.

Proof proceeds in order: show the selected route in the correct IP-VRF; show resolved next hops and encapsulation; show the programmed FIB on each relevant forwarding element; then send positive and negative canaries in both directions and observe them at the tenant edges. Application success, loss, latency and rollback thresholds belong to that final receipt, not to D-PATH.

Error handling protects the session by narrowing the claim

A malformed D-PATH invokes treat-as-withdraw under RFC 7606. D-PATH on an unsupported AFI/SAFI does too. Unknown SAFI values inside otherwise valid domain entries may be accepted, and multiple attributes are reduced to the first. These choices preserve the BGP session while limiting what one bad route can assert.

The security boundary is equally direct. A transitive attribute can carry syntactically valid but false domain information. RFC 10039 confines D-PATH to the VPN “walled garden,” requires removal before SAFI 1 advertisement to a CE, and tells operators to validate contents at domain boundaries. Protocol validity is not provenance.

Heng Lu's Running-Code Primacy supplies the right reading. The RFC defines the minimum shared grammar. Operators retain the decisions that make it real: identifier allocation, propagation mode, import/export policy, deployment order, test evidence and rollback. Publication is coordination; running gateways and observed packets are adoption.