Re: [dhcwg] draft-ietf-dhc-l2ra-00 comments

On Wed, Apr 16, 2008 at 04:15:29PM +0530, Bharat Joshi wrote:
> > 4.2.2. Issues due to introduction of Layer 2 Relay Agent
> > 
> > o Suggest adding (in addition to similar 4.1.2 issues):
> > 
> >    Layer 2 relay agents which maintain persistent state, such as
> >    updating filters or client registration, must be prepared to handle
> >    potentially conflicting responses from different DHCP Servers.
> >    Some Layer 2 relay agents instead use "the most recent DHCP
> >    packet", and this is not necessarily a reflection of which state a
> >    client has actually adopted.  Even where a client requests a single
> >    address, and two servers ack the single address, they MAY differ
> >    for example in lease times.  If the relay agent selects the server
> >    reply which has a shorter lease time, it would expire its state
> >    possibly before the client even has a chance to renew it.
> >    Therefore, Layer 2 relay agents SHOULD select the longest lease
> >    time of two conflicting but similar replies, by discarding replies
> >    that shorten the lease time.
> > 
> > Or possibly this should be an expanded discussion of 4.2.1's point?
> 
> 
> Ok. This point seems to require some discussion.
> 
> We feel that when client receives multiple OFFER messages, it will
> choose only one of the server and will send REQUEST message identifying
> that server. Now Layer 2 Relay Agent should typically extract/glean
> Lease Information to install filters etc when it sees an Ack from the
> Server.
> 
> So my question is that we won't have a case where two servers are acking
> for the same request. I am not sure if I am missing something here.

Actually there are multiple scenarios, as DHCPREQUEST is used not just
in the transition from selecting->bound, but also in renewal and
rebinding.  You noted this in a later email. :)

More importantly, where a server-id is present, it does not imply only
one server will reply, as there may be a failover configuration
present (and some DHCP servers ignore the server-id sent by clients
anyway for various reasons).  So it is simplest just to say that any
DHCPREQUEST MAY net multiple DHCPACKs (and NAKs!).

Especially in a failover configuration, two servers may be prepared to
answer requests for a given IPv4 address being requested, and some
will do so regardless of server-identifier (or at least will be wiling
to answer for each other, or may use the same "anycast"
server-identifier, or ... any number of things).

The consequence is precisely two DHCPACKs, under failover, presuming
that the lease being requested is in the ACTIVE state already, or has
been reserved for the client.

-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		you'll just have to do it again."
Internet Systems Consortium, Inc.	-- Jack T. Hankins