xDS transport and versioning evolution
summary
Proposal replaces opaque xDS names with a UDPA URI that embeds an optional authority, resource type, id, context params and client-only directives to enable cacheable keys, fine‑grained federation (delegation, redirection, alt failover) and per‑resource variants. It adds two collection types — list collections with inline or referenced entries and scalable glob collections used to implement LEDS for per‑endpoint updates. Versioning shifts to minor/patch versioning (rare major bumps, yearly minor deprecations, per‑change patches); v2 removal and Q4 core work are planned.
AI-written summary · about
chapters (19)
- 0:00Start
- 0:40XDS transport limitations
- 8:40udpa:// URI Examples
- 10:11Context Parameters
- 12:37List Collections
- 13:59Glob Collections
- 15:13Authority Delegation
- 16:20Authority Failover
- 17:10Envoy implementation
- 18:20Versioning in Envoy
- 19:29Stop the clock!
- 19:56Major versioning: The Good
- 20:44Major versioning: The Ugly
- 21:33New plan
- 21:52Minor/patch versioning
- 22:35Technical details
- 23:01Implications
- 23:34New versioning roadmap
- 24:09Resources
related talks
10mThe Universal Dataplane API (UDPA): Envoy's Next Generation APIs
22mDos and Don’ts: Designing an XDS Backend for the LinkedIn Scale
08mLightning Talk: It’s 10pm, do you know what your proxy is doing? Understanding...
16mHow Data Distribution Service (DDS) enables secure
25mAdapting Our XDS Control Plane for Proxyless gRPC
27mSpeeding up Istio: Our Journey Implementing Delta xDS
33mBringing packet queueing to XDP
25mEvolution of Direct Server Return (DSR) implementation for containerized applications