Change:
THe addition to the first paragraph here seems necessary. The basic idea is that if a QUIC version violates the (reasonable) assumptions this section makes, then it just doesn't work if you try to apply this design. You will need to update your load balancer and probably update the CID allocation/negotiation/configuration you are using. The second paragraph I'm less sure about. I think that the intent was to say that if you follow the advice here you still get a functioning system even if the load balancer gets it wrong. So I said that. I think that I agree, provided that the tenant (new term?) chooses a good connection ID for any new ones. So that's not just Section 3.1 you need to refer to, but the whole document.
So what I'm trying to say at the end of the second paragraph is this: 1) Say, for example you have a LB that routes the Client Inital by SNI 2) For other packets, it uses a QUIC-LB config with 8B CIDs. 3) A client Initial arrives to URL with an (unknown) QUIC version 4) This initial also has an 8B CID that accidentally happens to route to a URL tenant 5) Since the LB can't read the CHLO, it ends up using the CID to route and things fail. Maybe you got all that from the text, but I'm making sure. This scenario isn't great but also isn't any worse than the pre-QUIC-LB status quo. shrug Still, your editorial change makes things clearer.

Discussion:
If these assumptions are not valid, this specification is likely to lead to loss of packets that contain unroutable DCIDs, and in extreme <del> cases connection failure. Some load balancers might inspect elements of the Server Name Indication (SNI) extension in the TLS Client Hello to make a routing 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- 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. </del> <ins> cases connection failure.  A QUIC version that violates the assumptions in this section therefore cannot be safely deployed with a load balancer that follows this specification.  An updated or alternative version of this specification might address these shortcomings for such a QUIC version. Some load balancers might inspect version-specific elements of packets to make a routing decision.  This might include the Server Name Indication (SNI) extension in the TLS Client Hello.  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-invariant.  Such a load balancer, when it receives packets from an unknown QUIC version, might misdirect initial packets to the wrong tenant.  While this can be inefficient, the design in this document 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> 8.