Subject: RE: [Diffserv] RE: DEFVAL in dsmonAggGroupIndex - SMIC error

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 5 Nov 2001 11:49:43 +0200

Andy,

Please allow me to comment on some of your concerns.

I agree that duplication is a bad thing in principle. However, one
cannot ignore the fact that remote monitoring probes are being deployed
and used quite extensively, and defining specific MIBs for these probes
helps in extending their functionality and creating the tools for
monitoring a DiffServ enabled network. MIBs belonging to the RMON family
complement the MIBs runing in the devices themselves. The obvious
example is that the RMON and RMON-2 MIBs from RMON probes complement
from a network operator point of view the information that can be
obtained by looking at MIB-II, Bridge MIB and IP forwarding MIBs in the
bridges and routers deployed in the network. You cannot expect such a
probe to implement much of the DiffServ MIB for the simple reason that
they are not DiffServ enabled routers.

I agree with you that many of the DS-MON MIB implementation will end by
being implemented in switches and routers. Such implementations are
already available. This is exactly where the optimizations that the
DS-MON MIB tried to propose can help. Embedded devices tend to be
sometimes scarce in resources, and doing monitoring is not their primary
job. The concept of aggregation that bothers you in the example that you
provided is such a case, as it helps to focus on the case where only
some of the DSCP values are relevant for the specific network, and
avoids wasting resources (like tables of counters mostly filled with
zeroes) that cost on the device and on the wire. Optimization for
monitoring purposes is different from what the 'data path' concept, and
a network operator application may need to focus on different sources. 

I think that the problem spaces of providing data for the protocol
management, and monitoring the network (by stand-alone or embedded
probes) are complementary sets of tools, which deserve each their
separate definition and MIB interface.

Regards,

Dan

> -----Original Message-----
> From: Andrew Smith [mailto:[email-masked]]
> Sent: Friday, November 02, 2001 11:12 PM
> To: [email-masked]
> Cc: Diffserv
> Subject: [Diffserv] RE: DEFVAL in dsmonAggGroupIndex - SMIC error
> 
> 
> I've (still) got serious problems with this MIB, its 
> relationship to the
> DiffServ MIB and the "aggregation group" concept. Haven't 
> spoken up recently
> because I thought others would taken care of it by now.
> 
> 1. You're duplicating functionality from the DiffServ MIB 
> here. If that's
> fine with IESG then OK but it seems like a bad idea to me. People have
> argued on the RMON list before that DSMON is meant for 
> probes, not switches
> but I believe a large proportion of DSMON implementations 
> will end up inside
> switches with consequent waste of resources. I do not think 
> there is a good
> case to be made for optimising this MIB for the "standalone 
> probe" case.
> 
> 2. You're inventing a new grouping concept with its own 
> number space for
> something that the DiffServ conceptual management model, MIB 
> and PIB do
> using their "data path" concept and which they have their own 
> numberspace
> for. You should re-use that concept or else persuade DiffServ 
> to use your
> concept but there is no excuse for having duplicate 
> mechanisms in MIBs that
> are being developed/published at roughly the same time by 
> IETF (is this due
> to OPS and TSV ADs not talking to each other enough? No 
> apologies for adding
> Diffserv WG to this message).
> 
> 3. You're overloading your dsmonAggGroupIndex numberspace with the
> "convenience functionality" of letting the group index equal the DSCP.
> There's no need for this and it cannot be useful unless you have some
> mandated behaviour that relies on this 1:1 mapping e.g. a 
> default setting
> for the table on power-up or initial state. Leaving it as an 
> option (see
> "SHOULD" below) makes it useless in a multi-vendor world.
> 
> Specifics:
> 
> 4. "dsmonAggGroupIndex OBJECT-TYPE
>     SYNTAX      DsmonAggGroupIndex
>     MAX-ACCESS  read-write
>     STATUS      current
>     DESCRIPTION
>             "The aggregation group which contains this DSCP 
> value.  Upon
>             creation of a new sub-tree (set of 64 entries 
> with the same
>             dsmonAggControlIndex value) in this table, the 
> agent SHOULD
>             initialize all related instances of this object 
> to the value
>             zero.
> 
>             This object MUST NOT be modified if the
>             dsmonAggControlLocked object is equal to 'true'."
>     DEFVAL { 0 }"
> 
> a)  This description does not make sense (to me): 
> dsmonAggControlIndex does
> not appear in this table so how is creation of a new sub-tree 
> related to
> entries in this table? Please clarify this wording. Or is this a typo?
> b) What's the point of the "SHOULD" directive here?
> c) Define "related instances" more precisely.
> d) You can't say that a read-write variable "MUST NOT" be modified (by
> whom?) - you can define that if you try to do so then the 
> operation will
> pass/fail etc. but you can't use a MIB to enforce what a 
> manager can/cannot
> attempt (you might as well add "please" :-)).
> e) I don't think you can rely on "0" as a special value of 
> DSCP here - use
> something like -1 if you really need to use a DEFVAL.
> 
> That's all on this particular issue, I guess I ought to read 
> the rest of the
> MIB now ...
> 
> Andrew Smith
> 
> 
> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf
> Of Andy Bierman
> Sent: Friday, November 02, 2001 8:31 AM
> To: Harrie Hazewinkel
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: DEFVAL in dsmonAggGroupIndex - SMIC error
> 
> 
> At 06:33 PM 11/1/2001 -0800, Harrie Hazewinkel wrote:
> 
> 
> 
> Now that I looked at this some more, I think the SMIC is wrong.
> This DEFVAL should not be a syntax error.
> 
> The dsmonAggGroupIndex object itself is read-write object
> and not an INDEX in the table its defined in.  The DEFVAL clause
> indicates that the initial aggGroup value an agent should set for each
> DSCP mapping. All DSCPs in the same group -- perfectly valid concept,
> perfectly valid SMIv2 syntax.
> 
> However, the dsmonAggGroupIndex object is also declared as one of the
> INDEX components in the dsmonAggGroupEntry. SMIC is complaining about
> the DEFVAL that is only meant to apply to original OBJECT-TYPE macro,
> not a DEFVAL for the INDEX -- that doesn't even make sense.
> 
> >--On Thursday, November 1, 2001 7:40 AM -0800 Andy Bierman
> ><[email-masked]> wrote:
> >
> >>At 01:39 PM 11/1/2001 +0100, Wijnen, Bert (Bert) wrote:
> >>>OK, 2 issues basically came out after your approval.
> >>>
> >>>- SMICng complains about having a DEFVAL for dsmonAggGroupIndex
> >>>   since this object is used as an index object as well. Andy
> >>>   did put it in since you insisted. I am discussing the matter
> >>>   with the SMIv2 doc editors
> >>>- Frank Strauss (I asked him to check to see if his compiler
> >>>   would also complain about that indexing thing, which it did not,
> >>>   but then Juergen has now added a lvl 4 warning about it).
> >>>   Frank brought out that the OID could become too long based on
> >>>   some index definitions. So Andy has posted a new rev to address
> >>>   that
> 
>  >....
> 
> 
> >>The rules are too strict!
> >
> >I agree here. When a default value is written in a description
> >it seems to be allowe, but when a DEFVAL is used it is
> >not because of compilers complain. That sounds
> >contradictionary to me. The DEFVAL-cluase is
> >(IMHO) there to support more formally the
> >semantics of the object, but it may neither
> >create a conflict with the semantics provided in
> >the description-clause.
> >
> >
> >Maybe far fetched, but I can envision such a scenario.
> >Someone can create some object in X-MIB with
> >a read-create ACCESS and a DEFVAL seems appropriate.
> >Later someone else in Y-MIB uses that object in an
> >index, because it wants to extend information for
> >that perticular object only.
> >The only option (to keep compilers happy) will then
> >be create/duplicate the object and provide the same
> >semantics without DEFVAL.
> >
> >Hmm....
> 
> Someone already did that -- in DSMON-MIB !
> 
> 
> 
> 
> >My thoughts about it,
> >
> >
> >Harrie Hazewinkel
> 
> Andy
> 
> 
> 
> 
> _______________________________________________
> diffserv mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/diffserv
> Archive: 
> http://www2.ietf.org/mail-archive/working-groups/diffserv/curr
ent/maillist.html

_______________________________________________
diffserv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 05 Nov 2001 13:42:03 +0100

Dan,

"Romascanu, Dan (Dan)" wrote:
...
> separate definition and MIB interface.

That is why the diffserv MIB has two conformance levels, one for
read-only (i.e. monitoring) and one for read-write (i.e. control).
A priori, the diffserv MIB is what you need for complete monitoring
of a diffserv router. It certainly doesn't seem appropriate to
construct a *different* virtual model of such a router for an RMON
MIB; surely it should be a strict subset of the same model?
Otherwise life will become very confusing for operational staff.

The diffserv MIB deconstructs the path for each traffic aggregate
and maintains some counters deep down in the deconstructed elements
of the path. You are going the opposite way in the DSMON MIB - you
are synthesizing something that doesn't exist (the aggregation group),
which may or may not map to the paths defined in the diffserv MIB.
In practice I think that will force implementors to do extra work,
and cost extra overhead. It would indeed seem more logical for
the DSMON MIB to collect up the counters already defined by the
diffserv MIB, but that means a different approach to aggregating
the counters.

  Brian

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 
On assignment at the IBM Zurich Laboratory, Switzerland
Board Chairman, Internet Society http://www.isoc.org

---

From: Andy Bierman <[email-masked]>
Date: Mon, 05 Nov 2001 07:45:02 -0800

>Otherwise life will become very confusing for operational staff.

I think you might have missed Dan's point.
RMON focuses on aggregating statistics from the network user POV.
Simple, high-level statistics of the nature "What is the traffic mix on
network X?"  RMON does not focus at all on the performance or
health of individual forwarding elements within the network.
Although RMON can run inside switches, it is designed to run
in many environments, and it provides an intentionally simplified
control interface to allow such implementations.

In DSMON, the dsmonAggControl group allows an administrator
to configure which DSCPs to lump together for counting purposes
only.  This allows for implementations with hardware-based counters
to 'share' those counters.  It also can reduce the number of MIB
objects an application has to retrieve -- the agent can do the
counter roll-up for the application if so configured.  RMON applications
are not intended for use as DS forwarding device fault and performance
monitoring tools.

>diffserv MIB, but that means a different approach to aggregating

The DIFFSERV-MIB I-D is 127 pages.
The DSMON-MIB I-D is 128 pages.
For those of us on the list who have not memorized every MIB object
in both MIBs, can somebody please list these DIFFSERV-MIB
objects and the DSMON-MIB objects that overlap them?

Andy

> http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html
>
>--
>http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html