Change:
Upon further consideration, any TP to provide CIDs for future connections should be in a different document.
LBs that are doing SNI routing are a special case. (1) If the Initial CID is routable, they can't just take that as good; they have to assume that it was random and inspect the SNI to make a decision. Section 4.1 doesn't allow this, and it should. (2) that mode doesn't work for unknown QUIC versions, obviously. (3) For QUIC versions the SNI-LB doesn't understand, I think this is the best we can do: a) For QUIC versions it understands, the LB MAY find the SNI. It MAY use the SNI for unroutable CIDs. If a routable CID, it may override the encoded SID if that SID does not correspond to the provided SNI. b) The QUIC-LB config explicitly states that the LB is doing SNI routing and the versions it supports c) The server MAY send a TP that means "next time you connect with me, please use one of the connection IDs I provided in a NEWCONNECTIONID frame." This may also be useful for some persistence use cases. The worst case is an unsupported version with a randomly generated CID. In this case, the LB will spray it and will only get lucky if it happens to get to the right tenant. Sec 11.4 may also need a revision here. Or maybe SNI routing is just incompatible with version-independent QUIC-LB?
The down side of just saying "don't do that' is that then SNI Load balancing can't work with version aliasing, which would be sad because VA helps hide the SNI.
Maybe specify a unique quic transport param is a better choice? For a web service, all requests just have same SNI, help nothing for distinguishing the Initial CID
Further more, there is a draft about encrypted client hello(URL)if it becomes RFC, maybe LB cannot get information about clientHello or there must be some ways to synchronize the server private-key to LB
synchronizing the server private-key is exactly what happens; that is what the "client-facing server" is in that draft.
I'm not sure what you're proposing here. My hope is not introduce a regression relative to current capabilities, but it sounds like you're talking about an L7 load balancer that's doing deep packet inspection. If so, that's out of scope for this document.
OK, I got it

Discussion:
All other DCIDs are routable. Load balancers MUST forward packets with routable DCIDs to a server <del> in accordance with the chosen routing algorithm. </del> <ins> in accordance with the chosen routing algorithm.  Exception: if the load balancer can parse the QUIC packet and makes a routing decision depending on the contents (e.g., the SNI in a TLS client hello), it MAY route in accordance with this instead.  However, load balancers MUST always route long header packets it cannot parse in accordance with the DCID (see version-invariance). </ins> Load balancers SHOULD drop short header packets with unroutable DCIDs.

decision.  Note that the format and cryptographic protection of this information may change in future versions or extensions of TLS or QUIC, and therefore this functionality is inherently not version- <del> invariant. </del> <ins> invariant.  See also unroutable for other considerations about this case.  Note that an SNI-aware load balancer, faced with an unknown QUIC version, might misdirect initial packets to the wrong tenant. While inefficient, this preserves the ability for tenants to deploy new versions provided they have an out-of-band means of providing a connection ID for the client to use. </ins> 11.