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

From: Kim Kinnear <[email-masked]>
Date: Mon, 26 Oct 2009 13:45:12 -0500

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

---

From: Bud Millwood <[email-masked]>
Date: Tue, 27 Oct 2009 12:26:30 +0100

On Monday 26 October 2009, Kim Kinnear wrote:

Comments inline

> 	simply by more closely specifying the values that it may

Hmm, both arguments seem reasonable.

But I have to wonder, is this now our standard operating procedure for DHCPv4, 
to always overload options just because it's technically feasible?

On a side note, why is it difficult to expand the DHCPv4 option space? 
Subencoded options are in their own number space. UTF-8 encoding was created 
as a superset of ASCII. It seems possible.

> 	below), then you need the absolute time in the context of

I have no problem with absolute times.

> 	there is general utility to being able to do this.

Please do not push this towards vendor independent options. I think time 
ranges are a great idea.

I generally find that any state not explicitly recorded can be easily 
calculated on demand.

> 	otherwise it might well be possible, but I suppose that's

I vote for the interoperability approach.

"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."

Our server also does this, and I suspect that any server that used the 
draft-dhc-failover document as a starting point does this.

Not that we should necessarily consider draft-dhc-failover when making these 
decisions, but there are at least two independent DHCP server implementations 
that provide redundancy by allowing cooperating servers to periodically be 
out of sync.

> 	but we can certainly take it out.

We support grace periods, but I fail to see how this information of use to a 
relay agent. Is there something the relay could use this information for that 
would result in some increase in effectiveness or efficiency?

- Bud

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

-- 
Bud Millwood
Weird Solutions, Inc.
http://www.weird-solutions.com
tel: +46 8 758 3700
fax: +46 8 758 3687

---

From: Kim Kinnear <[email-masked]>
Date: Fri, 30 Oct 2009 15:23:16 -0400

Bud,

Thanks for your comments.  I've removed the things on which we
agree (and I certainly appreciate those comments too).

My comments on your comments on my comments (whew!) are preceded
by Kim:

>to always overload options just because it's technically feasible?

        Kim: No, of course not.  Just when it seems to make some
        sense. 

        I think it is worth looking at the specifics of what is
        being proposed first, and considering metaphors of
        uncertainly congruity second (or even later) when
        examining questions such as this.

        My test is: does what is proposed make you slightly (or
        severely) ill?  If so, let's not do it.

        Personally I find this a bit unusual but overall quite
        reasonable.

        Were I look for a metaphor for this particular proposal,
        I would say that we were more or less sub-classing the
        message option for use in a specific and limited context.

        One nice feature of this is that all extant packet
        sniffers should need no changes to process this (though
        that wasn't why we thought it up).  They'll need
        plenty of changes to process TCP based DHCP traffic,
        I expect, so this isn't a big sales approach.

        But if you (or you all) can't stand this on its own
        merits, we'll change it to use a new option and be
        done with it.

>On a side note, why is it difficult to expand the DHCPv4 option space? 

        I'm must be misunderstanding something here.  There is a
        256 byte type code, and while we tried to make it bigger
        years ago, that effort languished.

>Subencoded options are in their own number space.

        For sure, but we aren't in a sub-option situation here.

        But I think I've lost the train of your thought.  Maybe
        you could help me understand what you mean here?

        Thanks again for your comments, truly!

        Kim

> UTF-8 encoding was created