RE: [dhcwg] revisions to DHCPv4 Server MIB suggested by MIB "Doctor"

["Bernie Volz" <[e-mail]>]

Hi Barr:

I don't have a copy of -09 and -10 appears to have already removed the
optional statistics and switched to 64 bit counters.

I think removing anything optional is fine. The smaller the initial MIB, the
more likely it will be to get deployed.

Looks like you also switched most of the counters to 64 bits, so I'm not
sure why section 3.3.2, Counter Rollover, is needed? With 64 bits, I can't
see rollovers being likely (even with very infrequent polling).

While I believe 32 bits should have been sufficient for counters (since
you're not counting bytes), I also see no harm in going to 64 bits. ASN.1 is
a compact representation, so there's really not any penalty over the wire
whether the counter is 32 or 64 bits unless the value itself exceeds 32
bits. 

So, I'm OK with these changes.

- Bernie

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Barr
Hibbs
Sent: Monday, March 01, 2004 3:55 PM
To: [e-mail]
Cc: [e-mail]
Subject: [dhcwg] revisions to DHCPv4 Server MIB suggested by MIB "Doctor"


David Harrington has been assigned to work with Glenn and
myself to finalize the proposed DHCPv4 server MIB
("draft-ietf-dhc-server-mib-09.txt"), making sure that it is
conformant with current SNMP practice and implementable.

David has proposed many improvements to the text, most of
which fall into the general category of clarification, which
I believe do not require WG approval to incorporate.

There are at least two concerns about the proposed MIB that
David has expressed which represent significant changes to
the MIB.  First, the two large portions of the MIB that were
declared optional (BOOTP and DHCP optional statistics) and
the size of counters used throughout the MIB.

Dealing first with counters, the original work which led to
the development of the MIB was done on a mainframe computer
that supported both 32-bit and 64-bit integers, both signed
and unsigned.  We collected the server's statistics
(actually, our primary reason for developing the MIB) at
hourly intervals and even at a prolonged level of traffic in
excess of 100 DHCP requests per second received from our
client population, the 32-bit counters were sufficient to
avoid roll-over during the data collection intervals.  At
issue now is whether a 32-bit counter is of sufficient size
not to roll-over during likely data collection intervals on
servers managing the address space for 100s of thousands of
clients.

If one assumes that 10,000 clients can generate 100 msgs/sec
during a mass event, and that the client population is
500,000 for a very large server (5000 msgs/sec), then a
32-bit counter will roll-over in about 10 days.  The
appropriate questions are, "Can anyone provide better
estimates of both maximum number of clients and the peak
message arrival rate?" and "What is the longest interval
between data collection points that can be reasonably
expected?"  The answers to both of these questions impact
the choice of counter size.

The second significant change for which I need WG
concurrence is to entirely remove the two large optional
sections of the MIB, BOOTP optional statistics and DHCP
optional statistics.  The last time the structure of the MIB
was discussed at a WG meeting, the consensus was to make
both sections optional as only a very few implementors or
operators were interested in the traffic engineering data
that these sections covered.  There were no comments about
this from the mailing list.

Sorry I can't be in Seoul with you all to raise these issues
in the meeting.

--Barr


_______________________________________________
dhcwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg




_______________________________________________
dhcwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg