Summary

  • RFC 10039 defines a routing domain by tenant forwarding behavior, not by an ASN, IGP area or organizational chart. Every gateway on that domain must nevertheless be configured with the same DOMAIN-ID.
  • D-PATH turns that shared declaration into a route-control input. A local ID found in the path marks a route as looped, while path length also enters best-path selection; a wrong declaration can therefore reject traffic as effectively as a real loop.

The diagram looked settled. Two data centres sat inside one operator's ASN. An EVPN fabric occupied each site, an IPVPN crossed the middle, and two redundant gateway pairs re-originated the same tenant prefixes. The change sheet assigned a D-PATH identifier to every coloured box. Nothing on the sheet explained why the boxes were domains.

That missing sentence is the deployment.

RFC 10039 gives operators a standard way to interconnect EVPN and IPVPN domains for tenant inter-subnet forwarding. Its new optional, transitive BGP Domain Path attribute records the domains through which an interworking route has passed. A gateway can detect its own domain in that history and avoid sending the route around again. The procedure addresses a real failure mode: one gateway translates an IPVPN route into EVPN, another sees the EVPN copy and sends it back into IPVPN, and redundant interconnection becomes a control-plane loop.

But D-PATH does not discover the domain boundary. It consumes one.

The domain is a forwarding fact

RFC 10039's definition is deliberately more precise than the familiar administrative labels. Two provider edges belong to the same domain when they serve the same tenant and traffic between them does not require a tenant-space IP lookup at a transit router. A gateway interconnects domains when such a lookup is required at the boundary.

An Autonomous System is therefore not a shortcut. The RFC says one domain may extend across several ASes and one AS may contain several domains. An IGP instance is not decisive either. A data-centre name, region, business unit and vendor fabric are possible planning labels, but none proves the forwarding condition.

This matters because the wire representation looks deceptively familiar. A DOMAIN-ID contains a four-octet Global Administrator and a two-octet Local Administrator. The first field may contain a public or private ASN, an IPv4 address or another value. That flexibility helps allocate identifiers and troubleshoot them. It does not convert the chosen notation into an assertion that the domain equals the ASN or that the named address controls it.

The operator must supply the meaning. Each domain needs a unique DOMAIN-ID. All gateway PEs attached to the same domain must use the same value. A gateway connecting two domains has two distinct identities, one for each side. Depending on the design, assignment may apply to an entire interconnection or separately to a tenant IP-VRF. The distinction becomes material when routes leak between VRFs: loop detection is performed in the context of the receiving VRF's configured identities.

A label becomes an executable veto

The attribute is not an inventory annotation. Once enabled, it changes treatment of the route.

Each D-PATH entry pairs a six-octet DOMAIN-ID with an ISF_SAFI_TYPE. The SAFI value explains whether that step used EVPN, IPVPN or, for some locally originated cases, zero. It is useful for checking whether interworking followed the intended sequence. It is irrelevant to loop detection. If any DOMAIN-ID in an incoming path matches any local ID associated with the IP-VRF, the gateway treats the route as looped for the specified procedures regardless of the accompanying SAFI type.

That rule is powerful precisely because it is simple. It also means a collision is not cosmetic. If two genuinely different domains reuse an ID, a route can be classified as a return to a place it never visited. If redundant gateways name the same domain differently, each may fail to recognize a returning route. If an ID is bound at the wrong VRF scope, route leaking can make the comparison describe a different control surface from the one engineers intended.

D-PATH also enters route selection. When a PE compares eligible EVPN and non-EVPN inter-subnet-forwarding routes for the same prefix, it applies LOCAL_PREF and then removes candidates that do not have the shortest D-PATH. A route without D-PATH counts as length zero. The number is a count of declared traversals, not a measurement of fibre distance, latency, congestion, commercial cost or trust. Yet it can decide which route survives.

An ID allocation error has therefore crossed the line from documentation into forwarding authority. A register entry can suppress a legitimate candidate, preserve a looped candidate or alter the selected encapsulation family. The proper evidence is not a screenshot showing that code point 36 exists in a route. It is a joined record showing that the boundary model was agreed, applied consistently and observed in the RIB, FIB and packet path.

Propagation is a policy choice

RFC 10039 does not silently turn on this authority. D-PATH is disabled by default and restricted to IPVPN and EVPN routes. A gateway must be explicitly configured to use it.

The default No Propagation Mode re-initializes BGP Path Attributes when a route is re-originated into another domain. D-PATH is not carried. This limits the attributes that a remote domain inherits, but redundant gateways may remain exposed to a loop. The RFC notes that routing policy or a Route Origin extended community may mitigate that risk without guaranteeing detection of every case.

Uniform Propagation Mode retains a bounded set of commonly used attributes. By default, that set includes AS_PATH, D-PATH where applicable, and certain iBGP-only attributes for iBGP peers. Other attributes should not cross unless import or export policy expressly permits them. This mode offers downstream visibility, but it also carries semantically inappropriate or maliciously supplied state farther from its origin.

Neither mode is a universal virtue. No Propagation trades provenance for isolation. Uniform Propagation trades isolation for a controlled continuity of evidence. The decision belongs at each boundary and should state which attributes are admitted, which are re-initialized and who owns exceptions. “D-PATH enabled” is not a sufficient change description.

Error handling cannot repair semantic disagreement

The protocol handles malformed structure carefully. A malformed D-PATH or a D-PATH attached to an unsupported address family receives treat-as-withdraw behavior under RFC 7606. Unknown SAFI-type values may be accepted because they do not affect the identity comparison. If the attribute appears more than once, all instances after the first are discarded and the UPDATE continues.

Those rules contain damaged encodings. They cannot detect two well-formed but conflicting accounts of the world. A forged or accidentally reused DOMAIN-ID can be syntactically perfect. So can an attribute that should never have crossed a boundary. RFC 10039 explicitly warns that incorrect IDs or inconsistent support may produce false-positive loop detection, traffic discarding, or suboptimal and inconsistent routing.

The “walled garden” restriction is another boundary that must be proved. A conforming PE removes D-PATH before advertising a prefix to a customer edge as ordinary SAFI 1 unicast. Upgraded PEs should apply local policy to D-PATH-bearing routes arriving from peers believed not to support the feature. The RFC leaves the mechanism for determining that peer state outside its scope. A rollout plan must fill the gap with version inventory and tests rather than assumption.

Build a domain-boundary accord

Before configuration, the operator needs one compact accord for each tenant and interconnection. It should begin with the forwarding test that makes two PEs members of one domain. It should then name the ID allocator, the uniqueness scope, the collision search and the exact gateways and VRFs that will receive the value. An ASN-shaped notation may be convenient, but the record should say explicitly that notation is not topology proof.

The rollout portion should list software versions and tested feature support; choose No Propagation or Uniform Propagation for every boundary; record the permitted attribute set; define how locally originated routes are named; and specify what happens when one gateway cannot participate. The owner must be able to explain how a returned route should look at each hop before a configuration is applied.

Tests should include more than a happy path. Send a legitimate route through the expected sequence and confirm its domain history. Inject a local ID and observe the loop response. Use an unknown SAFI type and verify that identity matching remains intact. Present a malformed attribute and confirm bounded withdrawal. Include a mixed-version peer. Finally, inspect the customer-edge advertisement and prove that D-PATH did not escape in SAFI 1.

The evidence must follow one prefix through adjacent RIBs, the selected route, the programmed FIB and an actual packet canary. Configuration acceptance proves only that a parser accepted a command. A visible D-PATH proves only that some speaker carried a claim. Loop prevention is established only when the right claim is shared by every relevant gateway and the expected legitimate and illegitimate paths separate in observed behavior.

Keep the conclusion narrower than the mechanism

RFC 4271 supplies the base BGP decision process. RFC 4364 supplies the IPVPN setting. RFC 7432, RFC 9135 and RFC 9136 supply the EVPN and routed-prefix context. Together with RFC 10039, they describe how the mechanism should behave. They do not report whether a named vendor implements it, whether an operator has enabled it, or whether any production route follows the diagram.

That boundary protects the analysis from becoming marketing. A standards-track mechanism is a public rule. An IANA assignment is a public registry fact. A configured DOMAIN-ID is a local assertion. A selected route is a device decision. A forwarding result is an observation. None can substitute for the next.

Sources