Subject: RE: [Diffserv] Comments on the -03 draft of the Diffserv MIB

From: Andrew Smith <[email-masked]>
Date: Fri, 2 Jun 2000 15:01:06 -0700

Thanks Keith. Some questions below.

> -----Original Message-----
> From: Keith McCloghrie [mailto:[email-masked]]
> Sent: Friday, June 02, 2000 2:35 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Diffserv] Comments on the -03 draft of the Diffserv MIB
...
> The SNMPv2 WG in January 1995 agreed to solve:
> 
>    Problem:
>  
>    As currently used in MIB modules, InstancePointer is used for two
>    purposes: to point to the first column of a particular row in a
>    conceptual table; and, to a particular object instance.
>  
>    This ambiguity leads to endless confusion.
>  
> by splitting it into separate TCs.

[Andrew] But it created new problems for people who (validly?) really meant
"one or the other". So I guess your advice would be "use OBJECT IDENTIFIER
and explain what you really mean, clearly, in the DESCRIPTION clause",
right? Rather than (defiantly) going ahead and using InstancePointer.

...
> > In any case, see below:
> > even if it's *legal* to use ifCounterDiscontinuityTime, I
> > don't think it does the job here.
>  
> I agree that the quote from 2233 does not explicitly say "ifTable or
> ifXTable or potentially other tables indexed by ifIndex".  OTOH,
> I think that restricting the scope to include only the counters in
> ifTable and ifXTable would require the word "only" to be used, but
> it's not. 
> 
> I also note that RFC 2668's usage of ifCounterDiscontinuityTime
> counters does not cause interoperability problems for any other
> SNMP entity (mgmt application or agent) which is not aware of the
> usage by RFC 2668.
> 
> Thus, the only downside I see to the use of ifCounterDiscontinuityTime
> by this MIB's counters would be if such usage were to cause
> ifCounterDiscontinuityTime to change its value more often.

[Andrew] In thinking about this some more, I don't think we should make it
such that you have to go back and have to fiddle with the code that
implements ifCounterDiscontinuityTime. I think Bob's original suggestion of
having our own discontinuity time is the safest.

...
> The reason that ifCounterDiscontinuityTime has to be
> 
>     sysUpTime was reset OR ifCounterDiscontinuityTime changed
> 
> is a special case, because the value of ifCounterDiscontinuityTime is
> not necessarily changed on a sysUpTime reset.  The same rationale does
> not apply to when defining new discontinuity indicators.  
> Thus, there is no need to define "ANY OF sysUpTime was reset OR 
> ifCounterDiscontinuityTime OR diffServAlgDropStatus changed".

[Andrew] So I think you are saying that, if we define our own discontinuity
time, we should just mandate in the DESCRIPTION that it be explicitly set to
sysUpTime whenever sysUpTime is changed.

This just leaves the issue of what granularity we need: (a)
diffServCountDiscontinuityTime per-interface, (b)
per-{element-type,interface} i.e. one diffServCountActionDiscontTime and one
diffServAlgDropDiscontTime per-interface, or (c)
per-{element-instance,element-type,interface} i.e. a time in each
diffServCountActEntry and each diffServAlgDropEntry.

I could live with (a) or (b). Either of these requires a new per-interface
table in the MIB.

Andrew

_______________________________________________
diffserv mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/

---

From: Fred Baker <[email-masked]>
Date: Fri, 02 Jun 2000 15:10:16 -0700

>sysUpTime whenever sysUpTime is changed.

in that case, it is sysUpTime in another variable, which seems a little 
pointless. I'm missing something here (as usual). The benefit of having a 
separate discontinuity time is what again?

---

From: Keith McCloghrie <[email-masked]>
Date: Fri, 2 Jun 2000 16:44:03 -0700 (PDT)

> right? Rather than (defiantly) going ahead and using InstancePointer.
 
Right.

> sysUpTime whenever sysUpTime is changed.

I don't think you mean that.  sysUpTime changes every one hundredth of
a second :-), and Fred would be right.

Let me try again - the counters related to any discontinuity indicator,
xxxDiscontinuityTime (i.e., not just those for ifCounterDiscontinuityTime)
need to be defined as:

               Discontinuities in the value of this counter can occur
               at re-initialization of the management system, and at
               other times as indicated by the value of 
               xxxDiscontinuityTime.

or to use your syntax:

   sysUpTime was reset OR xxxDiscontinuityTime changed

The reason is that the value of ifCounterDiscontinuityTime is not
necessarily changed on a sysUpTime reset.  For example, if no counter
discontinuities occur between two successive reboots, then the value
of xxxDiscontinuityTime:

- before the 2nd reboot is zero, and
- after the 2nd reboot is also zero.

So if you only look for changes in the value of xxxDiscontinuityTime,
you will miss the discontinuity that occurs due to the 2nd reboot.

Keith.