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

[Ted Lemon <[e-mail]>]

This document is not ready for publication as a proposed standard.   The main problem is that it's woefully underspecified, because RFC 3074 was woefully underspecified, and so it gets some key points wrong.

In section 3.2, the text appears to be saying that in a DHCPv6 failover setup, a RENEW with a server identifier should be ignored if the load balancing algorithm doesn't identify the client as belonging to that server.   This is problematic, for two reasons.   First, it leads to the client attempting to renew multiple times, resulting in an increased load on the server.   Second, a REBIND would presumably be answered by both servers, so it wouldn't necessarily correct the problem.

But this leads to the reason I think this is not ready for publication: RFC 3074 never actually specifies under what circumstances load balancing is done: it leaves it up to the implementation.   It kind of implies that load balancing should be done on all requests.   But in fact it only ever mentions DHCPDISCOVER.   And indeed, I just looked at the ISC implementation, and it only does load balancing on DHCPDISCOVER.

Section 2 of this document suggests that load balancing is done for _all_ client-sourced messages, but that would mean that a REBIND message wouldn't get a response from the non-balancing server, which in turn would mean that the client's lease would have to expire before it could rebind to the correct server.

There are a couple of ways this could be addressed.   One way would be to just take out section 3.2.  Another would be to say in section 3.2 that if the server identifier doesn't match the recipient's server identifier, but the load balancing algorithm says that the server should answer for this client, and the server can answer, it should answer, and leave the rest of the text the same.   Of course, there's no way to be sure the _client_ will do the right thing with such a response.

Do we have any data about operational problems in this scenario with DHCPv4?

Anyway, this needs to be resolved before I can last-call the document.   Sorry for not catching this in previous reviews.