Subject: [Diffserv] DiffServ MIB slides/issues

From: Andrew Smith <[email-masked]>
Date: Mon, 27 Mar 2000 15:17:43 -0800

Here is a transcript of my slides on the DiffServ MIB from yesterday's
meeting (I'll try to post the diagram I showed sometime soon).

Andrew Smith

===========================================

Open issues - general

Breakdown of objects into: core, optional and "no way"?
- we need to make some judgements on what is in each category
- should err on the side of "leave it out" - we should have the intersection
of implementations, not the union.
- we need to agree on conformance statements
we need to show how to extend the basic core in enterprise MIBs

Closer alignment with DiffServ Conceptual Model 
- terminology
- MIB has more detail on queues and droppers than Model: this is backwards!
Move a lot of sect. 3 explanation -> Model draft.
- Model describes "dropper" and "discarder" actions separately and has
discarder as part of queueing; MIB lumps them together. PICK ONE.
- Syntax and format fixes

Open MIB issues

0. Terminology consistency with Model (which is right?): 
"Algorithmic Dropper" <- "Discarder"
"Counter" <- "Monitor"

1. Cascaded token-buckets is not equivalent to multi-rate token-bucket: do
we need to fix this by allowing a multi-rate TB in the MIB? Or, by defining
cascaded buckets to mean "multi-rate". Discuss.

2. Markers: model only describes DSCP-markers: do we need to be able to
extend this to other sorts (e.g. 802.1p), even if we do not represent them
in this MIB today? (yes)
- Probably just needs words of explanation, not MIB syntax at this point.

3. Counters: should specific blocks include their own or is a "monitor
action", as described in the Model, sufficient to count all paths through a
device? (yes)
- We do not have per-queue counters: they are derivable from "action" ones.
- If you want per-classifier counters they need to result in distinct
actions.

4. Queue Sets: are these generally applicable? (yes)
- should be described in Model if so.
- the example in MIB 3.5 is hard to follow: we should describe this example
in Model and then show how it maps to MIB in the MIB draft 3.5.

5. Do we need scheduling units of "packets"? Should we use "kbps" or just
"bps" for rates? (no - suggest kbps)

6. Are "absolute" rates sufficient or should we include "relative to line
speed" ones as well? (yes)

7. Scheduler weights vs. rates vs. priorities: this is confusing - suggest
we stick to rates and priorities (see Model draft 7.1.2)

8. Queue Measure table: 
- This allows for RIO - multiple averaging functions for the same queue: is
this needed? (no)
- mixes config with status objects - split these? (yes)
- do we need floating-point representation for "weight"? (no)
- do we need MIB visibility for average queue depth? (no)
- do we need MIB-configurable averaging functions (sample weight/interval)?
(maybe just "sample weight")

9. Counter compliance: paste text from IF-MIB re line-speeds.
- Do you still have to do the low-speed counters for fast interfaces? (yes)

10. Meters: are these mandatory for compliance? (no)

11. Discussion material: move most of this to Model draft e.g. most of 3.1,
3.3, "Dropper/discarder" part of 3.4, nearly all of 3.5. Just leave the "how
does the MIB map from the Model" parts in the MIB draft, no general
discussion. (yes)

12. Monitors: merge in 32-bit and 64-bit counters - conformance statements
will sort out which ones must be implemented.
- Should be consistent with interface MIB

13. Droppers: we currently have a "dropper" table that represents all of:
dropAlways, randomDrop, tailDrop with just some parameters valid for the
simpler ones.
- A simpler representation would be to define specific dropper tables for
each type (e.g. a single OID to point at for dropAlways since it is always
the last action in a chain)
- but this would be more (simpler) MIB objects

=================end=================

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