Can you comment on examples of this will be used; e.g. what would Envoy put in this? What is the key space for the metadata?

Ideally this would contain the same information that we populate in LbEndpoint.metadata.

Thinking of this as a custom response to the Load Balancer for the Endpoint. e.g. if Load Balancer is using some sort of 'affinity', it would pass down it down to envoy via LbEndpoint.metadata. And should be copied back in the report to the balancer, for some correlation from Assignment to Load Report at the balancer.

That said, I agree that this is not an exact definition of how this field will be populated.
I will remove it.

I think that Endpoint has a lot of information beyond just the endpoint identifier these days, even though it started of as a simple identifier. I think core.Address is the only actual identifier in there. Should we use that instead?

Yes, core.Address is enough. Will change

Where did we end up with on the "let's eventually deprecate cluster granularity stats and have the management server aggregate the endpoint stats"?

I just caught up on this, ignore this comment.

I thought we did not want to disable a scenario where Server (Balancer) might not need per endpoint granurality information. In which case we can avoid sending all the Endpoint information to the Server.

To make this work I have added the following in LoadStatsResponse below

bool report_endpoint_granularity = 3;

FWIW I think it makes sense to make this be configurable. If users don't want all the extra data there seems no reason to spend resources serializing it.

Nit *true* to match Envoy docs style.

done

s/if Server/if the server

Done