Subject: Re: [dhcwg] Re: One more question

From: Ted Lemon <[email-masked]>
Date: Fri, 28 Oct 2005 14:46:28 -0700

On Sunday 30 October 2005 07:51, Bernie Volz (volz) wrote:
> But what if you need to reconfigure the network while one of the
> partners is down. You wouldn't be able to reconfigure any client that
> gots its configuration from the partner that is down (until the client
> transitioned into REBIND state).

It seems to me that the solution to this problem is to have Reconfigure throw 
the client into the REBIND state rather than the RENEW state.   I'm not sure 
what purpose it serves to throw the client into the RENEW state.

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

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Sun, 30 Oct 2005 09:51:02 -0500

Ted:

The protocol works just fine. Just like in DHCPv4, the partner server
won't respond to RENEWs but will to REBINDs.

Reconfigure has authentication and it is presumed that the failover
partners would communicate that authentication information. Therefore,
what's the harm in having the client respond to the server that sent the
Reconfigure (in most cases it will be the same server, but in some it
may not be).

There are other alternatives for failover - such as having a "failover"
server identifier instead of using the server's DUID.

I just think we'd be boxing ourselves in by forcing the client to
communicate with the original server; especially since we have
authentication and thus the client should be able to "trust" the server
that sent it the Reconfigure.

- Bernie 

> -----Original Message-----
> From: Ted Lemon [mailto:[email-masked]] 
> Sent: Friday, October 28, 2005 5:16 PM
> To: [email-masked]
> Cc: Bernie Volz (volz); Shengyou Zeng (szeng); D. R. Evans; 
> Ralph Droms (rdroms)
> Subject: Re: [dhcwg] Re: One more question
> 
> On Saturday 29 October 2005 19:00, Bernie Volz (volz) wrote:
> > Think about a failover environment and the failover partner 
> that gave
> > out the addresses is down ...
> 
> I don't see how that's relevant.   If the protocol doesn't 
> work with failover 
> in the absence of reconfigure, that's a problem that needs to 
> be solved.   
> You can't solve it by being more specific about how the 
> client behaves in the 
> presence of reconfigure.
>