Subject: Re: [dhcwg] Lease query by remote-id

From: Kim Kinnear <[email-masked]>
Date: Fri, 19 Dec 2008 17:59:50 -0500

Bharat,

I've recently reviewed draft-ietf-dhc-leasequery-by-remote-id-00.txt.

I had the following comments:

Section 5, second to last paragraph:

  "In addition, it may supply additional ...".  I believe this
  should probably be "...  it SHOULD supply" or maybe "...  it
  MUST supply", but a lowercase "may" isn't helpful.

Section 5, last paragraph:

  Every sentence should begin with "The ...".

  "[The] server replies with a DHCPLEASEUNASSIGNED if it has
  information of the said remote ID but no lease is assigned for
  the same".  Andre Kostur brought this up too -- you said to
  him:

>We assumed that a DHCP server would be able to figure out if it is serving a given remote-id or not. So it should be able to reply with DHCPLEASEUNASSIGNED for those which it may be serving but does not have any active lease associated with it.

  While it is certainly possible that some DHCP servers keep
  track of this stuff independent of active leases associated
  with things like the remote-id, our server does not do this in
  a consistent way.  We keep information like this associated
  only with leases, and if we have leases that are not active but
  were once active with a particular remote-id, this would be
  "remembered".  But if no leases are in that situation, we would
  have no memory of any remote-id's we've ever served.  Since the
  remote-id is defined to be opaque {from RFC 3046):

>   The option SHOULD be
>   considered an opaque value, with policies based on exact string match
>   only; that is, the option SHOULD NOT be internally parsed by the
>   server.

  there are few reasons (other than to support this draft) why a
  DHCP server would keep around a separate list of remote-id's
  that it "serves" but for which it has no currently active
  addresses.  DHCP servers are performance limited, and this data
  isn't interesting enough to keep around unless you have a good
  reason for doing so.

  All of this is to say that I think that the above paragraph
  should say:

  "[The] server MUST reply with a DHCPLEASEUNASSIGNED if it has
  information of the said remote ID but no lease is assigned for
  the same.  The server [MAY | SHOULD] keep track of the remote ID values
  for which it has currently active leases as well as any which
  it has served in the recent past but for which it has no
  currently active leases".

  I can see this as a MAY or SHOULD, but certainly not a MUST.

Section 6.3, last paragraph, last sentence:

  "...  server not only know[s] the ..."

Section 6.9.

  "The lease binding data storage requirements are the same as
  those specified in RFC 4388 [RFC4388]."

  I disagree.  In order to answer these queries efficiently, the
  DHCP server would have to at least add an index based on
  remote-id value to the lease state database.  Whether this
  database is on-disk or in-memory, some server-wide index
  capability based on remote-id is necessary to be efficient
  in implementing this draft.

  Not only does this need to be mentioned here in this section,
  but in my mind that is the biggest problem with this draft --
  the additional data storage requirement burden (not space so
  much as time) that this draft places on every DHCP server which
  implements it.  And this cost in processing time is permanent
  even if no relay agent ever uses this query.

Regards -- Kim

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

---

From: Bharat Joshi <[email-masked]>
Date: Mon, 22 Dec 2008 10:31:35 +0530

Hi Kim,

    Thanks a lot for your comments. Please see my response in line.

     I will come out with a new revision soon.

Regards,
Bharat

>   MUST supply", but a lowercase "may" isn't helpful.

Ok. I can change this to 'SHOULD'. Actually we have taken this wording from RFC 4388. We agreed with this wordings because there may be only one IP address associated with the passed remote-id. 

In RFC 4388, it is available in section 5, under "Query by MAC address".

>   the same".  Andre Kostur brought this up too -- you said to

Ok. I will fix this.

> >We assumed that a DHCP server would be able to figure out if it is
> serving a given remote-id or not. So it should be able to reply with
> DHCPLEASEUNASSIGNED for those which it may be serving but does not have
> any active lease associated with it.
> 

Ok. We were thinking that a DHCP server may be pre-configured to have all the remote-ids it will serve. This could be used for IP address allocation or other policy enforcements. So if a DHCP server maintains such information, it can do what we have suggested. But I agree that there may be DHCP server's which do not do this or are not capable of doing this. I will change it to what you have suggested.
 
>   "...  server not only know[s] the ..."

Will fix this.

>   in implementing this draft.

Yes. I agree.

>   even if no relay agent ever uses this query.

Ok. I will add this information in the protocol overview as well as under this section so that it becomes explicit. I agree that for a DHCP server to respond effeciently, it needs to index the allocated lease using remote-id as well.

I agree that this increases the processing required in DHCP server but if a DHCP server supports query by remote-id, it need not support query-by-mac-address and query-by-client-identifier which will surely help in saving some time as well as space.

In any case, if a DHCP server supports DHCPv4 Bulk Lease query, it would need to do the above so the lease database can be used by both UDP/TCP based lease query.

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