Not specific to gRPC: Should we also add this "optional" functionality to upstream filters in cluster? Then if one day Envoy decided to implement this feature, they will have all proto changes needed.

In general, I think it would be useful to do this for all types of filters (also including L4 filters and listener filters). But right now, we are primarily concerned about HTTP filters, so let's focus this PR on that functionality.

Is this wrapper needed? Setting is_optional=true ought to disable parsing of config for filters that are optional and not build into the binary. It should be possible to ignore this config without wrapping it in an extra layer of messages.

The problem is that at the time that we receive the RouteConfiguration from RDS, we don't necessarily know which HCM config it's going to be matched up with, because there could be a new LDS response waiting to be swapped in, so we can't depend on the is_optional=true that was set there. See my comment in #12274 for details.

Yeah, I think this is unavoidable given the nature of xDS resource independence.

What does the rest of the implementation look like? Is there a natural place to ignore the config for optional filters that are not built into the binary?

@htuch said this probably wouldn't be hard to implement.

I'm guessing that we'll do it when validating the LDS response. Presumably, that's the point at which we're checking that we have a filter registered for the type of the config in the typed_config field, and we'll NACK the config if we don't have one. The purpose of the is_optional field is to have that check ignore the filter instead of NACKing the config.

A downside of this wrapper is that it adds exactly one feature, and leaves no room for future expansion. If we need another feature in the future, we'll need two levels of wrapping. (Actually, we already do have another level of wrapping in the TypedStruct feature.)

Instead of this limited-purpose wrapper, maybe we should have one that holds all future expandability instead?

message FilterConfig {
  oneof config_type {
    proto.Any typed_config = 1;  // Would never contain a TypedStruct
    udpa.type.v1.TypedStruct struct_config = 2;
    config.core.v3.ExtensionConfigSource config_discovery = 3; // ? (from HttpFilter)
  }
  bool optional = 4;
  // room for future expansion
}

Also, optionally & more invasively, we could update HttpFilter to deprecate config_type and reference this new FilterConfig message to unify things further.

I like the idea of making this more general-purpose so that we can add additional per-filter options later! Done.

I didn't include the TypedStruct field, because I think the established way of dealing with TypedStruct in xDS is to embed it inside of an Any field, since that makes the JSON representation more natural.

I also didn't include the ExtensionConfigSource field, since I don't see any existing option for using ECDS here in the typed_per_filter_config fields. I suspect the two are mutually exclusive, but @htuch can confirm.