Subject: [dhcwg] Comparison between DHCPv4 Bulk Leasequery drafts

From: Kim Kinnear <[email-masked]>
Date: Fri, 15 Aug 2008 16:29:56 -0400

Folks,

[While this is directly primarily at the authors of
draft-dtv-dhc-dhcpv4-bulk-leasequery-00.txt, I've copied the DHC
WG list as well in case anyone is interested in the rather lengthy
details.]

A week or so ago, I promised an analysis of the differences between
the two relatively new DHCPv4 Bulk Leasequery drafts:

http://tools.ietf.org/html/draft-kinnear-dhc-dhcpv4-bulk-leasequery-00

http://tools.ietf.org/html/draft-dtv-dhc-dhcpv4-bulk-leasequery-00

In addition, I promised proposals for how to bring these two drafts
together into one draft that meets the needs of both groups.  This email
contains both the analysis and the proposals for how to unify these two
drafts.

This rather long piece of email is the results of that effort.  Sorry
about the length.

If we can come to some level of agreement on these issues, I'll
volunteer to produce a combined draft that reflects our agreement
sometime in the first week or so of September.

Let me say that I am impressed by the draft-dtv-dhc-dhcpv4-
bulk-leasequery-00.txt draft.  It is well done and of better quality
than most -00 version drafts that I've read.  Nice job.

I've structured the comparison based on the importance of the proposals
from our point of view.  That is to say, the proposals we feel most
strongly about are first, and those less so, later.

I'll name the drafts the dtv-draft and the kinnear-draft in order to be
able to discuss them.

  1.  Query types:  The dtv-draft has two new query types: relay-id and
  remote-id, and the kinnear-draft has one new query type: time.

  Proposal: I believe that we should have one draft that supports all
  three new query types.

  2. Existing query types:  The dtv-draft supports existing DHCPv4
  RFC 4388 UDP leasequery types, and the kinnear-draft does not.

  Proposal: We strongly believe that we should *not* support the
  existing query types in a bulk leasequery.  We believe that supporting
  these query types in a bulk leasequery is a mistake for a variety of
  reasons:

    a) The dtv-draft spends considerable time showing how these queries
    are not sufficient (i.e., useful) for the problem at hand.
  
    b) These queries in general return a very small amount of data,
    certainly nothing that requires a bulk/TCP connection.

    c) In at least our implementation, the approach to processing a bulk
    leasequery is quite different from the approach to processing the
    RFC 4388 leasequery responses, and trying to unify them seems like a
    waste of time, effort, and complexity for both us as well as clients.

  Our Proposal:  If you want RFC 4388 queries, use RFC 4388 UDP
  leasequery.  If you want the three (combined) bulk leasequery
  approaches, use bulk leasequery.

  3.  Data returned:  The dtv-draft implies that there must be a query
  type for every bulk leasequery.  The kinnear-draft allows a bulk
  leasequery without any query-start-time or query-end-time.  This means
  that all DHCP lease state data will be returned in such a bulk
  leasequery.

  Proposal:  The ability to get *all* of the lease state database data
  (including information about IP address which do not now and may have
  never had any lease association with a DHCP client) is integral to the
  one of the requirements that prompted our creation of the
  kinnear-draft.

  We propose that a bulk leasequery with no query return all information
  in the lease state database.   If you don't want all that data, don't
  send in such a request.  This means that you can get DHCPLEASEACTIVE
  as a message in a response, or DHCPLEASEUNASSIGNED as a message in a
  response.

  4.  DHCPLEASEDATA message:  The dtv-draft has, in an echo of the
  DHCPv6 Bulk Leaesquery draft, the concept of a DHCPLEASEDATA message
  to "reduce redundant data when there are multiple bindings to be sent".
  The kinnear-draft has all messages containing data to be similar to
  the first client's data sent (which is similar to the RFC 4388 format
  for both dtv-draft and kinnear-draft).

  It seems that DHCPLEASEDATA is a synonym for DHCPLEASEACTIVE but
  without the server-id option.

  Proposal:  Given requirement for the kinnear-draft to get
  DHCPLEASEACTIVE as well as DHCPLEASEUNASSIGNED messages in response to
  some of our bulk leasequery requests, the DHCPLEASEDATA approach just
  doesn't work.  We could certainly design yet another message type that
  might, but the amount of common data in DHCPv4 leasequery responses is
  really quite minimal -- the server-id option.  In DHCPv6 Bulk
  Leasequery it made more sense, since multiple leases will often (even
  usually) be returned for one client.  But in DHCPv4 this is really
  quite rare enough to be considered uninteresting from a data
  duplication standpoint.  And the 6 bytes of server-id are really not a
  lot given the other overhead we've already bought into with the DHCPv4
  packet format.  So we believe that a combined draft should just not
  include the concept of a DHCPLEASEDATA message.  This also makes it a
  lot less complicated.

  If people *really* are up in arms about the server-id option in every
  message, we could just special case that and say that it only needs to
  be in the first message.

  5.  Multiple bulk leasequeries per connection:  The dtv-draft follows
  along the DHCPv6 draft in allowing multiple parallel bulk leasequeries
  per TCP connection.  The kinnear-draft does not, and has one
  connection per bulk leasequery at a time.  Though you could keep the
  connection open and do another bulk leasequery after the first one
  completes.

  Proposal: Make life simpler (since it isn't required anyway), and
  simply say that there can only be one outstanding bulk leasequery per
  TCP connection.  Then you don't have to explain how it works, and the
  complexity goes way down from the implementation standpoint.  

  Given that you've pretty much got to drop the connection in some
  errors in a bulk leasequery, no rational client is going to try to
  bundle multiple bulk leasequeries onto one TCP connection since the
  investment in a bulk leasequery is so great.  If one of them suffers
  an error, all of them get stopped and must be re-run from scratch.  If
  availability is important (and when is it not?) then you'd certainly
  not send in more than one bulk leasequery per connection.  So why
  bother to allow it and document it since it really isn't a good idea
  anyway?

  6.  DHCPLEASEQUERYFAIL:  The dtv-draft has some new message types for
  specific status values.  The kinnear-draft has a new message type for
  general status, with a status-code option for the details of that
  status.

  Proposal: Use the kinnear-draft approach for a single status message
  time, and encode the state in the status option.

  7.  dhcp-status-code option:  Both drafts have a status code option.
  The only difference is the length of the code.

  That said, in recent discussions involving how to phase this in, the
  kinnear-draft authors have had a change of heart.  In an attempt to
  use fewer new option values (since we are running out in DHCPv4), we
  would now suggest overloading the dhcp-message option (option 56)
  instead of creating a new status code option.  The approach would be
  to encode the status code in the first three acsii characters of the
  dhcp-message option (including leading zeros), followed by a space.
  For example, if NotAllowed was code 4, then:

	dhcp-message = "004 ciaddr was non-zero."

  might be a response to sending in a bulk leasequery with a non-zero
  ciaddr.

  This is a bit inelegant, but isn't too bad and doesn't use up an
  additional option when it isn't necessary.

  Ultimately, we'd like to see this in a combined draft.  Whether or not
  it will make it through the DHC WG process remains to be seen.

  8.  DHCPLEASEDONE:  The dtv-draft DHCPLEASEDONE and the kinnear-draft
  DHCPLEASEQUERYDONE messages are similar.  But the dtv-draft mimics the
  strange approach of the DHCPv6 Bulk Leasequery where you can't send it
  unless you've sent some amount of information.

  Proposal:  Every bulk leasequery that terminates (as opposed to loses
  its connection) shall be terminated by a DHCPLEASE[QUERY]DONE message.
  Period.  It should have a status (in a dhcp-message option) if there
  was anything but success for a status.

  This means that a combined draft doesn't have to have an entire
  section devoted to "completion criteria" (dtv-draft section 8.4).
  Plus, writing the client code is a lot easier.

  9.  TCP framing.  dtv-draft section 7.1, kinnear-draft section 5.1.
  The two unused bytes after the message-size are not there in the
  kinnear-draft.  Our original approach was identical to yours, and then
  it became clear that with TCP, things wouldn't be aligned anyway, so
  having the two bytes was essentially useless.

  Proposal:  Leave out the two unused bytes, and frame it with a 16 byte
  message-size.

  10.  Querying multiple servers: The dtv-draft has a section 8.5 which
  is short, while the kinnear-draft has section 6.5 about how to resolve
  conflicts (and section 6.4 which supports section 6.5 by discussing
  how to correct time values).

  Proposal: adopt the kinnear-draft text more or less as-is.  We feel
  that explaining how to do this is important, and we've learned a lot
  from failover about how important this is.

  11.  Additional information: The kinnear-draft defines several options
  that contain additional information not discussed in the dtv-draft and
  beyond what RFC 4388 returns.  Specifically: base-time,
  start-time-of-state, and dhcp-state.  Of course, base-time is really
  about point 10, above.

  Proposal:  Include these additional options in a combined draft.  But
  see below on whether or not they are "required".

  12.  Appendix explaining why bulk leasequery is required in the
  dtv-draft.

  Proposal:  We like this, though I'm not sure it belongs in the final
  RFC.  The WG chairs could help us out here, but the information is
  important, well said, and should be available for people that are
  reviewing the draft.  If it could be deleted as part of the RFC editor
  process, that might work.

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

Things not in either draft that have come up since we published our
draft:

  a) In kinnear-draft section 7.3 we required the additional options
  defined for more detailed data (see point 11 above) be returned.  They
  were stated as MUST be in the packet.  We now think this was a
  mistake, and all of these options should be controlled by the
  parameter request list.  If you ask for them with the
  dhcp-parameter-request-list (option 55), then you get them, if not,
  not.  Saves space if you don't want them.

  b) Also, if you ask for *other* options in the parameter request list,
  then what do you get back?  Specifically, if the option could have
  been sent in by the client and could also have been sent back by the
  server, which option do you want to get in a bulk leasequery?  For
  instance, the option 125 (vivso) question -- if you specify 125 in the
  dhcp-parameter-request-list, do you want the option-125 sent in by the
  DHCP client, or the option-125 sent back by the DHCP server.  If
  either exists?

  Our current thinking is that a bulk leasequery SHOULD return options
  sent in by the DHCP client in preference to options returned by the
  DHCP server if there is a chance that it could have been either.  But
  we're still thinking about this, and open to some level of suggestion.

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

That's it for now.

I'll volunteer to produce a combined draft with all of our names on it
based on the results of this discussion.

Regards -- Kim

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

---

From: Bharat Joshi <[email-masked]>
Date: Mon, 18 Aug 2008 16:48:41 +0530

Hi Kim,

> contains both the analysis and the proposals for how to unify these two

Thanks a lot for this detailed explanation. We think it is very well
written and cover most of the points. Please see our response in line
for each of the items.

This is becoming rather big so please bear with me.

> than most -00 version drafts that I've read.  Nice job.

Thanks.

>   Proposal: I believe that we should have one draft that supports all

Yes. We agree. We also want to point out couple of specific differences
between two drafts which we feel we should discuss.

We believe that the actual usage of bulk lease query defined in
dtv-draft and kinnear-draft is different. In 'dtv-draft', usage of bulk
lease query is focused on a lease query client [eg. Access Concentrator]
getting all the Active lease information assigned through a specific
relay Id/remote-id. Please note that this means, with this lease query,
lease query client gets lease information for only Active Leases. While
kinnear-draft defines a generic bulk lease query where a lease query
client can query the status of each IP address, a DHCP server is
configured to allocate.

Another small difference is that dtv-draft has proposed to use the
existing query message type 'DHCPLEASEQUERY' [defined by RFC 4388] while
'kinnear-draft' has proposed a new DHCP message type
'DHCPBULKLEASEQUERY'. Also 'dtv-draft' carry forward the ways and means
similar to RFC 4388 to differentiate between different queries.

We are curious to know:

* Where/when do we see a Lease Query Client to get status of all the IP
addresses configured in the DHCP server?

For query by time, we think that the method using start/end time in Bulk
lease query is useful only when a lease query client is storing its
lease information in a stable storage.

One question we have here is:

* Do we really see a lease query client [Eg. Access Concentrator/Relay
Agents] having stable storage and store the lease information in stable
storage periodically?

With the above information, we feel we need to discuss this area a
little more in detail.

>   approaches, use bulk leasequery.

Before adding RFC 4388 queries in dtv-draft, we had discussed this
between ourselves and realize that there is not much work involved in
supporting them. In fact, they can be implicitly supported.

We think that this might be useful in cases where a lease query client
want to get details of a specific IP address/MAC addresses.

If keeping it in the combined draft will not result in too much of work,
we think we should support it.

>   as a message in a response, or DHCPLEASEUNASSIGNED as a message in a

We agree with this proposal but there is a small difference as mentioned
above.

'kinnear-draft' has proposed a new message type 'DHCPBULKLEASEQUERY'
while 'dtv-draft' uses the old message type 'DHCPLEASEQUERY'.

We propose that for getting states of *all* lease queries, we should use
the new message type 'DHCPBULKLEASEQUERY' while for other cases, we
should use existing lease query.

The other method could be that we all uses existing message type
'DHCPLEASEQUERY' and use differentiate between different query types
based on the information available in the DHCP message.

>   message, we could just special case that and say that it only needs to

We agree that DHCPLEASEDATA approach would not work with
'kinnear-draft'. I agree that 'dtv-draft' can do with just
DHCPLEASEACTIVE messages.

But we think it would be good to have server-id option in just the first
message so that we can save on some bandwidth.

>   bother to allow it and document it since it really isn't a good idea

We think this is fine for Bulk Lease Query and Query by Relay id. But we
had kept it in our draft because of Query by Remote id and RFC 4388
based query types. 

A lease query client would like to use the same TCP connection when
doing query by remote-id or RFC 4388 based query types and we think we
should allow that.

>   time, and encode the state in the status option.

We think this proposal is fine. We just wanted to check if we would
still need DHCPLEASEQUERYSTATUS message as well. Can we just use
DHCPLEASEDONE with a dhcp-status option for all such instances?

>   it will make it through the DHC WG process remains to be seen.

Yes. This proposal is fine.

>   Plus, writing the client code is a lot easier.

This looks good to us. With this, will we still need
DHCPLEASEFAIL/DHCPLEASEQUERYSTATUS message type?

>   Proposal:  Leave out the two unused bytes, and frame it with a 16 byte

Ok. This is fine.

>   from failover about how important this is.

We feel kinnear-draft explains this in much more detail.

>   see below on whether or not they are "required".

Ok.

>   process, that might work.

Yes. This is something which we really feel should be kept as is. We
would also like to keep it in the final RFC if possible.

Ok. Yes. We were also planning to propose the same.

>   we're still thinking about this, and open to some level of suggestion.

Yes. This looks good. 

Should not this be proposed only for some specific options like option
125? Also people may ask that if they want to fetch both the values,
will there be a way to query them specifically?

If you think we should get on a conference call to discuss some of these
items, let us know.

Thanks & Regards,
Bharat

**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely 
for the use of the addressee(s). If you are not the intended recipient, please 
notify the sender by e-mail and delete the original message. Further, you are not 
to copy, disclose, or distribute this e-mail or its contents to any other person and 
any such actions are unlawful. This e-mail may contain viruses. Infosys has taken 
every reasonable precaution to minimize this risk, but is not liable for any damage 
you may sustain as a result of any virus in this e-mail. You should carry out your 
own virus checks before opening the e-mail or attachment. Infosys reserves the 
right to monitor and review the content of all messages sent to or from this e-mail 
address. Messages sent to or from this e-mail address may be stored on the 
Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg