Subject: [Diffserv] new MIB draft

From: Fred Baker <[email-masked]>
Date: Fri, 20 Jul 2001 11:13:56 -0700

You may find a new MIB draft at 
ftp://ftpeng.cisco.com/fred/diffserv-mib/draft-ietf-diffserv-mib-10.txt

_______________________________________________
diffserv mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html

---

From: Anders Bergsten <[email-masked]>
Date: Tue, 24 Jul 2001 17:39:22 +0200

Fred, 

I have a quick question that I have been thinking about: 

I was looking through the statistics that you collect in the MIB for
random droppers (diffServAlgDropPkts, diffServAlgDropHCPkts and the two
for Octets)   and, if I understood it correctly, you do not
differentiate between 'random drops', drops caused by exceeding max_th
(diffServRandomDropMaxThreshBytes), and drops caused by exceeding the
queue depth. 

As I understand RED algorithms, there is a hugh difference between these
types of drops; exceeding max_th should rarely occur. If it does, then I
should take some action (either increase max_p or move min_th or
max_th). Drops due to exceeding the queue depth should never occur. On
the other hand true random drops are ok. 

Wouldn't it be sensible to separate these three types of drops in the
MIB and have a counter for each? I mean, for me as an operator they give
different types of information and should be treated separately.

Anders

---

From: Fred Baker <[email-masked]>
Date: Tue, 24 Jul 2001 13:15:25 -0700

At 08:39 AM 7/24/2001, Anders Bergsten wrote:
>MIB and have a counter for each?

point taken

---

From: Fred Baker <[email-masked]>
Date: Mon, 30 Jul 2001 00:51:04 +0100

At 13:21 29/07/2001, Frank Strauss wrote:
>Purely from the SMIv2 syntax perspective I'd like to let you know about
>some things that should be fixed. Maybe, you would like to use smilint
>(http://www.ibr.cs.tu-bs.de/projects/libsmi/) yourself. ;-)

I use smicng, which I have been using as a test for some years; the 
observation has been made in many circles that something it will pass can 
be compiled on any compiler. Perhaps you can get Dave Perkins to update it 
to your specifications.

>- Dates in in LAST-UPDATED and REVISION clauses must have a 4-digit year.

Funny, doesn't match the specifications I find in the RFC I saw that in 
draft 9, when smicng told me it was in error. I checked the RFC archives to 
verify, and chandged it when I found that the format of the date is 
specified in ASN.1 and matches what I have done in this draft. Can you 
instruct me on the point? My research didn't support you.

>- Where the old ASN.1-fashioned type INTEGER is used for signed 32-bit
>   integers, you should use Integer32 in SMIv2 modules instead.

Fine, if the range of the integer is -2^32..+2^32. When it's not, one needs 
to select a TC supporting the correct enumeration. Go check the uses here, 
and you will find that the enumeration is correctly specified, rather than 
specifying that range.

Maybe you need to check the logic of blanket assertions like "all useful 
integers have valid negative values."

_______________________________________________
diffserv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html

---

From: Frank Strauss <[email-masked]>
Date: 29 Jul 2001 14:21:22 +0200

Hi!

Fred> You may find a new MIB draft at
Fred> ftp://ftpeng.cisco.com/fred/diffserv-mib/draft-ietf-diffserv-mib-10.txt

./DIFFSERV-MIB:23: date specification `0102210000Z' contains a two-digit year representing `1901'
./DIFFSERV-MIB:23: date specification `0102210000Z' contains an illegal value
./DIFFSERV-MIB:55: date specification `0106030000Z' contains a two-digit year representing `1901'
./DIFFSERV-MIB:55: date specification `0106030000Z' contains an illegal value
./DIFFSERV-MIB:235: use Integer32 instead of INTEGER in SMIv2
./DIFFSERV-MIB:361: use Integer32 instead of INTEGER in SMIv2
./DIFFSERV-MIB:425: use Integer32 instead of INTEGER in SMIv2
./DIFFSERV-MIB:438: use Integer32 instead of INTEGER in SMIv2
./DIFFSERV-MIB:540: use Integer32 instead of INTEGER in SMIv2
./DIFFSERV-MIB:592: use Integer32 instead of INTEGER in SMIv2
./DIFFSERV-MIB:803: use Integer32 instead of INTEGER in SMIv2
./DIFFSERV-MIB:854: use Integer32 instead of INTEGER in SMIv2
./DIFFSERV-MIB:960: use Integer32 instead of INTEGER in SMIv2
./DIFFSERV-MIB:1009: use Integer32 instead of INTEGER in SMIv2
./DIFFSERV-MIB:1237: use Integer32 instead of INTEGER in SMIv2
./DIFFSERV-MIB:1287: use Integer32 instead of INTEGER in SMIv2
./DIFFSERV-MIB:1418: use Integer32 instead of INTEGER in SMIv2
./DIFFSERV-MIB:1464: use Integer32 instead of INTEGER in SMIv2
./DIFFSERV-MIB:1589: use Integer32 instead of INTEGER in SMIv2
./DIFFSERV-MIB:1643: use Integer32 instead of INTEGER in SMIv2
./DIFFSERV-MIB:1860: use Integer32 instead of INTEGER in SMIv2
./DIFFSERV-MIB:1910: use Integer32 instead of INTEGER in SMIv2
./DIFFSERV-MIB:1978: use Integer32 instead of INTEGER in SMIv2
./DIFFSERV-MIB:1996: use Integer32 instead of INTEGER in SMIv2
./DIFFSERV-MIB:2016: use Integer32 instead of INTEGER in SMIv2
./DIFFSERV-MIB:2065: use Integer32 instead of INTEGER in SMIv2
./DIFFSERV-MIB:2109: use Integer32 instead of INTEGER in SMIv2
./DIFFSERV-MIB:2205: use Integer32 instead of INTEGER in SMIv2
./DIFFSERV-MIB:2252: use Integer32 instead of INTEGER in SMIv2
./DIFFSERV-MIB:2427: use Integer32 instead of INTEGER in SMIv2
./DIFFSERV-MIB:2472: use Integer32 instead of INTEGER in SMIv2
./DIFFSERV-MIB:2631: use Integer32 instead of INTEGER in SMIv2
./DIFFSERV-MIB:2677: use Integer32 instead of INTEGER in SMIv2
./DIFFSERV-MIB:2688: use Integer32 instead of INTEGER in SMIv2

 -frank

---

From: Frank Strauss <[email-masked]>
Date: 30 Jul 2001 10:23:47 +0200

Hi!

>> (http://www.ibr.cs.tu-bs.de/projects/libsmi/) yourself. ;-)

Fred> I use smicng, which I have been using as a test for some years; the
Fred> observation has been made in many circles that something it will pass
Fred> can be compiled on any compiler. Perhaps you can get Dave Perkins to
Fred> update it to your specifications.

I'm quite sure, Dave Perkins is aware of the problem that the SMICng
that many people use is older than RFC 2578-80 which introduced a
number of clarifications. One of these clarifications is more of a
change: the date length has to be 13 for any date after 1999.

>> - Dates in in LAST-UPDATED and REVISION clauses must have a 4-digit year.

Fred> Funny, doesn't match the specifications I find in the RFC I saw that
Fred> in draft 9, when smicng told me it was in error. I checked the RFC
Fred> archives to verify, and chandged it when I found that the format of
Fred> the date is specified in ASN.1 and matches what I have done in this
Fred> draft. Can you instruct me on the point? My research didn't support
Fred> you.

According to RFC 2578 (SMIv2) the Date in LAST-UPDATED and REVISION clauses
is defined by ExtUTCTime on pages 4-5:

  ExtUTCTime ::= OCTET STRING(SIZE(11 | 13))
      -- [...]
      -- 8:15pm GMT on 19 February 1995. Years after 1999 must use
      -- the four digit year format. Years 1900-1999 may use the
      -- two or four digit format.

>> integers, you should use Integer32 in SMIv2 modules instead.

Fred> Fine, if the range of the integer is -2^32..+2^32. 

The range of both INTEGER and Integer32 is -2^31 .. 2^31-1.

Fred> When it's not, one needs to select a TC supporting the correct
Fred> enumeration.

You don't have to define a TC in this case. You can also add a range
restriction to the basetype at the place where it's used (in the SYNTAX
clause of an OBJECT-TYPE).

Fred> Go check the uses here, and you will find that the enumeration
Fred> is correctly specified, rather than specifying that range.

I'm not talking about enumerations or ranges. I'm talking about using
`Integer32' instead of `INTEGER', e.g.:

  diffServClfrNextFree OBJECT-TYPE
      SYNTAX       Integer32 (1..2147483647)
      MAX-ACCESS   read-only
      [...]
  
instead of

  diffServClfrNextFree OBJECT-TYPE
      SYNTAX       INTEGER (1..2147483647)
      MAX-ACCESS   read-only
      [...]

However, this is more of a `should' than a `must'.

 -frank

---

From: Fred Baker <[email-masked]>
Date: Mon, 30 Jul 2001 11:27:52 +0100

>The range of both INTEGER and Integer32 is -2^31 .. 2^31-1.

You and I must be reading different versions of ASN.1. last I checked, 
INTEGER was a primitive type, and can (at least theoretically) represent an 
integer which is arbitrarily large. Integer32 is a TC specified in RFC 1442 
and later which limits the range to 32 bits.

           Integer32 ::=
               [UNIVERSAL 2]
                   IMPLICIT INTEGER (-2147483648..2147483647)

Jeff's comment in 1442 was that "Integer32 is indistinguishable from 
INTEGER"; it is an unfortunate comment, as it is in fact very 
distinguishable. If it were indistinguishable, the following specification 
(which is found on the next page, and says that a Counter64 is one of the 
subset of positive integers that can be represented as a 64 bit number) 
would not be very meaningful:

           Counter64 ::=
               [APPLICATION 6]
                   IMPLICIT INTEGER (0..18446744073709551615)

This limitation was imposed a decade and a half ago when computers were 
typically 32 bits wide. The limitation made life easier for early SNMP 
implementors - they could simply pass integers around as ints.

I'll change the dates to have four digit years.

As to the cases where I call out an INTEGER, please explain which of the 
following is incorrect, and why? I'll accept a statement that I should have 
defined a TC for the range 1..2147483647, or that there is one in existence 
that I could have imported and used, but the assertion that I should 
specify one TC and then change it to another mystifies me.

IfDirection ::= TEXTUAL-CONVENTION
     STATUS current
     DESCRIPTION
        "IfDirection specifies a direction of data travel on an
        interface. 'inbound' traffic is operated on during reception from
        the interface, while 'outbound' traffic is operated on prior to
        transmission on the interface."
     SYNTAX  INTEGER {
                 inbound(1),     -- ingress interface
                 outbound(2)     -- egress interface
     }

diffServClfrElementNextFree OBJECT-TYPE
     SYNTAX       INTEGER (1..2147483647)

diffServClfrElementClfrId OBJECT-TYPE
     SYNTAX       INTEGER (1..2147483647)

diffServClfrElementId OBJECT-TYPE
     SYNTAX       INTEGER (1..2147483647)

diffServSixTupleClfrNextFree OBJECT-TYPE
     SYNTAX       INTEGER (1..2147483647)

diffServSixTupleClfrId OBJECT-TYPE
     SYNTAX         INTEGER (1..2147483647)

diffServMeterNextFree OBJECT-TYPE
     SYNTAX       INTEGER (1..2147483647)

diffServMeterId OBJECT-TYPE
     SYNTAX       INTEGER (1..2147483647)

diffServTBParamNextFree OBJECT-TYPE
     SYNTAX       INTEGER (1..2147483647)

diffServTBParamId OBJECT-TYPE
     SYNTAX       INTEGER (1..2147483647)

diffServActionNextFree OBJECT-TYPE
     SYNTAX       INTEGER (1..2147483647)

diffServActionId OBJECT-TYPE
     SYNTAX       INTEGER (1..2147483647)

diffServCountActNextFree OBJECT-TYPE
     SYNTAX       INTEGER (1..2147483647)

diffServCountActId OBJECT-TYPE
     SYNTAX       INTEGER (1..2147483647)

diffServAlgDropNextFree OBJECT-TYPE
     SYNTAX       INTEGER (1..2147483647)

diffServAlgDropId OBJECT-TYPE
     SYNTAX       INTEGER (1..2147483647)

diffServAlgDropType OBJECT-TYPE
     SYNTAX       INTEGER {
                      other(1),
                      tailDrop(2),
                      headDrop(3),
                      randomDrop(4),
                      alwaysDrop(5)
                  }

diffServRandomDropNextFree OBJECT-TYPE
     SYNTAX       INTEGER (1..2147483647)

diffServRandomDropId OBJECT-TYPE
     SYNTAX       INTEGER (1..2147483647)

diffServRandomDropProbMax OBJECT-TYPE
     SYNTAX       INTEGER (0..1000)

diffServRandomDropWeight OBJECT-TYPE
     SYNTAX       INTEGER (0..65536)

diffServRandomDropSamplingRate OBJECT-TYPE
     SYNTAX       INTEGER (0..1000000)

diffServQNextFree OBJECT-TYPE
     SYNTAX       INTEGER (1..2147483647)

diffServQId OBJECT-TYPE

diffServSchedulerNextFree OBJECT-TYPE
     SYNTAX       INTEGER (1..2147483647)

diffServSchedulerId OBJECT-TYPE
     SYNTAX       INTEGER (1..2147483647)

diffServAssuredRateNextFree OBJECT-TYPE
     SYNTAX       INTEGER (1..2147483647)

diffServAssuredRateId OBJECT-TYPE
     SYNTAX       INTEGER (1..2147483647)

diffServShapingRateNextFree OBJECT-TYPE
     SYNTAX       INTEGER (1..2147483647)

diffServShapingRateId OBJECT-TYPE
     SYNTAX       INTEGER (1..2147483647)

diffServShapingRateLevel OBJECT-TYPE
     SYNTAX       INTEGER (1..2147483647)

---

From: Frank Strauss <[email-masked]>
Date: 31 Jul 2001 10:10:30 +0200

Hi!

>> The range of both INTEGER and Integer32 is -2^31 .. 2^31-1.

Fred> You and I must be reading different versions of ASN.1. last I checked,
Fred> INTEGER was a primitive type, and can (at least theoretically)
Fred> represent an integer which is arbitrarily large. Integer32 is a TC
Fred> specified in RFC 1442 and later which limits the range to 32 bits.

I think we should refer the current SMIv2 specifications in RFC
2578-80 and neither the obsoleted RFC 1442 nor ASN.1. There are
important differences.

Both types are `formally' defined the SNMPv2-SMI module:

  SimpleSyntax ::=
      CHOICE {
          -- INTEGERs with a more restrictive range
          -- may also be used
          integer-value               -- includes Integer32
              INTEGER (-2147483648..2147483647),
  [...]
  -- indistinguishable from INTEGER, but never needs more than
  -- 32-bits for a two's complement representation
  Integer32 ::=
          INTEGER (-2147483648..2147483647)
 
(BTW, Integer32 is not defined through the TEXTUAL-CONVENTION macro,
hence it's not a TC) and described in Section 7.1.1:

  7.1.1.  Integer32 and INTEGER
   
     The Integer32 type represents integer-valued information between
     -2^31 and 2^31-1 inclusive (-2147483648 to 2147483647 decimal).  This
     type is indistinguishable from the INTEGER type.  Both the INTEGER
     and Integer32 types may be sub-typed to be more constrained than the
     Integer32 type.

(From the ASN.1 point of view, you are right: INTEGER is unlimited in range.)

Fred>            Integer32 ::=
Fred>                [UNIVERSAL 2]
Fred>                    IMPLICIT INTEGER (-2147483648..2147483647)

Fred> Jeff's comment in 1442 was that "Integer32 is indistinguishable from
Fred> INTEGER"; it is an unfortunate comment, as it is in fact very
Fred> distinguishable. 

INTEGER and Integer32 are indistinguishable in the sense that when
they are used in the SNMP protocol, both use the same type tag so that
a receiver of an SNMP PDU cannot distinguish them just by the tag.

Fred> I'll change the dates to have four digit years.

Thanks.

Fred> As to the cases where I call out an INTEGER, please explain which of
Fred> the following is incorrect, and why? I'll accept a statement that I
Fred> should have defined a TC for the range 1..2147483647, or that there is
Fred> one in existence that I could have imported and used, but the
Fred> assertion that I should specify one TC and then change it to another
Fred> mystifies me.

Fred> IfDirection ::= TEXTUAL-CONVENTION
Fred>      STATUS current
Fred>      DESCRIPTION
Fred>         "IfDirection specifies a direction of data travel on an
Fred>         interface. 'inbound' traffic is operated on during reception from
Fred>         the interface, while 'outbound' traffic is operated on prior to
Fred>         transmission on the interface."
Fred>      SYNTAX  INTEGER {
Fred>                  inbound(1),     -- ingress interface
Fred>                  outbound(2)     -- egress interface
Fred>      }

This is correct. In case of enumerations you have to use INTEGER
(RFC 2578, Section 7.1.1, second paragraph).

Fred> diffServClfrNextFree OBJECT-TYPE
Fred>      SYNTAX       INTEGER (1..2147483647)

In all these cases where you want to use a 32bit signed basetype
(either range restricted or not) I *suggest* to use Integer32 instead
of INTEGER. It is not incorrect as it is right now. I would just prefer
Integer32 simply for alignment with the `common practice' to use the
`new' xxx32 and xxx64 types. 

 -frank