Subject: [dhcwg] Last Call: draft-ietf-dhc-dhcpv6-bulk-leasequery (DHCPv6 Bulk Leasequery) to Proposed Standard

From: The IESG <[email-masked]>
Date: Mon, 20 Oct 2008 05:34:25 -0700 (PDT)

The IESG has received a request from the Dynamic Host Configuration WG 
(dhc) to consider the following document:

- 'DHCPv6 Bulk Leasequery '
   <draft-ietf-dhc-dhcpv6-bulk-leasequery-04.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
[email-masked] mailing lists by 2008-11-03. Exceptionally, 
comments may be sent to [email-masked] instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-bulk-leasequery-04.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=16934&rfc_flag=0

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

---

From: Pekka Savola <[email-masked]>
Date: Tue, 21 Oct 2008 09:09:48 +0300 (EEST)

> http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-bulk-leasequery-04.txt

First there was DHC Leasequery (RFC4388), next DHCv6 Leasequery 
(RFC5007), now we have DHCv6 Bulk Leasequery.  And someone seems to be 
proposing DHCPv4 bulk leasequery as well 
(draft-dtv-dhc-dhcpv4-bulk-leasequery).

RFC4388 S4.2 described reasons why SNMP was deemed inappropriate. 
And if you look at the reasoning there, some of these are not even 
valid anymore for bulk leasequeries.  I remain unconvinced.  A far 
better solution would seem to be define a smaller MIB just for 
querying leases so implementing it would be trivial.  Bulk 
leasequeries just underline the fact that SNMP and MIB data models are 
being reinvented inside DHCP.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Marcus <[email-masked]>
Date: Tue, 21 Oct 2008 09:55:14 +0200

On Tue, Oct 21, 2008 at 8:09 AM, Pekka Savola <[email-masked]> wrote:
> First there was DHC Leasequery (RFC4388), next DHCv6 Leasequery (RFC5007), now we have DHCv6 Bulk Leasequery.  And someone seems to be proposing DHCPv4 bulk leasequery as well (draft-dtv-dhc-dhcpv4-bulk-leasequery).
>
> RFC4388 S4.2 described reasons why SNMP was deemed inappropriate. And if you look at the reasoning there, some of these are not even valid anymore for bulk leasequeries.  I remain unconvinced.  A far better solution would seem to be define a smaller MIB just for querying leases so implementing it would be trivial.  Bulk leasequeries just underline the fact that SNMP and MIB data models are being reinvented inside DHCP.
>
> --

I am not an expert on SNMP, but the only way I could imagine that
working, would be by using queries for MIBs which would look like
this:

get <MIB>.<querytype>

As the query type can be a relay id, link-address or remote id, this
would look a bit strange to me. I know and use SNMP mostly for
querying specific, predefined counters or tables, not variable entries
in the MIB tree. Also all implementations I know, use UDP not TCP for
SNMP queries and replies.
The DHCPv6 Bulk Leasquery proposal looks like a logical next step to me.

Marcus

---

From: Pekka Savola <[email-masked]>
Date: Wed, 22 Oct 2008 08:36:22 +0300 (EEST)

I was hoping some folks more intimate with SNMP and IETF management 
frameworks would chime in here, but I'll respond to clarify:

On Tue, 21 Oct 2008, Marcus wrote:
> in the MIB tree.

If I understand what you want to achieve, what you want is supported 
and indeed used by lots of MIB modules out there.  This is useful and 
indeed we use it regularly with e.g. BGP and IP forwarding MIBs:

$ snmpwalk -m IP-FORWARD-MIB -v 2c -c foo foo-rtr ip.ipForward.ipCidrRouteTable.ipCidrRouteEntry.ipCidrRouteProto.128.214.46
IP-FORWARD-MIB::ipCidrRouteProto.128.214.46.0.255.255.255.0.0.0.0.0.0 = INTEGER: netmgmt(3)
IP-FORWARD-MIB::ipCidrRouteProto.128.214.46.254.255.255.255.255.0.0.0.0.0 = INTEGER: local(2)

> Also all implementations I know, use UDP not TCP for SNMP queries 
> and replies. The DHCPv6 Bulk Leasquery proposal looks like a logical 
> next step to me.

An open-source SNMP implementation (net-snmp) is at least available. 
SNMP over TCP is defined in RFC3430. The systems under consideration 
already support TCP, just the TCP SNMP server part is missing; this 
should be trivial to implement if there is a need -- the lack of 
implementation efforts seems like an indication that UDP with 
retransmissions is usually "good enough".

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 22 Oct 2008 10:17:14 -0700

On Wed, Oct 22, 2008 at 08:36:22AM +0300, Pekka Savola wrote:
> $ snmpwalk -m IP-FORWARD-MIB -v 2c -c foo foo-rtr 

This essentially would be identical to DHCP leasequery, minus the
bulk.  Even if transported via TCP, on the wire it would look like
a single client->server GETNEXT, waiting for a server->client reply
before sending the next one.  One PDU and one OID in it at a time.

snmpbulkwalk is a minor improvement; a single UDP reply can contain
many iterated GETNEXT's, or similarly over TCP.  There is still a
'pause' between the client's request and reply.

What the leasequery bulk methods are looking for is "all at once."
The objective is to fill the socket at maximum window size.  I am
not aware of a means to do this with SNMP considering the kinds of
data in DHCP lease tables, and the usual ways MIBs are constructed.

> ip.ipForward.ipCidrRouteTable.ipCidrRouteEntry.ipCidrRouteProto.128.214.46

This kind of underlines a qualm with SNMP data management (as opposed
to network management).

For each iterated GETNEXT or GETBULK both rely upon a fixed point in
the database ("node n"), which was present in the database and was
the last PDU in the server's reply in the previous packet.  But it may
not be present in the database at the time the next request is made.

This requires the database models used by the servers to be able to
find a "reliable sorting", where the previously-valid-now-invalid
OID can still be used as an index to provide continuation; it can
still grant the next OID.

This essentially is a problem, or at least a facility not present in
some DHCP databases, which caused us to motivate away from UDP based
bulk queries (the original bulk leasequery proposal was more similar
to snmpwalk in this regard, and this was a concern raised by
implementers).

In addition...

SNMP likes to present a single table of a single variable at a time.
I suppose we could overcome this by having the DHCP lease information
in an 'blob of octets' rather than in classical SNMP variable form
(INTEGER etc), so you only have one MIB to walk.  But it seems foreign
to SNMP to do so.

The problem is that most leasequery clients are not positioned to
allocate fields of temporary memory in order to make sense of SNMP's
kind of "scatter-gather" approach to this kind of data transfer.

To make sense of SNMP MIBs you have to develop some strategy to
receive multiple datapoints from different locations and times.

For example, you start by walking a table of "index" advertisements,
where you receive an 'index number' that can be used into other MIBs
to find variables associated with that database entry.

For each of these indexes you discover, you could then queue single
GET PDU's for each separate variable you were interested in (lease
state, lease expiration time, ...).

There are 'performance alternatives' from there, and they are
fantastic to entertain because so many SNMP server implementations
will outright crash if too many PDUs are queued in a single packet
(others corrupt their replies if there are more than single PDU's).

This becomes more problematic when you consider that some leasequery
clients are going to want only a subset of the MIB's total contents.
The question truly is "what leases did I have in my table before I
rebooted?"  Such filtration in an SNMP MIB model I think would be
done on the client end, not on the server end, meaning the client
still must traverse some entire MIB one PDU (GETNEXT or GETBULK) at a
time.

This is different from the proposed bulk leasequery models, where the
server writes to the TCP socket "all at once", with all data for a
given lease spatially located in the same position in the TCP stream,
and a primitive query language ("by query type") to provide subsets.

This doesn't mean a standard DHCP MIB isn't a bad idea for entirely
different reasons.

-- 
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
Why settle for the lesser evil?	 https://secure.isc.org/store/t-shirt/
-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg