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

From: [email-masked]
Date: Tue, 30 May 2000 14:09:15 -0400

I'll just start from the beginning of the draft and move
through it:

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.

2. Section 2.3.1:  This says that specific meter parameters
   are referenced via a RowPointer.  In the MIB, though, (p.28)
   it's an Object Identifier rather than a RowPointer.
   Which is it supposed to be?

3. Section 2.4.3:  This description doesn't match the MIB,
   since it refers to a nonexistent diffServActionType
   object.  See my comment below, though -- what's currently
   in the MIB isn't right either.

4. diffServClassifierTable (p.19):  The reference to "incoming"
   traffic seems wrong, unless it's just talking about traffic
   that's coming into the classifier.

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.

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.

7. diffServSixTupleClfrDstAddrMask (p.23):  You should add
   UNITS="bits" to the definition.

8. diffServMeterTable (p.27):  "The traffic stream to be
   metered is determined by the classifier upstream of the
   meter i.e. by the object(s) that point to each entry in
   this table using a RowPointer."  This is too restrictive.
   There are examples in the Conceptual Model where an
   element other than a classifier feeds traffic to a
   meter.

9. diffServMeterSucceedNext (p.28), several other objects:
   I'm trying to relate the sentence about zeroDotZero
   back to the Conceptual Model.  Does this value mean that
   the traffic is Muxed together with other traffic if
   necessary, and then passed out of the outermost TCB for
   the interface/direction?

10. diffServMeterSpecific (p.28):  As noted above in item 2,
    the introduction already states that this is a RowPointer.
    Wouldn't a RowPointer be a better choice for this object
    than an Object Identifier?

11. diffServTBMeterTable (p.29):  I've read the second
    paragraph, and compared it with section 2.3, but I'm
    still not sure what point is being made.  It *seems*
    like the text in section 2.3 says that modeling complex
    meters with the objects defined in the MIB results in
    a model that's equivalent to the complex meter.  (This
    also strikes me as how it should be.)   In the description
    of diffServTBMeterTable, however, it says that the
    cascading of elements necessitated by the MIB structure
    results in something that is *not* "functionally
    equivalent to a multi-rate meter."  You need to clarify
    what you mean here.

    There's also an editorial problem with the end of this
    description on p.30 -- the text just quits in the middle
    of a sentence."

12. diffServTBMeterStatus (p.30):  You need to say more about
    how a RowStatus object works when the table it's in is
    just a "reflection" of another table.  (I think you were
    about to say something about this in the sentence that
    got lost in the table's description.)  Have you thought
    through whether you need a separate RowStatus object for
    this table at all?  If you could somehow ride along on
    diffServMeterStatus, you'd avoid questions about what it
    means if these two status objects have different values.

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.

14. diffServActionStatus (p.33):  Typo in the description:

      meter-->action

15. diffServDscpMarkActTable (p.34):  How does this table
    work without a RowStatus object?  Is this table just
    always there, with 64 rows in it, in case an action
    entry needs to point at it?

16. diffServDscpMarkActDscp (p.35):  You need to state that
    the value -1 is not allowed for this object.

17. diffServCountActEntry (p.35):  The last sentence of the
    description seems too weak.  If an action entry points
    to this table, hasn't the entry it points to *got* to
    be here?

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.

     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?

    The net is, I think you need to define a separate
    discontinuity indicator in diffServCountActTable to
    report discontinuities in these counters.

19. diffServCountActStatus (p.37):  What does a RowStatus
    object accomplish if it's the only writeable object in
    the table?  Rather than a RowStatus here, I think you
    need to describe the "magic" that causes a row of this
    table to come into existence as soon as there is an
    action entry to point to it.

20. diffServAbsoluteDropAction (p.37):  As noted earlier,
    this object can't accomplish what you want it to.  So
    it should just be removed.

21. diffServAlgDropQThreshold (p.40):  This definition
    should have a UNITS clause.

22. diffServAlgDropSpecific (p.40):  Why isn't this object
    defined as a RowPointer, since you've already said
    what the row index will be?

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.

Sorry about the volume of these comments.  But if you hadn't
gotten them from me, I'm sure you would have gotten most of
them from Bert's MIB reviewer a few weeks from now.  I expect
to send in some comments on the Conceptual Model by the end
of this week.

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: Andrew Smith <[email-masked]>
Date: Tue, 30 May 2000 14:37:30 -0700

Bob,

Thanks for your thorough review. Please see below. In general these are
nearly all MIB style/syntax/interpretation issues (except for 21 which is
Diffserv). Please see suggested resolutions below. We'd also appreciate
anyone's opinions on any of the other listed open issues.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, May 30, 2000 11:09 AM
> To: [email-masked]
> Subject: [Diffserv] Comments on the -03 draft of the Diffserv MIB
> 
> 
> 
> 

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 :-)

>    Which is it supposed to be?

OID pointing to the table. Indexing is implicit since the table has same
indices as diffServMeterTable. This is simpler to implement and use than a
more generic RowPointer. Will fix the descriptive text.

>    in the MIB isn't right either.

Will fix the description here to say:

"2.4.3.  Absolute Drop Action

This action just silently discards all traffic presented to it, without
counting it. This action has no additional parameters and so is represented
only as a diffServActionSpecific pointing to diffServAbsoluteDropAction
without any specific parameters."

>    that's coming into the classifier.

Will clarify.

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

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

Will clarify this in the MIB draft.

>    UNITS="bits" to the definition.

Sure. I guess it doesn't hurt to add it.

>    element other than a classifier feeds traffic to a

OK.

>    necessary, and then passed out of the outermost TCB for

Yes.

>     than an Object Identifier?

I don't think it needs to be that flexible - see item 2 above.

>     equivalent to a multi-rate meter."  You need to clarify

Thank you - that's a leftover from the previous formulation.

>     description on p.30 -- the text just quits in the middle

Hmm ... don't know what happened there. Thanks.

>     got lost in the table's description.)  

Yes.

> Have you thought

No. That ought to have been listed as an open issue, similar to (16), (18)
and (19). I agree with you in principal but you do have to handle the case
where it is a different sort of meter than TB and where the columns of
diffServTBMeterEntry are not meaningful (it is debatable whether they even
ought to exist or not in this case). One possible solution would be to have
a read-write variable that just selected valid/invalid but I'd rather this
were automatically controlled by the base table i.e.  diffServTBMeterValid =
(diffServMeterSpecific == diffServTBMeterTable). diffServMeterStatus would
probably be the wrong think to ride on.

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

> 14. diffServActionStatus (p.33):  Typo in the description:

OK.
 
>     entry needs to point at it?

Yes. Seems simpler than the alternatives (it's not like an agent ever need
store anything here - it's just a list of OIDs to point to).

>     the value -1 is not allowed for this object.

OK.

>     to this table, hasn't the entry it points to *got* to

It's deliberately weak. I think what you are saying is that  we must mandate
that a pointed-to entry can not be deleted until all references to it have
first been deleted. We could do that if people think it necessary - it's
harder to implement though. Whenever we use RowPointer in a MIB, a manager
has to handle the case of dangling pointers reported by the agent. It's a
lot easier though just to define the required semantics if there is a
dangling pointer.

>         I don't think you can come along later and add to

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.

>         ifCounterDiscontinuityTime tracks?

Can you be more specific? Do you just mean whenever a diffServCountActStatus
changes?

>     report discontinuities in these counters.

Possibly - need examples of what scenarios.

>     action entry to point to it.

This was open issue 16. Either of the solutions I mentioned in the draft
could be applied - further opinions are sought.

>     it should just be removed.

See earlier.

>     should have a UNITS clause.

Any suggestions? Bytes? Bits? Packets? Cells?

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

>     another discontinuity indicator is needed for these

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? 

BTW, there is a need, I think, for a "diffserv capabilities" table so it
could go in there maybe.

> to send in some comments on the Conceptual Model by the end

No problem. We needed some fresh reviewing talent, having been immersed in
this stuff for so long.

> Bob

Andrew

****************************************************************
Andrew Smith                              tel: +1 (408) 579-2821
Extreme Networks                          fax: +1 (408) 579-3000
3585 Monroe St.                   http://www.extremenetworks.com
Santa Clara CA 95051-1450        em:  [email-masked]
****************************************************************