Subject: Re: Protocol Action: The Interfaces Group MIB to Proposed Standard

From: David Perkins <[email-masked]>
Date: Wed, 19 Nov 97 14:14:21 pst

HI

The issue with high capacity counters is becoming increasingly important
with 100megabit ethernet, gigabit ethernet, ATM, and high speed WAN
interfaces.

There are two big problems with supporting high capacity counters. They
are:
  1) the lack of a standard way to obtain the values of high
     capacity counters in the SNMPv1 protocol, and
  2) the lack of support for large unsigned integers in
     management platforms.

The problem is primarily due to choosing the data type "Counter64" for
supporting high capacity counters. This data type does not exist in
SNMPv1, and objects with this data type cannot be returned in SNMPv1
messages. To get around this, several approaches have been taken in
standards track MIB modules. The most wide spread is to create two
32-bit counter objects to report the value of a single high 64-bit
counter. These objects are called "split [32-bit] counter objects".
One object reports the high 32 bits, and the other reports the low
32 bits. For these objects to be used in a management app, then both
need to be obtained in the same SNMP request, and value of the 64-bit
object computed by multiplying the high 32 bits by 2^32 (4294967296)
and adding the low 32 bits. The result is a 64-bit unsigned integer.
This leads to the second problem, which is lack of support for such
large unsigned integers in management platforms. Many database systems
do not support such high precision, as well as many libraries that
are used for drawing strip charts do not support such precision.

To help test out management apps, I'm putting together a test MIB
containing split counters and 64-bit counters, and some objects
to control the rate that the counters are incremented. I'm also
putting together a sub-agent using the SNMP Research agent development
kit. I will try to make both available so that we can see how
management applications cope with high capacity counters.

It seems silly to put 64-bit counter objects in MIB modules if they
cannot be used in management apps.

Regards,
/[email-masked], David T. Perkins
Date: 11/19/97, Time: 14:14:21

---

From: Keith McCloghrie <[email-masked]>
Date: Thu, 20 Nov 1997 01:16:19 -0800 (PST)

Dave,
 
I suggest your message/complaint below is neither relevant to this email
thread, nor is it helpful.  RFC 2233 has 64-bit counters.  So, we need
two implementations of the ifHCXxxxx counters in order to advance in 6
months.

Keith.

---

From: [email-masked] (Chris_Martin)
Date: Thu, 20 Nov 1997 08:15:39 -0500 (EST)

> two implementations of the ifHCXxxxx counters in order to advance in 6

I would like a clarification on this comment.

Does this imply that it is required that an agent support SNMPv2?  If
agents are required to implement 64-bit counters per RFC 2233, then 
can converted MIBs (v2 to v1)  be considered a true "implementation."  
As pointed out, there are SNMPv1 protocol issues to consider.

Any insight appreciated.
_____________________________________________________________________
Chris Martin                    INTERNET: [email-masked]
NetEdge Systems                 PHONE: (919) 991-9253 
P.O. Box 14993                  FAX: (919) 991-9160
Research Triangle Park, NC  27709-4993

---

From: Bob Stewart <[email-masked]>
Date: Thu, 20 Nov 1997 08:43:45 -0500

>As pointed out, there are SNMPv1 protocol issues to consider.

An agent is required to support SNMPv2[c] if it wants 64-bit counters,
GetBulk, and error exceptions, since those are features of SNMPv2, added
because SNMPv1 was inadequate.  The only reason to need 64-bit counters is
if you need MIBs that have them, and MIBs aren't supposed to have them
unless they really need them.

So this comes down to supporting what you need.  At some point you stop
trying to be completely backward compatible.  If you could do that
indefinitely, there wouldn't be new versions of things and you'd be forever
bound by the chains of your first version.

There is no way to support Counter64 with v1, even though you can convert
most of the MIB.  So a MIB with 64-bit counters, converted from v2 to v1 is
not complete and if conditions are met for them being mandatory, not
compliant.  In other words there is no way to do a compliant v1
implementation with 64-bit counters.

Some of us believe that it's time to quit whining and implement SNMPv2 (and
shortly SNMPv3).  Some of us did that a *long* time ago.  Dave Perkins
believes it is important to keep going over and over and over the issue of
supporting 64-bit counters in SNMPv1.  The consensus has consistently been
against that, but he doesn't give up.

I'm less polite than Keith.  Is that clearer?

	Bob

---

From: Bob Natale <[email-masked]>
Date: Thu, 20 Nov 1997 10:29:36 -0500

>At 08:15 AM 11/20/97 -0500, Chris_Martin wrote:

Hi Chris,

<...>
>Does this imply that it is required that an agent support SNMPv2?

As Keith and BobS have already said, yes...and agent that
implements a MIB with counter64 objects--modulo MODULE-COMPLIANCE
and AGENT-CAPABILITIES considerations in SMIv2--has to be
SNMPv2 compliant.  (Where SNMPv2 = SNMPv2c and SNMPv2 is a
subset of SNMPv3 for the purposes of this discussion.)

>If agents are required to implement 64-bit counters per RFC 2233,
>then can converted MIBs (v2 to v1)  be considered a true
>"implementation."

Not really...there is no standard way to map counter64 objects
to SMIv1 types...and there really isn't any need to do so.

>As pointed out, there are SNMPv1 protocol issues to consider.

Not really...agents that need to support SMIv2 MIBs with
counter64 objects should just start life as SNMPv2 agents
or as SNMPv1 agents evolved into bilingual agents.

>From the management app side, it's close to trivial to
upgrade an SNMPv1 entity to SNMPv2.  Sure, some mgmt app
vendors might elect not to upgrade their apps for SNMPv2
(or SNMPv3), leaving their users unable to take advantage
of the capabilities provided by SNMPv2 agents...that
happens all the time and is what the marketplace is for.

>Any insight appreciated.

Relative to SNMPv1, SNMPv2 means supporting the following
new features:

	- SMIv2 stuff (of which counter64 is the meatiest)
	- Wider range of error codes (which permit more
	  effective application reaction to conditions)
	- Varbind exception codes (which permit more
	  efficient application use of SNMP messages)
	- GetBulk (which permits more efficient use of
	  agent and network resources...and which is
	  pretty much totally optional in the mgmt app)
	- Normalized trap pdu format (which reduces
	  complexity by eliminating the special nature
	  of the SNMPv1 trap pdu format)
	- InformRequest capabilities (which provide
	  "ack'd traps", so to speak...and which, like
        GetBulk, need to be implemented only for apps
        that will actually make use of them)

(Of course, at the "engine" level all of the above need
to be supported...which, I can assure you, is not hard
to do relative to SNMPv1--and, I suspect, to SNMPv3! :-)

Cordially,

BobN
----- ISO 9001 Registered Hardware and Software Divsions ----
Bob Natale         | ACE*COMM              | 301-721-3000 [v]
Dir, Net Mgmt Prod | 704 Quince Orchard Rd | 301-721-3001 [f]
[email-masked]| Gaithersburg MD 20878 | www.acecomm.com
---- WinSNMP DLL, SDK, Apps & Agents for Win16/32 & UNIX ----
------ NetPlus (r) "FCAPS" Telemanagement Applications ------

---

From: Jeff Johnson <[email-masked]>
Date: Thu, 20 Nov 1997 19:22:52 -0800

I was please to see the new & improved IF-MIB published as RFC 2233.  
What is the current state of the IANAifType-MIB?  Will it be 
republished, with additions, as a new RFC?  I ask because RFC 2233 
obsoletes RFC 1573, and by so doing, obsoletes the only "published" 
version of the IANAifType-MIB.

thanks
/jeff

---

From: "Ted Brunner 503.627.1317" <[email-masked]>
Date: Fri, 21 Nov 1997 10:45:20 -0800

Jeff-

> version of the IANAifType-MIB.

Thats a good point.  But if I recall correctly, the idea behind
separating out the IANAifType-MIB was to improve on the RFC process
by having a continually updated document available via ftp so that
the freshest version could be bundled with each product shipped,
and later loaded again by the customer with little effort.
That was the theory - and a nice one as far as it went.

One problem we have had is that IANA is not updating IANAifType-MIB
as quickly as we had hoped.  Now before it sounds too much like
I'm whining, I do recognize that this year IANA has had some rather
public business concerning DNS high level domains.  (I recall Postel's
picture in The Economist, and some wit about long hair, sandals
and leaders of Biblical stature.)

But the fact remains that our publication mechanism is not as timely
as we wanted. Does that mean that an ifType RFC is a better way after all?
Well, before we jump, lets look at how long we take to put out RFCs.
That record isn't great either.  We invented this IANA ftp-based
mechanism because we were dissatisfied with our own handling of RFCs.
So there isn't a cut and dried case for changing back again.

Other opinions?

Ted Brunner			Video and Networking Division
				Tektronix
				MS 50-490
[email-masked]		14150 SW Karl Braun
503.627.1317			Beaverton OR 97005

---

From: Bob Stewart <[email-masked]>
Date: Fri, 21 Nov 1997 14:55:46 -0500

>Other opinions?

The idea of a live, FTPable file maintains its appeal.  Since assigning new
numbers requires recording them in some file, it seems like the process for
editing and publishing could be reduced to making the file readable to the
world and editing it as necessary.

How could it get more efficient than that?

But of course that procedure is under IANA's control, not ours.

Overall it seems to me like keeping a MIB file FTPable and reasonably up to
date has got to be less work than periodically publishing an RFC, not to
mention the major benefit of having one place to look instead of a moving
target with no simple pointer to the current RFC number.

	Bob