We would like to take a holistic (i.e. not point feature) approach to evolving the xDS transport. The primary motivations for this work are:

• Federation of the control plane (for example failover between two independently managed control planes, bridging independent service meshes).
• Enabling the LEDS use case (Locality endpoint discovery service (LEDS) #10373 , improving xDS client resource scalability.
• Improving control plane reliability via caching layers.
• Improving control plane scalability via mapping of xDS resources to non-xDS transports (e.g. HTTP, filesystem). This will support stateless CDN serving of xDS resources for example, which is of benefit for scale-out applications such as xDS mobile clients. The use case here is a massive number of clients, with limited configuration size (no plans for incremental xDS equivalent).
• Regularizing xDS; eliminating technical debt such as the special case handling of LDS/CDS vs. RDS/EDS, aliases, etc.

The concrete proposal is available at:

• Summary - https://docs.google.com/document/d/1m5_Q9LUlzvDdImP0jqh1lSTrLMldsApTQX6ibbd3i7c/edit?ts=5ec40d08#
• Full document - https://docs.google.com/document/d/1zZav-IYxMO0mP2A7y5XHBa9v0eXyirw1CxrLLSUqWR8/edit?ts=5ec43456#heading=h.w8hw2zbv3jwl

The PoR proposal involves:

• Introducing structured resource names with URI representations. Resources now have names like udpa://some-authority/v3-route-config/some/name?node.cluser=foo&client_feature.bar=baz.
• Naming collections of resources, e.g. udpa://some-authority/v3-listener/foo/*.
• Enhancing ConfigSource to provide a map from authority to transport. At the same time, modify ADS semantics to support > 1 ADS stream for a client.
• Replacing traditional uses of Node metadata for xDS resource qualification with context parameters in the UDPA resource name. This will limit the exposure of Node information in resource naming and addressing.
• Adding support for redirects and alternative resource naming. This provides the ability for control planes to delegate resource authority and describe failover relationships for federation use cases.
• A file and HTTP native transport for xDS resources.

The next steps for this are to circulate these documents for further feedback here on GitHub and the Envoy community meeting. Following this, we will begin work on the implementation roadmap.

This issue will track procedural and implementation work; please use the design docs for discussion of specific points of the proposal.

CC @envoyproxy/api-shepherds @mattklein123 @costinm @louiscryan @markdroth