Draft: draft-ietf-quic-load-balancers

Commentary: Here are some suggestions from my first pass , but overall I think the static vs dynamic server ID allocation idea works nicely . 2 Q 's : Is the definition of non - compliant different at LB and server in some cases ? Might non - routable be a better term than non - compliant ? 
 Yes , they can be different because the perception of the configuration is different . In general , during configuration updates the LB will have a configs that some servers do n't . Therefore , a DCID with those CR bits will be compliant at the LB and non - compliant at the server . With static allocation , servers do n't do anything with non - compliant DCIDs , so this is irrelevant . With dynamic allocation , it means that the LB will allocate an SID that the server does n't know anything about , until : 1 ) the allocation times out 2 ) the LB has the occasion to forward another packet with that SID to the server when the server has the configuration . I do n't feel strongly about this , but it works for me . If you want to file a PR with this change I 'd approve it . 
 In PR I suggested non - routable , though I realize non - conformant may also be an option . The sentence which caused me to suggest non - routable is : I 'm happy to write a PR if others find non - compliant potentially confusing as well . 
 I like it . Let 's go with it .
Load balancers SHOULD drop packets with non-compliant DCIDs in a
short header.
Load balancers SHOULD drop short header packets with non-compliant
DCIDs.
An arbitrary algorithmr MUST NOT make the routing behavior dependent
on any bits in the first octet of the QUIC packet header, except the
first bit, which indicates a long header.  All other bits are QUIC
version-dependent and intermediaries should not base their design on
version-specific templates.
An arbitrary algorithm MUST NOT make the routing behavior dependent
on any bits in the first octet of the QUIC packet header, except the
first bit, which indicates a long header.  All other bits are QUIC
version-dependent and intermediaries SHOULD NOT base their design on
version-specific templates.
A dynamically allocated configuration does not include any bespoke
assignment, reducing configuration complexity.  However, it places
limits on the maximum server ID length and requires more state at the
load balancer.  In certain edge cases, it can force parts of the
system to fail over to 5-tuple routing for a short time.
A dynamically allocated configuration does not have a pre-defined
assignment, reducing configuration complexity.  However, it places
limits on the maximum server ID length and requires more state at the
load balancer.  In certain edge cases, it can force parts of the
system to fail over to 5-tuple routing for a short time.
In the manual allocation method, the configuration agent assigns at
least one server ID to each server.
In the static allocation method, the configuration agent assigns at
least one server ID to each server.
In the dynamic allocation method, the load balancer assigns server
IDs dynamically so that configuration does not require bespoke server
ID assignment.  This also reduces linkability.  However, it requires
state at the load balancer that roughly scales with the number of
connections, until the server ID codespace is exhausted.
In the dynamic allocation method, the load balancer assigns server
IDs dynamically so that configuration does not require fixed server
ID assignment.  This reduces linkability.  However, it requires state
at the load balancer that roughly scales with the number of
connections, until the server ID codespace is exhausted.