Subject: Re: [dhcwg] Comments on draft-ietf-dhc-dhcpv6-load-balancing-00

From: Tomek Mrugalski <[email-masked]>
Date: Mon, 01 Jul 2013 22:55:24 +0200

On 13.06.2013 20:36, Andre Kostur wrote:
> Some general clarification questions (inline):
I'm very sorry it took me so long to get back to this thread.

>     The text mentions a case of 2 servers, with the first one going offline
>     and the second server taking over all clients. The text says that once
>     the first server recovers and the second server ignores RENEWs,
>     eventually the first server will be able to respond clients that start
>     REBINDing. This will cause the clients to constantly go through
>     REQUEST->failed RENEW attempts->REBIND cycles, even when both servers
>     are fine. Nothing really gained, but you just introduced REBINDs to
>     perfectly healthy network (with the extra processing needed for REBINDs
>     and possible warnings all around, as REBIND is usually a sign of
>     troubles).
> This shouldn't result in a constant cycle, only one cycle (where
> "primary client" == a client which should be answered by the primary
> server in a LB+Failover pair, and "secondary client" == a client which
> should be answered by the secondary server in a LB+Failover pair):
> 1) All servers are healthy
> 2) Primary server fails
> 3) A set of clients come online.  (mix of primary and secondary
> clients).  The Secondary clients are perfectly happy as the secondary
> server is still online.  The primary clients get serviced by the
> secondary server as well, as the secondary server knows that the primary
> is offline.
How can a server know that its partner is down? Is there some heuristic
to detect that? One thing comes to mind is to observe increasing elapsed
time values, but you explicitly say that Delayed Service Parameter
SHOULD NOT be used.

Also, keep in mind that the load balancing with its HBA mechanism allows
(at least in theory) more than two servers to cooperate, so the answer
may be more complex than just either "everyone's healthy" and "i'm the
only server left on-line".

In fact, I'd like to ask for further clarification on step 3). What do
you mean by "come online" - start new SARR exchanges after power up or
"reach T1 timer and start renewing"?

Here are my questions in case by "come online" you meant "start new
SARR". Steps 1) and 2) are as you described. Primary client sends a
SOLICIT that is received by secondary server. Should it respond or not?
That is not described in your I-D. I tried to look for DISCOVER in
RFC3074, but it doesn't seem to be described either.
Section 3.1 describes what to do with messages which contain server-id,
but there is no text that explains what to do with messages that doesn't
have server-id. I assume it should follow RFC3315, i.e. respond as
usual? Since that's the only server responding, primary client will pick
it up and send REQUEST with secondary server-id. Here are 2 choices:

a) secondary choses to respond to REQUEST. Address will be assigned. If
the secondary server choses to answer RENEW, there won't be any cycles,
but primary client will stay with secondary. If secondary server choses
to not respond RENEWs, primary client will go to REBIND mode. This will
be repeated over and over again, until primary server is restored.

b) secondary choses to not respond to REQUEST. The primary client goes
into infinite SOLCIT->ADVERTISE->REQUEST->retransmits->SOLICIT loops
until primary server is restored.

Note that I'm talking about situation before primary server is restored.

> 4) Primary server is restored
> 5) Secondary clients can Renew as the secondary server never went away
> 6) Primary clients Renewing against the secondary server get ignored
> 7) Primary clients transition to Rebind, where the primary server then
> answers them.  The clients then remember that the primary server
> answered and will do future Renews to the primary.
> 
> This is only one cycle of failed RENEW -> REBIND.
This assumes that the load balancing server behaves differently
depending on whether the partner is healthy or down, right? That's
against what is stated in the abstract ("without exchanging any
information beyond initial configuration") or there is some explanatory
text is missing.

In my opinion, the different behavior depending on whether the other
servers are healthy or not, require a state machine definition, with
clear transition rules. That's suddenly becoming much more complex than
a simple load balancing.

This finally brings me to another question: can this load balancing work
on its own, without failover?

>     Security considerations section is nice, but not sufficient. You also
>     mention that by misconfiguring HBA, administrators can fail to service
>     certain group of users and finding a pattern in such a group would be
>     difficult. As a practical aspect, debugging off-by-1 issues would be
>     tricky e.g. first server handles 1-127 and the second handles 128-255
>     (who is serving bucket 0?). Some warning about it - that the sum of all
>     Hash Bucket Assignments of all servers must cover the whole range -
>     would be useful.
> Are these security considerations, or just potential configuration errors?
Ok, fair point. Perhaps they could be moved to a separate section called
Deployment Considerations or Operational Considerations? However, if you
insist that these warnings are not needed, I won't object.

Any comments on the load balancing on relays? I think the easiest way to
resolve my concerns would be to simply remove the reference to relays
from abstract and do everthing on server side.

Additional comment: abstract mentions that the mechanism work "without
exchanging any information beyond initial configuration". Can you
elaborate on the initial configuration exchange? That's odd and I
haven't found anything about in in the text. I think that's a simple
copy and paste error from RFC3074 (which is also making the same
mistake, but that's a different story).

Tomek