Subject: Re: [dhcwg] Comparison between DHCPv4 Bulk Leasequery drafts

From: Kim Kinnear <[email-masked]>
Date: Fri, 05 Sep 2008 12:12:12 -0400

Bharat,

This is a continuation of the discussion of how to unify the two
existing 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

Thank you very much for your detailed response to my list of
differences.  You caught some things which passed me by, and
perhaps more importantly, caused me to think somewhat differently
about some of the issues.

Let's try for a bit to continue this in email and on the list,
and then if we need a conference call, we can do that.

I'm going to *not* include the previous discussion in order to
keep this email from growing beyond the bounds of reason, but it
would be handy to have it to reference.  Here is the previous
discussion:

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

First, you asked:

>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?

Our answers:

  1.  What is the value of query-start-time and query-end-time?

  A device which is monitoring (gleaning) DHCP activity from a
  data stream and which is disconnected from that data stream for
  a while (but has not lost its current memory), would be able to
  use a bulk leasequery query-time based query to catch up on
  what it has missed in an efficient way once it was reconnected
  to the data stream that it monitors.  This does not imply that
  such a device has stable storage.

  2.  Why send back *all* of the data instead of just current
  lease information?

  Imagine a device, above, which is trying to catch up on what it
  missed while it was disconnected.  It is necessary to get
  information about every IP address that changed, whether it
  became leased to a client or became free, since otherwise the
  device has no way to know if a lease became free during this
  period.  Not hearing about a particular IP address doesn't tell
  you anything in this context.  It can't assume that every IP
  address it didn't hear about is free, because it is only
  learning about the ones that changed.

  That said, we could certainly support an approach which only
  returns *everything* that changed when using the
  query-start-time and/or the query-end-time approach.  We think
  this would be better than tying it to the DHCPBULKLEASEQUERY
  message type as you recommended, for reasons which should 
  become clear, below.

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

A major concern of ours was the mixing of the existing RFC 4388
leasequery query types along with these new query approaches.  We
already have RFC 4388, why are we trying to support the same
queries in an additional context?

However, as you all didn't agree with my first proposal on this
issue (which was to completely leave out the RFC 4388 queries),
here is an alternative proposal.

This also relates to the fact that you had used the
DHCPLEASEQUERY message type for your queries.  Which I had missed,
so thanks for catching that.

Proposal:

We support RFC 4388-style queries over the TCP connection exactly
as they are supported today.  You use DHCPLEASEQUERY and the
query parameters are identical to those in use today and the
response is identical to the response today -- but it is over a
TCP connection.  To be clear -- this is a single request/response
type of query.  It is not in any way "bulk", any more than UDP
RFC 4388 queries are bulk.

If your draft "DHCPv4 Leasequery by relay agent remote ID"
becomes supported as an extension to RFC 4388, then it would also
be supported by the RFC-4388-under-TCP approach discussed above.

We also support bulk leasequery requests *only* over a TCP
connection and these queries use the DHCPBULKLEASEQUERY message
type.  The two types of queries supported here are:
query-by-relayid, and query-start|end-time.  The time based
queries return *all* IP addresses changed during that period, and
the query-by-relayid returns all of the active IP addresses which
contain that relay-id in their option-82 values.

So, of the three new query types defined between the two existing
documents, the two queries which can return more than one
response (and will be terminated by a DHCPLEASEQUERYDONE message)
are initiated by a DHCPBULKLEASEQUERY message type.  The other
one is essentially an extension to RFC 4388 (and is contained in
a separate draft for just that purpose), will be available
through the extension to the existing RFC 4388 message type
DHCPLEASEQUERY.  This RFC 4388-style query should not be
described in the bulk-leasequery draft, but rather as an
extension to RFC 4388 (which you have already done).

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

A second major concern of ours was the multiplexing of various
sorts of queries on the same TCP connection since, as I discussed
before, if one of the queries is a bulk query (i.e., returns a
lot of data in response to a single query), then the availability
of that query is of paramount importance and someone would be
foolish indeed to multiplex bulk queries on the same TCP
connection.

You didn't accept our proposal on this issue, so what about
this:

You can have multiple requests per TCP connection, but only one
at a time.  Thus, you can have a TCP connection and pump RFC 4388
requests at it and get one response per request.  And you can
have a bulk request outstanding and get lots of responses for one
request.  But you can't issue a second bulk request or an RFC
4388 request while a first bulk request is outstanding.

The server reserves the right to limit the client to a single
request per connection and can drop the connection after the
response to a request or after there is no traffic for some
period of time.  But the server can also leave the connection up
for a long time if it is configured to do so.

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

Regarding the server-id option in bulk leasequery responses.  We
can accept that every bulk leasequery client MUST assume that a
response without a server-id option uses the server-id from the
previous response to the same request.  We believe that the
server SHOULD (as opposed to MUST) only send a server-id response
in the first response packet for a bulk request.

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

We agree that the DHCPLEASEQUERYDONE message is really the only
message we need.  The DHCPLEASEQUERYSTATUS message is
unnecessary.  Good catch!

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

Regarding the question of options is the parameter request list
-- whether to return those sent in by the DHCP client associated
with an IP address or those returned by the server to that DHCP
client, we believe that we should return only those sent in by
the DHCP client if there is a choice, and that there should be no
way to request those returned by the server in cases where each
might be possible.  We're not trying to be unresponsive here, but
at some point we need to keep things simple and while we can
imagine unusual cases where someone *might* want the server's
returned options in preference to the client's incoming options
-- practically speaking, it doesn't seem worth the added
complexity.

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

On all other issues I believe we are in agreement.

Once we resolve these issues, I'll volunteer to produce a joint
draft which we can review and hopefully present to the next IETF
in Minneapolis.

Regards -- Kim

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

---

From: Bharat Joshi <[email-masked]>
Date: Tue, 9 Sep 2008 20:09:16 +0530

Hi Kim,

> and then if we need a conference call, we can do that.

Not a problem. I think we are in agreement on most of the points. For the first two points, we request some clarifications but they are not disagreements as such.

I have removed the other points from this mail.

> >Agents] having stable storage and store the lease information in stable

Our original questions were actually broader than the answers below. Probably, they were not clear. Let me try to be clearer in this regard.

We are trying to figure out what are all the applications that can utilize the combination of kinner-draft and dtv-draft.

dtv-draft mainly proposes one query: query-by-relay-id (it proposes others, but let us ignore them for now).

kinner-draft mainly proposes two queries: query-all (get all the information from a DHCP server, when no times are specified), query-by-time (get the information from a DHCP server for a specific time band).

The main application envisaged for dtv-draft is for an access concentrator when it loses all its DHCP gleaned information. (probably because of reset, power cycle etc). dtv-draft generalizes, but the above scenario provided the primary motivation.

Let us consider this scenario in more detail:

In an access network, there are a large number of access concentrators and a small number of DHCP servers are catering towards these ACs.
A DHCP server may be serving many ACs. An AC may contact multiple DHCP servers. DHCP servers are assumed to store the associated relay-id of an AC with each of its assigned IP addresses. AC gleans DHCP information passing through it related to its clients.

Now, suppose an AC has lost all its gleaned information. Then it is supposed to use query-by-relay-id to seek the lost information with each of its associated DHCP servers.

Is kinnear-draft also meant for this scenario? It appears it may not be. Here is our reasoning.

Suppose we try to apply the two queries proposed in kinner-draft: query-all and query-by-time. The AC which lost the information can use query-all to query all its associated DHCP servers, but it will be overwhelmed with lot of unneeded information (as it is getting ALL the information present in a DHCP server).

We are wondering whether query-by-time can be applied for AC at all.
If the AC lost its entire information, then it can not use times anyway.
Now, consider the scenario mentioned below.

>   such a device has stable storage.

This scenario may not be applicable to AC because of the way it gleans.
ACs glean while they forward DHCP requests to DHCP server or when they receive a response from DHCP server. Now, how can an AC be disconnected from this data stream of DHCP messages?

Hence it appears that the above scenario may not be the target scenario for queries defined in kinner-draft. Could you please explain in what scenarios then these queries may be used? If the draft actually applies to AC scenario, what are we missing in our understanding?

The resolution of second point depends upon this point so we can discuss that point once we understand/resolve the first one.

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

---

From: Kim Kinnear <[email-masked]>
Date: Mon, 22 Sep 2008 11:21:21 -0400

Bharat,

Sorry it has taken me a while to get back to this discussion.
When I first read your response, I didn't really understand where
the disconnect was, but now I believe I understand.

In my description of the value of query-time (as well as the
ability to get all of the DHCP lease state database information
from a DHCP server using bulk leasequery), I described a
hypothetical "device".  I did not call it an access concentrator,
and I did not mean to imply that it was an access concentrator.

Your questions all revolve around how an access concentrator
could behave like the device that I have described.  While I can
imagine that the device I described could be (or be part of) an
access concentrator, the device I described is not primarily an
access concentrator.  I agree with you -- certainly a garden
variety access concentrator would not require the query-time
capabilities that we have specified for bulk leasequery.

I hope that clears up this misunderstanding -- I apologize for
taking so long to figure out where we were not communicating.

I'll look forward to your reaction to the rest of the points that
I made in:

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

Thanks -- Kim

---

From: Bharat Joshi <[email-masked]>
Date: Fri, 26 Sep 2008 19:23:37 +0530

Kim,

      Please see my response in line.

Regards,
Bharat

> taking so long to figure out where we were not communicating.

Yes. It clears up this misunderstanding. Thanks for your patience. Since text in kinnear-draft suggest that this device could be a Relay Agent, we got confused.

We wanted to have a clear understanding of the use case of the bulk lease query described in kinnear-draft which resulted in these questions. Now we understand that this device may exist somewhere in the network and may query the DHCP server to get the status of all IP addresses configured in that DHCP server.  Would it be possible for you to add some use cases [application] for this in the combined draft?

> http://www.ietf.org/mail-archive/web/dhcwg/current/msg08841.html

I think we are in agreement in all the other points except one point where we were discussing the use of new message type.

We feel that we should use just one single message type 'DHCPBULKLEASEQUERY' in the combined draft. The reason behind is that all the existing query types [query by MAC/Client Identifier/Remote-id/Relay-id] actually are bulk lease query. What we mean by 'bulk' here is that these query may result in one or multiple responses from the DHCP server.  We can add 'query by IP address' just for the sake of completeness here.

DHCP server can use the machanism similar to RFC 4388 to identify the type of DHCPBULKLEASEQUERY. For example: a BULKLEASEQUERY with remote-id will have message type set to 'DHCPBULKLEASEQUERY' and only remote-id sub-option in option-82 is populated. Similarly, query by relay-id will have message type set to 'DHCPBULKLEASEQUERY' and only relay-id sub-option in option-82 is populated. For querying all the IP address state in DHCP server, only message type will be set to 'DHCPBULKLEASEQUERY'.

Start-time and End-time option can be combined with any of the relay types which can work as second level of filtering on top of query types identified as mentioned above.

This approach is actually compatible with both dtv-draft and kinner-draft as they are written currently. One change will be needed in dtv-draft which currently is using RFC 4388's DHCPLEASEQUERY message type, but, as discussed before, it is better to change it to use the new message type: DHCPBULKLEASEQUERY.

The advantages of this approach is that the existing queries (by IP address, mac address, client-identifier, and remote-id) will be supported seamlessly without any extra effort on our part. Moreover, this approach is also compatible with RFC 4388 and hence those servers which are supporting RFC 4388 can be easily upgraded to support the new queries.

I think you can create the combined draft with the above change. If you feel that the above points need some more discussion or you have any other concerns, please let us know.

Please do send us the combined draft as and when it is ready so that we can review the same before it is posted on Internet-drafts.

---

From: Kim Kinnear <[email-masked]>
Date: Fri, 26 Sep 2008 16:48:38 -0400

Bharat,

Thanks for getting back to me.  

Please see my responses inline...

>We feel that we should use just one single message type 'DHCPBULKLEASEQUERY' in the combined draft. The reason behind is that all the existing query types [query by MAC/Client Identifier/Remote-id/R…

        I'm not enthusiastic about adding things "just for
        completeness", since what I believe you are proposing is
        very much *not* RFC 4388 compatible.  If you had agreed
        to our proposal for using the existing RFC 4388 packet
        request format for RFC 4388 requests over TCP and
        expecting RFC 4388 responses over the same TCP
        connection, I would certainly be in favor of supporting
        the 'query by IP address' as well.

        However, I believe that you are considering a response
        different than RFC 4388 to the RFC 4388-style queries in
        a DHCPBULKLEASEQUERY.  I *think* you are proposing that
        instead of returning an associated-ip option for, say, a
        query by MAC address, you are proposing that the
        DHCPBULKLEASEQUERY return all of the IP addresses (if
        any) that were found associated with that MAC address.
        That's different than the RFC 4388 approach, and so
        adding the IP address query as well (which is not, ever,
        a bulk query) seems to distort the approach that you were
        taking.

        I can see two ways to go here :

          a) RFC 4388 queries and responses (using associated-ip
          option where necessary) over TCP and DHCPBULKLEASEQUERY
          queries over TCP for the new, massively bulk things we
          both have proposed.

          b) All queries use DHCPBULKLEASEQUERY over TCP but we
          only include queries that could reasonably be bulk
          queries.  That is to say, not IP based queries.

>DHCP server can use the machanism similar to RFC 4388 to identify the type of DHCPBULKLEASEQUERY. For example: a BULKLEASEQUERY with remote-id will have message type set to 'DHCPBULKLEASEQUERY' and…

        Yes, if we go with approach (b), I would agree with this.

>Start-time and End-time option can be combined with any of the relay types which can work as second level of filtering on top of query types identified as mentioned above.

        Sure, that makes sense.  Not required, as far as I know,
        but not a bad idea either.

>The advantages of this approach is that the existing queries (by IP address, mac address, client-identifier, and remote-id) will be supported seamlessly without any extra effort on our part. 

        I presume that you are discussing a specific
        implementation.  I can't speak for your particular code
        base, but I would expect the changes from use of
        associated-ip to actual bulk leasequery I discussed above
        to require at least *some* effort on your part.

        From our implementation standpoint, doing the existing
        RFC 4388 requests and responses over TCP  along with
        separating out the true bulk requests into the
        DHCPBULKLEASEQUERY messages is by *far* the easiest
        approach.  This makes everything much clearer and easier
        to implement and I'm surprised that is not the case
        for you as well.

        But ease of implementation on any specific code base isn't
        by any means the most important issue here.

>Moreover, this approach is also compatible with RFC 4388 and hence those servers which are supporting RFC 4388 can be easily upgraded to support the new queries.

        This is not true of our server, at least, since the
        approach that I believe you have proposed is not truly
        compatible with RFC 4388 from a response standpoint.  But
        perhaps I've misunderstood your proposal.

        I'm not trying to slant this for the ease of our
        implementation, to be clear about this, but rather to
        point out that some of the justifications that you have
        used for the approach you favor seem to be based on a
        belief that such an approach will benefit everyone (or
        most everyone) who implements this.  And in some cases,
        the approach you favor as generally easier to implement
        is actually substantially more difficult for us.  Which
        is a data point of exactly one implementation, of course,
        and not particularly significant.

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

        So, do you favor approach (a), (b) or something else,
        above?

        Once we get this figured out, I'll do the combined draft.

        Regards -- Kim

---

From: Bharat Joshi <[email-masked]>
Date: Mon, 29 Sep 2008 14:08:55 +0530

Hi Kim,

       Thanks for the explanation here. Please see my response in line.

> >I think we are in agreement in all the other points except one point
> where we were discussing the use of new message type.
> >
> >We feel that we should use just one single message type
> 'DHCPBULKLEASEQUERY' in the combined draft. The reason behind is that
> all the existing query types [query by MAC/Client
> Identifier/Remote-id/Relay-id] actually are bulk lease query. What we
> mean by 'bulk' here is that these query may result in one or multiple
> responses from the DHCP server. We can add 'query by IP address' just
> for the sake of completeness here.
>

Part of the disagreement arises from our usage of RFC 4388 compatibility. In our mail, we were talking about compatibility of RFC 4388 with respect to only how requests are prepared and sent. With respect to responses, we were not arguing about compatibility. As you correctly observed, since we were saying that associated-ip-option should not be used, it is not compatible with RFC 4388. We are sorry for the confusion as we were not explicit about that.

We do agree that "query-by-IP address" is not a "bulk" query. Query by MAC address can have multiple responses and hence is a truly bulk query. Where as query by IP address can have only one response. It may be considered as an extreme case of a bulk query which will always have only one response. However, we are not insistent on including query by IP address as a bulk query and the combined draft may omit it.

>           queries.  That is to say, not IP based queries.

As far as our understanding goes, the approach 'b' stated in your mail does the following:

It will support the following queries:
        Relay-ID
        Get the details of all IP addresses at a DHCP server
        Remote-ID
        Client identifier
        MAC address

Start-time and End-time option may be combined with any of the query types which can work as second level of filtering on top of query types identified as mentioned above.

The request will be formatted as follows:

All the queries will use a single message type: DHCPBULKLEASEQUERY.

Relay-ID:

        Query by relay-id will have only relay-id sub-option in option-82 is
        populated.

        MAC address and IP address will be set to NULL and client
        identifier will not be present.

Get the details of all IP addresses at a DHCP server:

        For querying all the IP address state in DHCP server, only message
        type will be set to 'DHCPBULKLEASEQUERY'.

        MAC address and IP address will be set to NULL and client
        identifier will not be present. Option 82 will not be present.

Remote-ID:

        Query by remote-id will have only remote-id sub-option in option-82
        is populated.

        MAC address and IP address will be set to NULL and client
        identifier will not be present.

Client identifier:

        Query with client identifier will have client identifier option in
        the request.

        MAC address and IP address will be set to NULL and option-82 will
        not be present.

MAC address:

        Query by MAC address will have non-zero MAC address.

        IP address will be set to NULL and client-identifier option and
        option-82 will not be present.

While sending the responses, associated-ip-option will not be used. Instead, server will send all the associated responses on the same TCP connection as specified by the existing draft.

Have we understood case 'b' accurately? If so, we think your approach 'b' captures our intentions quite well.

Regards,
Bharat

> >DHCP server can use the machanism similar to RFC 4388 to identify the
> type of DHCPBULKLEASEQUERY. For example: a BULKLEASEQUERY with remote-id
> will have message type set to 'DHCPBULKLEASEQUERY' and only remote-id
> sub-option in option-82 is populated. Similarly, query by relay-id will
> have message type set to 'DHCPBULKLEASEQUERY' and only relay-id
> sub-option in option-82 is populated. For querying all the IP address
> state in DHCP server, only message type will be set to
> 'DHCPBULKLEASEQUERY'.
>
> >Start-time and End-time option can be combined with any of the relay
> types which can work as second level of filtering on top of query types
> identified as mentioned above.
>
> >This approach is actually compatible with both dtv-draft and
> kinner-draft as they are written currently. One change will be needed in
> dtv-draft which currently is using RFC 4388's DHCPLEASEQUERY message
> type, but, as discussed before, it is better to change it to use the new
> message type: DHCPBULKLEASEQUERY.
> >
> >The advantages of this approach is that the existing queries (by IP
> address, mac address, client-identifier, and remote-id) will be
> supported seamlessly without any extra effort on our part.
>
> >Moreover, this approach is also compatible with RFC 4388 and hence
> those servers which are supporting RFC 4388 can be easily upgraded to
> support the new queries.
>