Re: [dhcwg] draft-ietf-dhc-server-override-03.txt returned to dhc WG for review (2nd call for review)

[Ted Lemon <[e-mail]>]

On Tuesday 14 March 2006 10:56, Kim Kinnear wrote:
> We certainly don't have the only server which NAK's renewals, and
> I thought that this was old news indeed -- about the state
> transition diagram allowing NAK's on renews.

It is.   The Nominum DHCP server and the ISC DHCP server can both NAK renewals 
as well, if the client is no longer allowed to have a particular IP address 
that it's trying to renew.   This is very old news indeed.

> Now, I've never discussed NAKing renews with anyone based on
> network attachment, and indeed, our server has code that is
> functionally similar that described by David -- we don't NAK a
> renew based on network connnectivity, only a rebind.  But that
> doesn't mean that in general we can't NAK a renew -- far from it.

Right, and in fact server override makes it more likely that things will 
function correctly: because we are now intercepting the DHCP client message 
at the relay agent and setting giaddr, the server can be *sure* whether the 
client's IP address is valid on the link to which it is connected.   With 
unicast renewals, we have no way of knowing, and indeed we have to guess.   
So server override actually takes us down a cleaner and safer code path - it 
makes things better, not worse.

> Issue #2: Load balancing generates multiple ACK's.
>
> This certainly is an issue, and does make load balancing largely
> uninteresting in a situation where you would use the
> server-id-override sub-option.  On the other hand, failover would
> still work -- you just don't get any effective load balancing.
>
> We've viewed this as the price you pay to talk to a DHCP client
> that you wouldn't otherwise be able to talk to, and given the
> circumstances, a small price to pay for that capability.
>
> It would be nice to be able to tell a unicast from a broadcast in
> the packet forwarded from the relay agent.  That would make load
> balancing work and would also allow a solution to #1 and #3.

Actually, there's another way to look at this: we have an opportunity to solve 
this problem now.   We could define a way to do load balancing at the relay 
agent (in a separate draft), and require that relay agents that implement 
server override also implement load balancing.   This might be a thing worth 
considering, since currently the load generated by forwarding renewals to 
both servers will be substantial.

> Issue #3:  Clients can get multiple ACK's to a renew, not just a
> rebind.
>
> At present a client can get multiple ACK's to rebind, but not a
> renew.  This would go away if issue #2 was solved somehow, since
> that is how this situation occurs.
>
> Given that client's expect multiple responses from a rebind,
> we've never seen issues with clients from multiple ack's from
> renews, for what that is worth.

Furthermore, if the servers are correctly configured, the renews should be 
interchangeable - the only difference will be which server gets picked, and 
this is immaterial because with server override, there will never be a case 
where load is directed to a particular server based on whether or not it was 
the server that renewed a particular lease.

> The question comes to -- how to have the relay agent tell the
> server the packet was unicast or broadcast.  The obvious answer
> is add information to the server-id-override sub-option, a flags
> byte perhaps.

I don't think this is necessary or worthwhile.   I don't see any upside in 
sending this flag, because, as you say, existing clients support DHCPNAK at 
DHCPRENEW.

>
> But there is a larger problem related to this one that deserves
> some discussion:
>
> One major issue with implementing advanced capabilities in the
> DHCP server is the lack of option-82 information in the unicast
> renew packets.  One solution to this is to never answer renews,
> but just answer rebinds, which works but is less than optimal.

I thought the whole point of server override was to make sure that every 
packet, renewal or not, went through the relay agent, and thus was elegible 
to have option 82 added to it.   Not so?

Anyway, from my perspective, I think that the right thing to do here is:

(1) allocate the suboption code now, so that implementation isn't held back by 
the roadblock I'm about to suggest (I don't *think* we are required not to 
allocate a suboption code prior to RFC).

(2) Write a new draft that describes how relay agents do load balancing.   
[[Short summary - they get the balance mask from the server somehow; they use 
it to decide where to forward _any_ DHCP packet; they check the value of the 
secs field and forward to all servers if secs is over some preconfigured 
limit.]]

(3) Require that conforming implementations of server override also implement 
the relay agent load balancing protocol.

I think that this would do it.   I think the DHCPNAK issue is a red herring.

_______________________________________________
dhcwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg