Re: [dhcwg] AD review of draft-ietf-dhc-dhcpv6-load-balancing

[Ted Lemon <[e-mail]>]

On Dec 17, 2014, at 5:18 PM, Bernie Volz (volz) <[e-mail]> wrote:
> See section 3.1 - a REBIND does not contain a Server ID option so the server that is supposed to respond to this client's hash bucket is the only that responds.

Right, but that behavior is incorrect.   If a client is sending REBINDs, it might be because the server it's bound to is refusing to answer due to load balancing.  But it also might also be because it's bound to the correct server, and that other server is no longer reachable by the client.   In that case, the client will fail to renew its lease, because the backup server won't answer.   Not only that, but in this case the client would simply fail to get a lease until the problem with the unreachable server is corrected.

Of course, Delayed Service is supposed to take care of that, but if Delayed Service is configured, then presumably the server that is refusing service under 3.2 will allow service once the Delayed Service interval has elapsed.   And so the whole thing will have been for naught.

> Also, at least in a failover situation, even if all clients were serviced by only one of the servers (say they all obtained their lease when only one of the servers was running and are happily renewing their leases), what's the harm? Failover doesn't mean you have twice the throughput - since you must have proper server capacity to handle all of the clients from a single server (the partner server may be down for an extended period). And, eventually clients will SOLICIT and then move to the proper server.

Right.

> Is there more than what followed (Section 2 & 3.2) that needs to be "specified"?

Well, it's pretty clear that the logic of doing load balancing on non-solicit messages hasn't been explored in any depth... :)

> Did you have any suggestion for how to deal with this? It was I believe intended to indicate that DHCPREQUEST in v4 could mean multiple things. Note that this is addressing the requirements, not the operation (though it is interesting that this section in 3074 doesn't mention DHCPREQUEST). Perhaps this can just be: "The requirements for DHCPv6 are substantially the same as for DHCPv4."?

Only do load balancing on solicits.   The problem isn't actually in this document; it's that this document relies on 3074, which is underspecified.   So this document needs to correct for that.