Changes to support xDS Federation

[arvindbr8]

Per A47 xDS Federation design proposal two new fields are added to the gRPC xDS bootstrap config format, authorities and client_default_listener_resource_name_template.

Here are the new formats

• authorities

// A map of authority name to corresponding configuration.
//
// This is used in the following cases:
// - A gRPC client channel is created using an "xds:" URI that includes
//   an authority.
// - A gRPC client channel is created using an "xds:" URI with no
//   authority, but the "client_default_listener_resource_name_template"
//   field turns it into an "xdstp:" URI.
// - A gRPC server is created and the
//   "server_listener_resource_name_template" field is an "xdstp:" URI.
//
// In any of those cases, it is an error if the specified authority is
// not present in this map.
"authorities": {
  // Entries are keyed by authority name.
  // Note: If a new-style resource name has no authority, we will use
  // the empty string here as the key.
  "<authority_name>": {
    // A template for the name of the Listener resource to subscribe
    // to for a gRPC client channel.  Used only when the channel is
    // created using an "xds:" URI with this authority name.
    //
    // The token "%s", if present in this string, will be replaced
    // with percent-encoded service authority (i.e., the path part of the
    // target URI used to create the gRPC channel).  The replacement string
    // must include only characters allowed in a URI path as per RFC-3986
    // section 3.3 (which includes '/'), and all other characters must be
    // percent-encoded.
    //
    // Must start with "xdstp://<authority_name>/".  If it does not,
    // that is considered a bootstrap file parsing error.
    //
    // If not present in the bootstrap file, defaults to
    // "xdstp://<authority_name>/envoy.config.listener.v3.Listener/%s".
    "client_listener_resource_name_template": <string>,

    // Ordered list of xDS servers to contact for this authority.
    // Format is exactly the same as the top level "xds_servers" field.
    //
    // If the same server is listed in multiple authorities, the
    // entries will be de-duped (i.e., resources for both authorities
    // will be fetched on the same ADS stream).
    //
    // If not specified, the top-level server list is used.
    "xds_servers": [ ... ]
  }
}

• client_default_listener_resource_name_template

// A template for the name of the Listener resource to subscribe to
// for a gRPC client channel.  Used only when the channel is created
// with an "xds:" URI with no authority.
//
// If starts with "xdstp:", will be interpreted as a new-style name,
// in which case the authority of the URI will be used to select the
// relevant configuration in the "authorities" map.
//
// The token "%s", if present in this string, will be replaced with
// the service authority (i.e., the path part of the target URI
// used to create the gRPC channel).  If the template starts with
// "xdstp:", the replaced string will be percent-encoded.  In that case,
// the replacement string must include only characters allowed in a URI path
// as per RFC-3986 section 3.3 (which includes '/'), and all other characters
// must be percent-encoded.
//
// Defaults to "%s".
"client_default_listener_resource_name_template": <string>,

The bootstrap generator needs to be updated to this spec

[arvindbr8]

authorities field now also contains xds_servers. In the command-line arg, we accept xds-server-uri flag for the top level xds_servers.server_uri field.

According to the spec, we either or both fields can empty. Is there a specific way we want this to be handled for the bootstrap generator?

[arvindbr8]

@easwars
IIRC from our previous discussion. We want the user to be able to add an authority to the bootstrap file. But this authority maps to an empty {} so that it would default to the top-level xds_server_uri. Is this the expected behavior?

[easwars]

I think this is what we want:

• For the authorities field, we want two entries:

  • Empty string: This will be used for all new style resource names which contain no authority
  • "trafficdirector.googleapis.com:443": This is for new style resource names which explicitly specify TD
  • For both these entries, we will leave the value empty or {}. That way, they will still both end up talking to TD with the server config specified by the top-level

• Don't specify anything for client_default_listener_resource_name_template and server_listener_resource_name_template.

Doing the above changes protected by a flag named something like --include-federation-support will get the bootstrap generator output to work with TD.

Later on, we can decide if we want to add support for specifying non-default values for all of these fields.

What do you think? @ejona86

[ejona86]

@easwars comment sounds right. Later, once TD supports xdstp, we will add templates.

I expect we should also add the C2P authority. That could happen in a follow-up PR. See grpc/grpc#29732

[easwars]

I expect we should also add the C2P authority. That could happen in a follow-up PR. See grpc/grpc#29732

That's right. I missed that. Thanks @ejona86 .

[arvindbr8]

• Add federation support
• Add c2p changes