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

From: [email-masked]
Date: Fri, 2 Jun 2000 12:15:55 -0700

Andrew,

>> 1. Section 2.2.1, last paragraph:  If you want to reference
>>    a document that describes roles, the PCIM has a much more
>>    complete discussion of them than Polterm does.
>
>Can you give a specific reference? - there are many uses of the term
"role"
>and I want to make sure we have the right one :-)
The reference I had in mind was to section 5.2 of
draft-ietf-policy-core-info-model-06.txt.  This text represents
a consensus that the Policy Framework WG reached in Adelaide,
and confirmed later on our mailing list.  I've heard second-hand,
however, that snmpconf came up with a different definition of
"role" at their interim meeting in San Francisco.  So whether the
reference I've given you is the "right" one may depend on who you
ask.

>> 5. diffServClassifierLevel (p.20):  The value for the first
>>    level should be specified:  I assume that it's 1, but
>>    0 is also a possible guess.
>
>Not sure that this needs to be specified. The semantics of "lower" are
>clear. You might to label them as e.g. 10, 20, 30 to make adds/changes
>easier. What's a good reason to limit this further?
I was thinking that a management application would like an
easy way to know it's looking at a "first" classifier, but
since ClassifierLevel is part of the index, it should be
able to figure this out.  What you have is fine.

>> 6. diffServClassifierPrecedence (p.21):  The last paragraph
>>    states clearly (except that it's misspelled:-) that the
>>    scope of a classifier is incoming traffic.  But in the
>>    Conceptual Model classification is equally applicable to
>>    incoming and outgoing traffic.
>
>The completeness requirement only applies to incoming - that's what the
>Model draft 4.1.2 says anyhow:
>
>"Note that this completeness is only required of the first classifier that
>incoming traffic will meet as it enters an interface - subsequent
>classifiers on an interface only need to handle the traffic that it is
known
>that they will receive."
After re-reading this section in the Conceptual Model, I
still read it differently.  The context is an explanation
of what an unambiguous classifier is, and why we want the
classifiers in the model to be unambiguous.  So I read
the reference to "incoming traffic" to mean traffic that's
coming into an interface from *either* direction.  With
this interpretation, the Conceptual Model is expressing
two requirements:

   - For the ingress direction, the first classifier that
     traffic coming into the interface from the network
     meets must be unambiguous.
   - For the egress direction, the first classifier that
     traffic coming into the interface from the routing
     core meets must be unambiguous.

I think this point needs to be clarified (one way or the
other) in both documents.  As I read the Conceptual Model,
the goal is to have overall determinacy in the device.
If the routing core is dumb, then I think you have to go
with my interpretation.  Yours only works if the routing
core can somehow insure that an incomplete classifier
sitting in the first position on an egress interface
never gets a packet that falls outside the union of its
filters.

>> 13. diffServActionSpecific (p.33):  The RowPointer TC in
>>     RFC 2579 doesn't allow you to point to a scalar object
>>     such as diffServAbsoluteDropAction.  If you're *sure*
>>     that's this is the only case you'll have where you won't
>>     need to point to another table entry, then you could
>>     probably get away with assigning the absolute drop
>>     semantics to the value zeroDotZero.  Otherwise, you'll
>>     need to do something else.
>
>I had looked at RFC 2579 and to me it was not clear to me whether a
>scalar OID would count or not - depends on the definition of "conceptual
>row" I guess (the reference pointer in 2579 to the definition in 2578
seems
>to be broken). We really want to make this an InstancePointer (a.k.a.
>RowOrVariablePointer) but that has been deprecated :-(. I guess we can
just
>make this an OBJECT IDENTIFIER if we're uncomfortable with the semantics
of
>RowPointer.
I wasn't involved with the SNMP standards when the
InstancePointer TC was deprecated, but people must have
thought that there was a good reason to do it.  If there
are indeed reasons why an InstancePointer is a Bad Idea,
then they would obviously apply as well to an object
that's effectively an InstancePointer, but defined with
the syntax OBJECT IDENTIFIER.  Maybe an SNMP "old-timer"
can tell us why InstancePointer was deprecated.

>> 18. diffServCountActOctets (p.36), and all the other
>>     counters:  There are two problems with specifying that
>>     ifCounterDiscontinuityTime is the discontinuity
>>     indicator for these counters:
>>
>>      1. The definition of ifCounterDiscontinuityTime gives
>>         an explicit list of counters that it "serves".
>>         I don't think you can come along later and add to
>>         this list.
>
>We are not referring to those other interface counters (ifTable and
ifXTable
>in http://www.ietf.org/rfc/rfc2233.txt), we are just piggy-backing onto
the
>reasons for which that variable might have been updated. This is comon
>practice see e.g. RFC2668.
Yes, I see that this was done in RFC 2668.  On the other
hand, here's the Description of ifCounterDiscontinuityTime
from RFC 2233:

   "The value of sysUpTime on the most recent occasion at
    which any one or more of this interface's counters
    suffered a discontinuity.  The relevant counters are
    the specific instances associated with this interface
    of any Counter32 or Counter64 object contained in the
    ifTable or ifXTable.  If no such discontinuities have
    occurred since the last re-initialization of the local
    management subsystem, then this object contains a zero
    value."

This is exactly what I would have written if I wanted to
restrict the scope of this object to include only the
counters in ifTable and ifXTable.  So I'm not sure which
interpretation is correct.  Maybe Keith can offer an opinion
on how this is supposed to work.  In any case, see below:
even if it's *legal* to use ifCounterDiscontinuityTime, I
don't think it does the job here.

>>      2. In any case, don't these counters experience other
>>         discontinuity events (related to changes in the
>>         Diffserv configuration for an interface) that don't
>>         affect the total interface counters that
>>         ifCounterDiscontinuityTime tracks?
>
>Can you be more specific? Do you just mean whenever a
diffServCountActStatus
>changes?
Maybe.  It depends how you go about changing the diffserv
configuration on an interface.  Suppose you already have a
TCB set up on an interface, with a classifier that splits
incoming traffic into three streams that move through
different action elements (including some counters), and
then eventually exit the interface.  Now you want to go in
and change some of the classifier filters, to direct some
additional traffic into one of the streams.  I was assuming
that this change to the filters would be a discontinuity
event for the counters in the TCB, since it makes no
sense to aggregate together counts from before the filters
changed with counts of traffic after they changed.  But this
change would not cause discontinuities in the ifTable and
ifXTable counters.  So you need some sort of discontinuity
indicator specifically for the diffserv counters.

I've written the preceding paragraph as if the scope of
these discontinuity indicators is a TCB, but I understand
that from the MIB's point of view, TCBs are just convenient
groupings of elements, without any real presence in the MIB.
On the other hand, having a separate indicator for each row
in the diffServCountActTable seems too narrow a scope
(although this is the solution I suggested in my original
comments).  I'm not sure what the right answer is here.

>> 22. diffServAlgDropSpecific (p.40):  Why isn't this object
>>     defined as a RowPointer, since you've already said
>>     what the row index will be?
>
>RowPointer seems to have the implied semantics of being an arbitrary row
for
>which the index portions of the OID would have to be checked for sanity,
>which would be redundant. Insisting that it just point to the OID of a
table
>makes life a lot simpler for the agent and manager. If we are allowed to
>"refine" the semantics of RowPointer like this in a DESCRIPTION clause
then
>we can call it a RowPointer but I expected the MIB Inquisition to descend
on
>me if I did that.
No, you can't define this object as you have, and still
call it a RowPointer.  But I'm not so sure that doing it
in the way you've proposed really does make life simpler
for a manager.  Any SNMP management application needs to
be "good" at following RowPointers.  Now you're asking it
to do something different:  build an instance identifier
from the table OID you have in this object plus the index
values for the row where this object resides.  Sure, a
management application could be made to do this.  But I
thought that the point of having the RowPointer TC was to
limit the number of things that a management application
had to know how to do, by having *one* way of getting from
one table entry to another one.

>> 23. diffServAlgDropOctets (p;40), related counters:  For
>>     the reasons given above, ifCounterDiscontinuityTime
>>     isn't the correct discontinuity indicator for these
>>     counters.  Since there's no tight binding between
>>     counter action elements and algorithmic droppers,
>>     the discontinuity indicators for the counter
>>     action elements are also inappropriate.  So yet
>>     another discontinuity indicator is needed for these
>>     counters.
>
>One way would be to say the the discontinuity is ANY OF sysUpTime was
reset
>OR ifCounterDiscontinuityTime OR diffServAlgDropStatus changed. It seems a
>shame to have to define a new indicator just for these counters - can we
get
>away with a diffServIfDiscontinuityTime for the complete interface or
>{interface, direction} perhaps?
SMIv2 doesn't give you this flexibility.  A counter must have
*one* discontinuity indicator, which is implicitly ORed with
sysUpTime.  If you had a TCB-wide indicator, though, it could
handle both the count action counters and these algorithmic
dropper counters.

Regards,
Bob

Bob Moore
IBM Networking Software
+1-919-254-4436
[email-masked]

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

---

From: Keith McCloghrie <[email-masked]>
Date: Fri, 2 Jun 2000 14:34:42 -0700 (PDT)

> the syntax OBJECT IDENTIFIER. 

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.
 
> 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.

> handle both the count action counters and these algorithmic
 
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".

Keith.