[dhcwg] draft-ietf-dhc-dhcpv4-bulk-leasequery-01.txt

[Kim Kinnear <kkinnear at cisco.com>]

I've submitted a new version of the DHCPv4 Bulk Leasequery
draft today.  

http://www.ietf.org/id/draft-ietf-dhc-dhcpv4-bulk-leasequery-01.txt

The substantive changes were based on comments some time ago by
Ted Lemon and David Miles.  Below I reproduce those comments
which we did *not* address in the updated draft, and comment on
why we did not make the requested change.

Many thanks for both Ted and David for their insightful comments.
It is always hard to get people to contribute to something
as detailed as this draft, and we really appreciate the work
that they both put in.

Again, if the comment is not listed below, I made the change
requested.  If you wish to see the original comments, you can
see the following two links:

 http://www.ietf.org/mail-archive/web/dhcwg/current/msg09977.html
 http://www.ietf.org/mail-archive/web/dhcwg/current/msg09979.html

Discussion regarding changes *not* made:

David Miles:

>
>1) Is very DSLAM centric - suggest we need to generalize the use case to
>any relay agent. The background re fast/slow path in the Motivation
>section is unnecessary. Suggest Motivation can be boiled down to
>"extending the current individual Leasequery protocol [RFC 4388] to
>support a bulk query".
	
	Well, actually, I did take out the entire section on
	Motivation as well as the Appendix (per Ted's request).
	But recognize that this is a contentious area -- some
	people always complain that we didn't motivate the draft
	properly and "what do we need it for anyway".  I'm dealing
	with that right now with the IESG on the vpn-option
	draft.  So there is no way to win on this one.

>3) Section 7.2.1 assigns new DHCP message type values - these should be
>TBA/IANA.
	
	I believe that someone told me to put these in this way,
	though I can't remember who, unfortunately.  I'll leave
	it up to the WG Chairs and/or Ralph to let me know how to
	handle this.  I certainly don't care one way or the other.

>4) Section 7.2.2 proposes dhcp-message formats that are somewhat
>confusing: it specifies constrained format 3 character ASCII field where
>the characters must be base10. As the table appears to be simple
>incrementing error codes I would suggest an simple 16-bit result code
>and associated table vs the left-, middle-, right-number format in
>7.2.2. I do not think we should overload option 56 for error messages as
>currently opt 56 is defined for text to display to end-client. I don't
>see any harm in creating a new DHCP option for lease-query to convey
>server-to-relay errors/results (ie, as done with the base-time and
>start-time-of-state messages).

	This is not a particularly big deal either, but I did not
	change to a new option for status codes and messages.

	I resisted this admonition largely because this
	particular use of option 56 is solely within the DHCPv4
	bulk leasequery interaction.  Without some definition of
	how to use option 56 in a bulk leasequery, it has
	essentially no meaning at all -- so I don't see the
	conflict with "option-56 is defined for text to display
	to [an] end-client".  This isn't a DHCP client <-> DHCP
	server interaction (in the sense of a DHCP client who
	want's an IP address).  This is an entirely orthogonal
	interaction concerning DHCP.

	Given that we are moderately short of options in the
	global DHCP option space (though less than we once were,
	of course), it seems wasteful to define a new option for
	use in bulk leasequery when we can use an existing option
	simply by more closely specifying the values that it may
	contain.

	But if this is a major impediment to moving the draft
	along we can certainly define a new option for bulk
	leasequery and use up another number.


>
>5) I dont think we should mix absolute and relative time scales in the
>same single message. As currently proposed base-time is an absolute time
>and all other time values are offsets from this base-time option. Is
>there a way we can avoid absolute times all together thus avoiding the
>need for time sync between relay and DHCP server? Given the leasequery
>returns things like lease (which are timers) could we not get away with
>returning the remaining lease time? I'm not sure I can appreciate value
>in the relay agent knowing what the original lease time was.
	
	There are two reasons to have one absolute time in the
	messages.  First, if you care about accuracy, having the
	absolute time in the message tells you the delay in
	sending, transmitting, receiving, and processing the
	message.  This will allow you to develop (if you wish) a
	much more accurate sense of the time skew between the two
	machines and, because of that, a much more accurate set
	of time values.

	Second, if you are going to support query times (see
	below), then you need the absolute time in the context of
	the DHCPv4 server.

>
>6) With section 7.2.5/7.2.6 I feel we are overcomplicating the query
>with time ranges. Why would a relay agent not want to recover all leases
>- further this requires a DHCP server to maintain an explicit
>last-modified time for every lease.
	
	The cost of sending information concerning all of the
	lease can be quite large.  It may be necessary to scan
	all of the IP addresses configured in the server in order
	to do any of the bulk leasequery operations -- and that
	can by itself be a load on the server.  Having to use 
	the network bandwidth to send it all back when it is
	unnecessary seems ...  unnecessary and possibly 
	prohibitively expensive.

	A relay agent may well have saved information to stable
	storage and be only interested in changes since a certain
	time.  Beaing able to ask for only what the relay agent
	wants can make the load on the DHCP server, the network,
	and the relay agent much much less than it would
	otherwise be.  In very little cost of complexity.

	We could certainly implement this as an add-on to bulk
	leasequery in vendor independent options, but I think that
	there is general utility to being able to do this.

	------------

	Regarding keeping the last modified time for a lease,
	RFC 4388 already defined the client-last-transaction-time.
	We are just using it again here.

>
>7) The states RELEASED, ABANDONED, RESET suggest the server keeps state
>of leases that have expired - I can see that this is a function of the
>time-based query - but it puts a huge burden on a DHCP server.

	I would think most servers would do this because it is
	part and parcel of how most vendors implement some form
	of increased availability.  But if you don't keep this
	information it doesn't invalidate that value of time
	oriented queries from the relay agent.

 See point
>6 wrt returning all valid leases. These time-bound queries could lead to
>out-of-sync problems between server and relay and as the motivation
>appears to be state recovery it seems pragmatic to return all state
>instead of a time-based subset. In reality how many relay-agents could
>even implement a time-bound query after a reload (ie, do they really
>know the second they were rebooted or lost power)?
	
	I agree, few relay agents have any clear idea of when they last
	were taken out of service or failed.  On the other hand, they	
	can easily keep track of the latest client-last-transaction-time
	of every bulk leasequery update and save that in stable storage.
	Thus, they know quite easily the most recent information held
	in stable storage and can ask for everything since then.

>
>8) This proposal requires a TCP connection between server and relay
>agent thus necessitating an IP address on the relay agent. This seems to
>be at odds with the objectives outlined in the L2 Relay and LDRA drafts.
>In these drafts relay-agent (often a DSLAM) does -not- require an IP
>address nor is it desirable. This proposal will require the DSLAM has an
>IP address that is routable to the DHCP server - also the draft says in
>section 5 that "No relaying of Bulk Leasequery messages is specified".
>This means a logical topology change in many ISP networks and is not
>aligned with the broadband architectures put forward by other
>organisations like Broadband Forum TR-101.
	
	Well, a UDP based approach to bulk leasequery was soundly
	defeated for DHCPv6 more or less recently, and years ago
	we sounded folks out on a UDP based version of RFC 4388
	for bulk leasequery for DHCPv4 -- and it was a
	non-starter.

	There is some ongoing work on extending RFC 4388 to
	clients that have no IP address.

	But, since DHCPv6 Bulk Leasequery made it to RFC status
	using TCP we decided to move forward using that precedent
	for DHCPv4 Bulk Leasequery.  Despite your comments, I
	can't see that we have any reasonable alternative to TCP.

>

Ted Lemons Comments:


>In section 7.2.7, I don't really understand why the relay agent needs  
>to know more than that the lease is still active, or is no longer  
>active.   This seems to be an extension on the functionality provided  
>by DHCPLEASEQUERY, relating to failover, but (a) it seems unnecessary,  
>(b) I have no idea what the DSLAM would do with it, and (c) because of  
>that, it seems like it could result in interoperability problems as  
>different implementors make different guesses as to how to handle  
>it.   You could save a lot of text by just taking this out.   Same  
>with data-source.
>
>I can see where it might be helpful to use this for disambiguating in  
>cases where one server reports a lease as free and another reports it  
>as allocated, but it might be better to simply specify rules for when  
>a server should claim to have knowledge about a lease - if a  
>particular IP address is in its peer's pool, and is not known to have  
>been allocated, perhaps that IP address should simply not be mentioned  
>in a DHCPBULKLEASEQUERY reply.   It would be entirely permissible and  
>expected in some cases for that to happen.
>
	
	Yes, all of this stuff is about the increased
	availability solution where two servers are operating
	together to increase availability.

	There are three cases (at least) for each server:

	1.  The IP address is available for this server to
	allocate.

	2.  The IP address is available for the other server to
	allocate.

	3.  The IP address is leased out to a DHCP client.

	The expectation is that the relay agent will ask *both*
	servers for all of the information it is interested in,
	and then use the "best" response it gets for each IP
	address.

	You propose to have the two servers respond only for
	cases 1 and 3 and be silent on case 2.  While that might
	be possible (though it isn't what the draft says, nor is
	it what I think the draft should say), the real issue is
	with case #3.

	When both servers are up and they both respond to a bulk
	leasequery about a leased IP address and the information
	they both send agrees everything is fine.  And that is
	the normal case (or one hopes so, anyway).

	The sticky part is where they *don't* agree -- for
	various reasons sometimes the two DHCP servers providing
	high availability DHCP server don't agree for some period
	of time about the situation regards a particular IP
	address.  Then the receiver of the two bulk leasequeries
	needs to figure out which information to believe.  The
	information it has in its "database", or the information
	coming in over the wire from one of the servers.
	(Generally they won't both come in at the same instant).

	Our experience is that the state and data-source are
	critical to making effective judgements about which data
	is the "best", and therefore which to remember as the
	accurate information about a particular IP address.

	Since we are trying to standardize bulk leasequery, we
	thought that having this information available to make
	decisions would be valuable for everyone.  We certainly
	need it.

	We could send this information to our users of bulk
	leasequery using vendor identifying vendor specific
	options (as we are already planning to do with other,
	less generally interesting, information).  But since we
	believe in standards, we felt that having this
	information available to all in a documented and
	standardized format was critical to interoperability in
	an increased availability environment.

	But we can certainly take it out and then do it in a
	vendor specific way if you want.  Seems unfortunate, as
	it means that we won't really have interoperability when
	otherwise it might well be possible, but I suppose that's
	the way things go.

>
>Regarding section 8.6, as I've said previously in this commentary, I  
>think it would be better to specify the client behavior in such a way  
>that the conflicts proposed in this section simply do not happen.    
>This section is not specific enough to foster interoperability.
>
	See above.  We need to decide if we want interoperability	
	in an increased availability environment, or not.


>Also on page 34:
>
>The message type of DHCPLEASEACTIVE or DHCPLEASEUNASSIGNED is based on  
>the value of the dhcp-state option.  If the dhcp-state option value is  
>ACTIVE, then the message type is DHCPLEASEACTIVE, otherwise the  
>message type is DHCPLEASEUNASSIGNED.
>
>Once again I suggest you get rid of the dhcp-state message and simply  
>say what should happen here for IP addresses that are managed by  
>failover and those that are managed by a single server.
>
>Specifically, any IP address that is in the FREE state on the primary  
>is DHCPLEASEUNASSIGNED.   Any IP address that is in the BACKUP state  
>on the primary is not reported on at all.   Any IP address that is in  
>the FREE state on the secondary is not reported on at all.   Any IP  
>address that is in the BACKUP state on the secondary is  
>DHCPLEASEUNASSIGNED.   Likewise for all the other permutations; I  
>think that in any of the states where the failover peer would renew  
>the lease, it's active, and in states where it wouldn't renew the  
>lease, it's either unassigned, or shouldn't be mentioned.
>

	See above.


>Also, in point 4, you mention a grace period on the expired state, but  
>as far as I know no such thing exists.
>
	We discussed the optional possibility for this
	a long time ago.  Some servers support such a
	thing, and it seemed valuable to provide for it,
	but we can certainly take it out.

>Section 10:
>
>As I mentioned earlier, the only authorization model for this protocol  
>is based on the requestor's IP address, and there is no  
>authentication.   At a minimum this should be mentioned in the  
>security considerations section.
>
	There was a much better security section in RFC4388,
	which I transplanted here.  While it may not be everything
	you wanted, it is certainly better.

Thanks much to both of you for your input!

Regards -- Kim