Andrew Smith March, 2000

1. DiffServ MIB - open issues and proposed changeshttp://www.ietf.org/internet-drafts/draft-ietf-diffserv-mib-02.txt Andrew Smith March, 2000

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

3. Open MIB issues (1) 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. Open MIB issues (2) 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)

5. Open MIB issues (3) 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)

6. Open MIB issues (4) 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