Re: [dhcwg] Comparison between DHCPv4 Bulk Leasequery drafts

[Bharat Joshi <bharat_joshi at infosys.com>]

Hi Kim,

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

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.

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

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.

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


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
dhcwg at ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg