Envoy control plane to data plane xDS v3: SotW omission versus Delta removed_resources semantics

Integration boundary

The integration boundary between an xDS v3 control plane and Envoy data plane must reconcile two resource-removal mechanisms: state-of-the-world (SotW) streams signal deletion by omitting a resource from the full snapshot, while Delta streams carry explicit removed_resources entries. A control plane that serves some resource types via SotW and others via Delta—or that migrates between the two without a coordinated cutover—can leave stale listeners, clusters, or routes in the data plane because the omission semantics are not interchangeable.

Constraints

The v3 API version itself is a hard wire-level boundary; v2 resources are rejected outright, so version skew between control plane and data plane manifests as configuration failure rather than graceful degradation. Additionally, the optional resource TTL field introduces a third removal signal whose post-expiry behavior (retain last-known versus drop) is a policy the control plane must declare, yet the interaction between TTL expiry and the two removal mechanisms is not universally documented for mixed-delivery deployments.

Open questions

1. When a control plane mixes SotW and Delta streams for different resource types, what are the exact conditions under which a resource removed via one mechanism remains present because the other mechanism did not signal its removal?
2. Does a resource TTL expiry on a Delta stream trigger an implicit removed_resources entry, or must the control plane emit one explicitly to avoid stale configuration?
3. How should a control plane coordinate a migration from SotW to Delta (or vice versa) for a given resource type without leaving orphaned resources in the data plane?