Subject: [Diffserv] DiffServ MIB rev 12 review

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Sun, 2 Sep 2001 14:08:51 +0200

Normally I have just some other MIB doctor do my IESG review.
Harrie Hazewinkel is that MIB doctor for this MIB and he has
done a review of earlier versions and is working on review
of rev 12 too.

I have also done some more detailed review myself, because
- this seems a MIB that can not just be used for monitoring
  but also for configuration. The co-operation between the
  DiffServ WG and the SNMPCONF WG have been very good on that
  topic I believe.
- A lot of effort has been spend on this MIB, and potentially
  a lot of people will implement it.
- Some Generic MIB (SMI) issues have come out as a result.
  We're discussing some of these in SMIng, EOS WGs and on
  the [email-masked] mailing list. Therefor I wanted to
  check out this MIB in more detail as well.

Here is my comments when reviewing.

These items are all more or less serious in my view.
----------------------------------------------------

1.Are the tables persistent or not?
  I do not see the use of StorageType TC, neither do I see any
  words in the DESCRIPTION clauses about the persistency of the
  tables. I'd prefer the use of StorageType. But having heard
  some of the issues at implementation time, I am happy if there
  is only a few words about persistency in the DESCRIPTION clause
  of each table.
  Another storage-type-like TC is being worked on by Juergen
  Schoenwaelder and Steve Moulto. This to try and address some
  of the issues that have been raised on the existing StorageType
  TC. But you may decide that you don't want to wait for that work
  to finish. I hear that we'll get a new draft on this in the
  coming week. 

2.In the compliances, I see a separate group for the set of 
  diffServXxxNextFree objects. The idea is that these only need
  to be implemented when write access (i.e. row creation) is
  supported by the implementation.
  However, one might decide to do an implementation with support
  for write-access (i,e, row creation), yet one might not
  implement all OBJECT-GROUPs, and so one would end up with
  some of these diffServXxxNextFree objects for GROUPS that one
  does not implement/support.
  The solution I think is to remove the diffServMibStaticGroup
  and include each of these objects in the related OBJECT-GROUP
  and add a line aka:

    OBJECT diffServClfrNextFree
    MIN-ACCESS not-accessible
    DESCRIPTION 
       "Object is not required for a read-only implementation."

3.I also seriously propose that we make 2 compliance statements
  The one you currently have (which allows read-only access) and 
  another one named diffServMIBFullCompliance 
  (or diffServMIBConfigurationCompliance or such) that REQUIRES all
   implemented objects to be read-write.
  I would hope that this will encourage implementers to go for a
  SNMP configurable Diffserv Capable device.

4.You are using a new TC IndexInteger for Indices. That is good!
  I would change ".. as an SNMP Index" into ".. as a table Index". 

  Bit... you use the same TC for the diffServXxxNextFree objects.
  I guess it is understandble, but what I often see is that people 
  allow in such objects a special value of zero to indicate that
  no new entries/rows can be created. It would address the concern
  that was posted to diffserv mlist yday where someone want to 
  limit the range to 4096. So I would suggest to add another TC aka:

  IndexIntegerNextFree ::= TEXTUAL-CONVENTION
    DISPLAY-HINT "d"
    STATUS   current
    DESCRIPTION
       "An integer which may be used as an Index in a table.

        The special value of 0 indicates that no more new
        entries can be created in the relevant table.

        When a MIB is used for configuration, an object 
        with this SYNTAX always contains a legal value (if 
        non-zero) for an index that is not currently used in 
        the relevant table. The Command Generator (Network 
        Management Application) reads this variable and uses 
        the (non-zero) value read when creating a new row 
        with an SNMP SET. When the SET is performed, the 
        Command Responder (agent) must determine whether the
        value is indeed still unused; Two Network Management
        Applications may attempt to create a row (configuration
        entry) simultaneously and use the same value. If it is
        currently unused, the SET succeeds and the Command
        Responder (agent) changes the value of this object,
        according to an implementation-specific algorithm.
        If the value is in use, however, the SET fails. 
        The Network Management Application must then re-read 
        this variable to obtain a new useable value.

        An OBJECT-TYPE definition using this SYNTAX MUST specify
        the relevant table for which the object is providing 
        this functionality.
       "
    SYNTAX   INTEGER (0..2147483647)

  By doing this, you might also get rid of 13 or so paragprahps
  in sections 3.2.1 through 3.5.4. that basically say the same 
  thing as above.

5. diffServClfrId and diffServElementClfrId are using the same
   object (diffServClfrNextFree), which is OK, since the entries
   in the two tables are related to each other. But is there a
   sequence in which such entries must be created? For example
   do you first create an entry in diffServClfrTable and then 
   one or more entries in diffServClfrElementTable? If the
   order is not prescribed, then there might be a risk that
   two management applications obtain the diffServClfrNext,
   and that one of them creates an entry in diffServClfrTable,
   while the other starts creating entry(ies) in 
   diffServClfrElementTable. I suggest it would be wise to
   add some words about this?

6. I think that a lot of the comment lines that we see just
   before all the tables SHOULD be moved into the DESCRIPTION
   clause of the table definitions.

7. For diffServClfrElementSpecific, it says that only ONE
   element (per classifier) may have the value zeroDotZero.
   Yet it specifies zeroDotZero as the default value. Is that
   then wise?

8. For diffServMeterSpecific, you should state what happens 
   if the ptr is pointing to a non-existing entry or if the
   ptr is zeroDotZero.

   Same question for diffServActionSpecific

9. I think that diffServParamType should have a syntax of
   AutonomousType as defined in SMIv2-TC (RFC2579).

10. diffServTBParameterInterval has syntax of Unsigned32.
    I wonder what the value zero means? Either it is not
    valid (and then you should specify a range), or it
    may have special meaning, which you should then specify
    in the DESCRIPTION clause.

11. The definitions of diffserv paramter types (i.e. OIDs
    for things like diffServTBParamSimpleTokenBucket and
    such) are OK. However, I think I would organize them
    under somthing like

      diffServAdmin  OBJECT IDENTIFIER { diffServMib 3 }

    That is define one place for administrative things and
    registrations.

    You have another set of these starting on page 81

12. The 2nd para in the DESCRIPTION clause of 
    diffServDscpMarkActDscp is not needed. RFC2578 clearly 
    explains that in this case the index column can and
    should be made accessible.
    If you keep the 2nd para, then it seem to me that you
    should not be talking about an OBJECT-IDENTITY but
    about an OBJECT IDENTIFIER instead.

13. You seem to have discontinuity timestamps (like the
    diffServCountActDisconTime) per row. Is this really 
    what you want? I don't think I have ever seen it
    implemented at the row level. I don't think that that
    is what we intended discontinuity timers for either.
    It seems to add an extra object to each row while I
    wonder if discontinuity indeed
    - happens often
    - if it does happen, does it then only apply to
      one row, or does it apply to multiple or possibly
      all rows in the table.
    A discontinuity timer per table or per MIB is what
    we have seen more often. 
   
    This has been done in a few more tables, so it applies
    to them as well.

14. For diffServCountActStatus, it says that "Any writable
    value may be modified....". I guess literally the 
    statement is correct. But it reads strange if the only
    writable object in this table/row is this object itself.

15. Is zero a valid value for diffServShapingRateLevel, and
    if so does that have a special meaning?
    If not, then must exclude zero via a range specification.

16. The comments at the beginning of diffServMIBCompliance
    probably are much better moved into the DESCRIPTION clause.
    Otherwise you loose them when the MIB gets extracted.

17. I wonder if at the places where you use the InetAddressType,
    InetAddress, InetAddressPrefixLength, if dns names are
    allowed. If not, then you have to specify so in the
    compliance section.

I am also discussing with a few people if this MIB should be
written such that one would NOT have to support createAndWait
(since several vendor-type people have claimed that this make
SET support so difficult and complex to implement). The tables
in this MIB are such (I believe) that we could specify that
only CreateAndGo MUST be supported, because each row fits
in a 484-octet packet (so we do not need to go through the
generic discussion if it indeed MUSt fit in such a small
packet).

Further I have a set of editorial nits that I will send 
directly to Fred, no need to waste bandwidth on this list for
that.

Bert 

_______________________________________________
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: Fred Baker <[email-masked]>
Date: Thu, 06 Sep 2001 16:02:17 -0700

>     If not, then must exclude zero via a range specification.

OK, so most shapers are single rate or dual rate; I can see having three or 
four rates, though I'm not sure why one would do that. It seems I have a 
choice of ranges for this:

         1..2            (differentiates between a single and dual
                          rate shaper, precludes ever doing anything else)
         1..2147483647   (leaves plenty of room for future creativity...)
         1..something else

I'm putting 1..32, on the theory that 1..2 would be enough but leaving 32 
levels leaves plenty of rope for those inclined to hang themselves. Any 
issues, or other opinions?

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Sat, 8 Sep 2001 23:31:50 +0200

I think the important things to consider are:

- If we have diiscontinuity time per row, then a
  nm app will have to retrieve for all rows not
  only the counters, but also the discontinuity 
  timer. So if it retries a table of counters,
  it also retries a lot of discontinuity timers 
  It then has to check each of those timers, every
  time it obtains all these counter. Typically such
  NM apps do that say every 15 mins or so. In order
  to do the check, the NM app probably also keeps
  all these discontinuity timers.
- If we have one discontinuity timer per table, then
  NM picks up the one discontinuity timer and the
  whole table of counters. It checks the discontinuity
  timer, and if not changed since last time, then 
  all counter can be handled, if it changed, then 
  all counters for that table start afresh (which 
  may cause some loss of data for every counter).
  NM app needs to keep one discontinutity timer per
  table.
- If we have one such timer for the whole MIB then
  the granularity is even more coarse

So how often do these things happen? If only occasionally
(say less than once a day), then I think one discontinuity 
timer per table or (if less than once a week) one per the 
whole MIB is fine.
If they happen a lot (say once an hour) then maybe you want
to go per row.

I also think, that if because of some config change, some
more (or less for that matter) data comes by at a specific
counter, that such is not a discontinuity. But that is a
personal opinion.

Bert