Subject: Re: [dhcwg] dhc WG last call on draft-ietf-dhc-dhcpv6-bulk-leasequery-00

From: "Wes Beebee (wbeebee)" <[email-masked]>
Date: Mon, 19 May 2008 14:48:26 -0400

In general, I approve of this draft.  However, I have a few comments:

1) In the Abstract, you say that in some situations individual queries
may not be possible.  How can that be?  I can understand how it can be
so inefficient as to not be practical, but how can it actually be
impossible?

2) "The relay may be a network device without adequate local storage to
maintain the necessary binding-to-route data."  I think the issue is
that the relay agent may not be the authoritative source of information
and that information may go away through corruption/reboot.  Not having
enough local storage is not the issue.

3) "In the case of DHCPv6 Prefix Delegation, the PD binding data may
need to be known before any traffic arrives from the client router.  The
DHCPv6 relay router may not be able to form individual queries in such
cases."  You might wish to note that it is possible with the original
Leasequery protocol to ask for the lease associated with an individual
address from a delegated prefix.  Conceivably, a router could kick off a
lease query when it encounters such a packet in a rate limited way, and
if you exceed the rate limit, then the packet is just dropped.  Although
it would result in reduced performance than having a bulk leasequery...

4) Should the message framing for TCP use the standard TLV format?

5) Shouldn't you declare port 547, which is mentioned in 5.6, also in
the IANA considerations?

- Wes

--------------------------------
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Ralph Droms (rdroms)
Sent: Monday, April 28, 2008 1:33 PM
To: DHC WG
Cc: Dhc Chairs
Subject: [dhcwg] dhc WG last call on
draft-ietf-dhc-dhcpv6-bulk-leasequery-00

This message announces a WG last call on "DHCPv6 Bulk Leasequery"
<draft-ietf-dhc-dhcpv6-bulk-leasequery-00.txt>.  The last call will
conclude at 1700EDT on 05-19-2008.

Please respond to this WG last call.  If you support acceptance of the
document without change, respond with a simple acknowledgment, so that
support for the document can be assessed.  Lack of discussion does not
represent positive support.  If there is no expression of support for
acceptance during the WG last call, the document will not be advanced to
the IESG.

There was an issue raised during the discussion of this draft at the dhc
WG meeting during IETF-71 regarding the termination of the TCP
connection after a bulk leasequery transaction.  That issue should be
discussed during this last call, and the duration of the last call has
been extended to three weeks to allow for that discussion.

The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) has been
extended with a Leasequery capability that allows a client to request
information about DHCPv6 bindings.  That mechanism is limited to queries
for individual bindings.  In some situations individual binding queries
may not be efficient, or even possible.
draft-ietf-dhc-dhcpv6-bulk-leasequery-00.txt specifies extensions to the
Leasequery protocol that add new query types and allow for bulk transfer
of DHCPv6 binding data.  This draft is available as
http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-bulk-leasequer
y-00.txt

- John Brzozowski, Ralph Droms
   dhc WG chairs

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

---

From: Mark Stapp <[email-masked]>
Date: Mon, 19 May 2008 15:27:34 -0400

Hi Wes,

some responses inline...

> so inefficient as to not be practical, but how can it actually be

I think in this case 'impractical' is equivalent to 'impossible'. the 
text there is just trying to describe some of the motivation for 
extending beyond the (now RFC) single query. do you really have an 
objection to that word in the text?

> enough local storage is not the issue.

do you really feel that this is something that must be changed to move 
forward? my thinking there was that if there were stable storage, the 
network element could simply refresh its cached information from it, and 
would not need to query the DHCP server at all.

> it would result in reduced performance than having a bulk leasequery...

like (1), the motivation for the new draft is that the facility offered 
by RFC5007 may not be optimal for certain situations. there's nothing 
_wrong_ with the single query - the new draft isn't meant as a critique 
of the RFC. do you really feel that this text must be changed?

> 4) Should the message framing for TCP use the standard TLV format?

is there an issue with the framing as specified? is there a prominent 
advantage to adding TLVs for this purpose? there are always alternatives 
- just trying to pick one and stick with it here.

> 5) Shouldn't you declare port 547, which is mentioned in 5.6, also in

I guess I didn't think so - I'm not asking for a new assignment of any 
kind. the TCP ports are already assigned. do you think there's something 
unclear or missing?

Thanks,
Mark

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 19 May 2008 15:35:21 -0400

Wes:

I think it is both (see my answer to your issue 3).

This doesn't work if no traffic would ever be received because the
network intrastructure never routes packets there (as the router
advertisement stopped being advertised when the router went down). There
are cases where the majority of the data flow is one directional.

The document uses LV. Not sure why T would need to be there? T is in the
V part (as the msg-type field).

5) Shouldn't you declare port 547, which is mentioned in 5.6, also in
the IANA considerations? Also, I don't think IANA considerations can
assign port numbers (though perhaps that has changed as the last time I
investigated port number assignments was a while ago). In any case, no
new port needs to be assigned.

TCP Port 547 was reserved long ago for DHCPv6 (from
http://www.iana.org/assignments/port-numbers):

dhcpv6-client   546/tcp    DHCPv6 Client
dhcpv6-client   546/udp    DHCPv6 Client
dhcpv6-server   547/tcp    DHCPv6 Server
dhcpv6-server   547/udp    DHCPv6 Server
#                          Jim Bound <bound&zk3.dec.com> 

- Bernie

-----Original Message-----
From: Wes Beebee (wbeebee) 
Sent: Monday, May 19, 2008 2:48 PM
To: Bernie Volz (volz)
Cc: [email-masked]'
Subject: RE: [dhcwg] dhc WG last call on

- Wes

---

From: "Wes Beebee (wbeebee)" <[email-masked]>
Date: Mon, 19 May 2008 15:44:21 -0400

Responses inline. 

-----Original Message-----
From: Mark Stapp (mjs) 
Sent: Monday, May 19, 2008 3:28 PM
To: Wes Beebee (wbeebee)
Cc: [email-masked]
Subject: Re: [dhcwg] dhc WG last call on

Hi Wes,

some responses inline...

WB> Impractical would be better.

> 2) "The relay may be a network device without adequate local storage 
> to maintain the necessary binding-to-route data."  I think the issue 
> is that the relay agent may not be the authoritative source of 
> information and that information may go away through 
> corruption/reboot.  Not having enough local storage is not the issue.
> 

WB> I guess what you're trying to say is that because a large portion if
not the entire store can be invalidated at once, there is a need for a
bulk leasequery.  Note that this is NOT the same as saying that there is
no local storage.  Our routers DO have enough local storage to do the
job, but we still need bulk leasequery because the information may be
invalidated.

> address from a delegated prefix.  Conceivably, a router could kick off

> a lease query when it encounters such a packet in a rate limited way, 
> and if you exceed the rate limit, then the packet is just dropped.  
> Although it would result in reduced performance than having a bulk
leasequery...

WB> My point was just that TLV seems to be the standard that's being
pushed for hop-by-hop IPv6 options and other framing at IETF.

WB> Just that if the assignment changes in the future, it may be useful
to have all the IANA-declared items in one place.  If you do put it
under the IANA section, you may wish to declare it as already assigned.

Thanks,
Mark