[dhcwg] lease query question

[Thomas Narten <[e-mail]>]

I've started my AD review on draft-ietf-dhc-leasequery-04.txt, and
have a basic question. From the problem statement, I understood the
problem to be fairly narrowly scoped, that is, an ability to rebuild
the state that an access concentrator builds from gleaned DHC
messages, but loses if it (say) restarts.  The abstract/problem
statement says:

   Access concentrators that act as DHCP relay agents need to determine
   the endpoint locations of IP addresses across public broadband access
   networks such as cable, DSL, and wireless networks.  Because ARP
   broadcasts are undesirable in public networks, many access
   concentrator implementations "glean" location information from DHCP
   messages forwarded by its relay agent function.  Unfortunately, the
   typical access concentrator loses its gleaned information when the
   access concentrator is rebooted or is replaced.  This memo proposes
   that when gleaned DHCP information is not available, the access
   concentrator/relay agent obtains the location information directly
   from the DHCP server(s) using a new, lightweight DHCPLEASEQUERY
   message.

That is, I assumed that what is needed is a mechanism that allows a
concentrator to avoid the need to invoke ARP, by querying the DHC
server instead.  To achieve this, I would have assumed that a simple
query-response protocol that would solve the problem as stated. That
is, I would have assumed perhaps two queries:

 - tell me the IP addresses of all devices behind a particular
   link-layer "MAC", or [note: one might use this to rebuild state
   about a particular link]
   
 - Tell me which of my links (if any) the following IP address resides
   on. [note: one might use this if one received an packet to forward,
   and needed to do the equivalent of "ARP" for it]

I would expect that the leasequery might say "give me the info", and
the server would respond with the same info it would give the
client. I.e, the information received is the same as that it would
glean from the normal DHC trafic (and in particular, without any new
information specific to the leasequery protocol).

But the protocol is quite a bit more complex than that. For example, a
server can respond with a "sort of" answer, one that indicates I don't
have a lease, but I did in the past. Likewise, there is also an R bit
for providing further information about the details of a particular
lease.

I don't fully understand the motivation or need for the additional
stuff. There seem to be some unstated assumptions about the nature of
the problem being solved. Could someone please clarify what the actual
problem is that needs solving here?

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