Hi - > From: "David W. Hankins" <David_Hankins@xxxxxxx> > To: "DHC WG" <dhcwg@xxxxxxxx> > Cc: <ietf@xxxxxxxx> > Sent: Wednesday, October 22, 2008 10:17 AM > Subject: Re: [dhcwg] Last Call: draft-ietf-dhc-dhcpv6-bulk-leasequery(DHCPv6 Bulk Leasequery) to Proposed Standard ... > 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. Uh... One of the useful features of tables is to organize related information into conceptual rows with common INDEX values. I'm not sure where "a single table of a single variable at a time" comes from - GetBulk certainly has no such limitation. ... > 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, ...). That would be a spectacularly inefficient implementation strategy. I should hope there's nothing in the SNMP RFCs that would be read as encouraging such wasteful behaviour. > 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). I'm not sure what you're trying to say here. An SNMP message (which would normally be carried in a single UDP datagram) by definition contains exactly one SNMP PDU. > 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 depends on the design of the MIB module in general, and the selection of the INDEX elements in particular. Choosing INDEX elements for a MIB module is *not* the same problem as selecting indexes for a database. The use cases for information access, such as "what leases did I have in my table during time period X" are also important. Sometimes it makes to have "shadow" tables that do nothing but provide re-ordered access to the table with the "real" data - but this requires careful thought about what the high-frequency or high-value use cases are. Randy _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf