Re: [dhcwg] RFC4388: Revision or new option needed?

[Niall O'Reilly <[e-mail]>]

On 03/06/10 13:00, Pavan Kurapati wrote:
> It may sound strange as to why an application running on DHCP server would
> need a leasequery mechanism to retrieve the lease data. Couldnt it retrieve
> just from the lease database?

	Not without reading the entire lease database from disk
	and parsing it all each time lease information is needed.
	Caching and high-watermark checking could mitigate this.

	The DHCP server already has this data in memory, and can
	return it 'instantly'.

> Are you going to suggest removing the constraint of adding 'giaddr' in
> leasequery message (Thus indicating there was no relay agent in between)? If
> so, the same condition applies when L2RAs are used and is mentioned in
> draft-ietf-dhc-l2ra-extensions which also covers leasequery.

	Thanks for that pointer.

	From a quick look, this mode (broadcast, source 0.0.0.0,
	destination 255.255.255.255) doesn't seem to be useful
	for my case.  I may need to read it again, more carefully.
	I need unicast, and possibly a number of routing hops
	greater than zero.

	I wasn't thinking of removing the constraint on how 'giaddr'
	is used in the query.

	What I had in mind was that, in sending its response to a
	DHCPLEASEQUERY request, the server should be required to be
	able to respect the UDP encapsulation, whether as standard
	behaviour, under control of a configuration option, or
	triggered by signalling using a new DHCP option (perhaps
	named 'lq-strict-layering').


	Best regards,
	Niall O'Reilly