Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv4-active-leasequery-00 - Respond by Feb. 28

["Bernie Volz (volz)" <[e-mail]>]

Interesting point as that is what we do for v6 (partly because it could be ridicously large depending on how leasing ranges are configured and over time as you would have to keep information on any lease the server ever gave out that it hasn't reused since the server has no idea what information requester might have had).

I guess in v4 as it is generally assumed that the address space is reasonably finite, not a significant issue. But that could also leave stuff behind if server is reconfigured to remove leases. So, yes this seems like it could be useful (optional).

Is it worth extending this for v4 at this time? Making it optional (client can request to only send "useful" stuff, server can ignore if it doesn't support) would be ok.

- Bernie (from iPad)

> On Mar 3, 2014, at 10:58 AM, "Lewis Donzis" <[e-mail]> wrote:
> 
> One other thing I wanted to ask about… currently the DHCPv4 bulk leasequery sends back the entire lease state database, whereas DHCPv6 does not, presumably because it would be ridiculously large.
> 
> However, since we have to handle both cases, our implementation doesn’t need the inactive v4 leases.  At the end of the bulk transfer, we just assume that any previously-active lease that wasn’t transferred must be inactive, just the same as if the server had sent an inactive lease.
> 
> Point being, it’s inefficient and unnecessary to transfer all of the inactive leases, so it might be nice to have an option on bulk leasequery to suppress the inactive entries.
> 
> The reason I mention it here is in case it would make sense to include it in the active leasequery document, i.e., extending bulk leasequery?
> 
> Thanks,
> lew
> 
> 
>> On Feb 27, 2014, at 2:01 PM, Lewis Donzis <[e-mail]> wrote:
>> 
>> I also have read the draft and agree that it should be moved forward.
>> 
>> We have already implemented a client and have experience with this
>> protocol in large production networks, and it has proven to be extremely
>> useful and has significant advantages over standard leasequery.
>> 
>> This may be outside the scope of this discussion, but it would be nice if
>> the specification included, perhaps in section 7, that the server MUST or
>> at least SHOULD include lease state changes for both dynamic and reserved
>> addresses.  There has been some ambiguity on this and it would be nice if
>> all implementations were consistent in this regard.  At a minimum, the
>> DHCP server should provide the same information via active leasequery that
>> it provides via standard leasequery.
>> 
>> lew
>> 
>> 
>> 
>>> On 11 Feb 2014, at 21:38, Tomek Mrugalski 
>>> <[e-mail]> wrote:
>>> 
>>>> We have adopted two active leasequery drafts after
>>> Vancouver meeting.
>>>> There was moderate interest in that work during adoption call, but
>>>> we never saw any discussions about them on the ML. Since authors
>>>> confidence in those proposals are high due to existing
>>> implementations,
>>>> they have requested WGLC.
>>>> 
>>>> After a quick discussion between chairs, we have decided to go ahead
>>>> with the WGLC, hoping that it will trigger some reviews and
>>> discussion.
>>>> Please make no mistake - those drafts need reviews and comments. A
>>>> simple "I support this" followed with couple +1s will not do do the
>>>> trick here.
>>>> 
>>>> This WGLC is for
>>> draft-ietf-dhc-dhcpv4-active-leasequery-00. Please send
>>>> your comments by Feb. 28th. Note that although both
>>> documents are very
>>>> similar, they are separate drafts and are going through
>>> separate WGLCs.
>>>> If you support this work, make sure that you clearly state
>>> which draft
>>>> (v4, v6 or both) you support. Each WGLC will be assessed
>>> independently.
>>>> 
>>>> Finally, I'd also remind you that we are looking for
>>> volunteers to do
>>>> the shepherding work. Please let us know if you'd like to
>>> be a shepherd
>>>> for one of those documents. It is not a difficult task, but
>>> some prior
>>>> IETF experience is necessary. As a shepherd, you can get
>>> unique insight
>>>> into the WGLC process and better exposure to how IESG
>>> works. Having such
>>>> an experience can be useful with moving your own draft
>>> forward faster.
>>>> 
>>>> Bernie & Tomek
>>>> 
>>>> _______________________________________________
>>>> dhcwg mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/dhcwg
>>> 
>>> _______________________________________________
>>> dhcwg mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/dhcwg
> 
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dhcwg