Subject: [Diffserv] Differences between DSMON-MIB and DIFFSERV-MIB

From: Harrie Hazewinkel <[email-masked]>
Date: Mon, 05 Nov 2001 22:28:45 -0800

Hi,

(Note I changed the subject)

--On Monday, November 5, 2001 1:42 PM +0100 Brian E Carpenter 
<[email-masked]> wrote:

> Dan,
>
> "Romascanu, Dan (Dan)" wrote:
> ...
>> 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.
>
> 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.

IMHO, the two conformance levels are there to have a different
SNMP access which in perticular reflect the approach the
system gets configured.
The 'full compliance' makes it that a diffserv capable router
can be monitored and configured via SNMP. The 'read-only
compliance' is mainly to support toses diffserv capable routers
who do not do configuration via SNMP. It can indeed be used
for monitoring, but the system can be configured in other ways
than SNMP.

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

The virtual model mainly creates the concept of the datapath and
its elements. Those datapaths and elements cause in a diffserv
capable router traffic treatment. Different treatment can be
given based on the way the traffic is filtered and goes through
the datapath elements. Traffic behavior can be altered/shaped
or just treated differently.

RMON is just a probe sitting on the sideline looking at the
traffic. It does not do any traffic treatment or shaping.
Traffic streams are NOT altered.

> Otherwise life will become very confusing for operational staff.

This is maybe already caused by the existance of RMON. Like D.Romascanu
said; "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."

I beleive the models are different where DSMON-MIB is monitoring
a particular traffic pattern and the DIFFSERV-MIB is monitoring a
perticular datapath configuration (and if 'full compliant' also
configuration itself.

A big difference is the end of a datapath configuration
is the router core. In DSMON-MIB monitoring is no router
core. Also the DIFFSERV-MIB has for each count action
a next datapath element which is not in the DSMON-MIB.

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

Indeed, this is a difference.

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

I am not sure if I follow it completely; correct me if I am wrong.
What you are saying is that the counter which are combined with a
particular DSCP counting from as well the DSMON-MIB and the DIFFSERV-MIB
can be the same?? But where does the traffic gets delivered in case
of an DSMON situation with the DIFFSERV-MIB??
The value zeroDotZero for a next pointer does not seem to be appropriate
if you just have a normal RMON probe.

I beleive this will force also extra work to configure the system.
Maybe one will not have the same DSMON monitoring (filtering) as
one has traffic treatment.

That would mean:

A traffic filter that feeds the various counters to do traffic
monitoring. The next pointer of all the count actions need to be
the same from where a complete new set of traffic filters is
created in order to have a traffic treatment one would like to
have. Maybe a farfetched idea, but still. Looks possible to me.

However, when the DSMON-MIB is just in a probe, I am not sure
how to use the filters and more precise the count actions of the
DIFFSERV-MIB need to be set up than. What is the next pointer
of the count actions?? These count actions (datapath elements)
are not in the path of the traffic and neither can the traffic
be delivered at the router core as the DIFFSERV-MIB does.

Maybe the case where an RMON probe in the DIFFSERV capable router resides
is a border case. But this is (I beleive) not to be expected the
case always.

Hope this all makes sense, (if not say so)

Harrie

>
>   Brian
>
>> > -----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/mailli
>> st.html
>
> --
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> 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
>
>
> _______________________________________________
> RMONMIB mailing list
> [email-masked]
> http://www1.ietf.org/mailman/listinfo/rmonmib
>
>

_______________________________________________
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: "Andrew Smith" <[email-masked]>
Date: Tue, 6 Nov 2001 01:38:31 -0800

Harrie,

The basic issue here is whether DSMON should invent a new concept
("aggregation group") for something that does not exist in the Diffserv
architecture or in any of the drafts that discuss management of Diffserv. It
seems wrong to do so if there is already an existing concept (a "data path")
that is a candidate for performing the necessary monitoring actions. Your
message, Harrie, goes into the details of how we might or might not re-use
existing objects but I'm trying to establish the general concept first.

"Data path" is not the same as "aggregation group" (neither is "PHB"). As
currently defined in DSMON, an aggregation group can be defined to include
traffic with assorted DSCPs totally orthogonally to the Diffserv treatment
that nodes might give those DSCPs: that's great - it's as as flexible as
anyone could want. But does it bare any relationship to the things that
network managers want to see? Andy asserts that it does, I would disagree. I
would argue that the things that people will want to train their DSMON
probes on are precisely the things that are a result of the Diffserv
configuration and that the manager (or the management tools, to be precise)
should not have to convert from one model used for configuration of the
network nodes into an orthogonal model used by the monitoring probes. That's
just unnecessary work.

I'd also argue that, to turn Andy's example against him, DSMON should be to
the Diffserv MIB as RMON is to the Ethernet MIB or RMON2 is to IP MIB
statistics: xxxMON should be a tool to take MIB objects and "wrap them up"
with history samples, trending and traffic matrix mechanisms. An xxxMON
module should not go off on its own in defining new management models for
the xxx technology.

Until we can agree (or agree to disagree) on these fundamentals, there's no
point diving into the details.

Andrew

-----Original Message-----
From: Harrie Hazewinkel [mailto:[email-masked]]
Sent: Monday, November 05, 2001 10:29 PM
To: Brian E Carpenter; Romascanu, Dan (Dan)
Cc: Andrew Smith; [email-masked]; Diffserv
Subject: Differences between DSMON-MIB and DIFFSERV-MIB

Hi,

That would mean:

Harrie

---

From: "Andrew Smith" <[email-masked]>
Date: Tue, 6 Nov 2001 01:45:09 -0800

To: Harrie Hazewinkel
Cc: [email-masked]

Harrie,

Andrew

-----Original Message-----
From: Harrie Hazewinkel [mailto:[email-masked]]
Sent: Monday, November 05, 2001 10:29 PM
To: Brian E Carpenter; Romascanu, Dan (Dan)
Cc: Andrew Smith; [email-masked]; Diffserv
Subject: Differences between DSMON-MIB and DIFFSERV-MIB

Hi,

That would mean:

Harrie

---

From: Andy Bierman <[email-masked]>
Date: Tue, 06 Nov 2001 09:38:07 -0800

>existing objects but I'm trying to establish the general concept first.

What if we thought of an aggregation group as aggregating "Counters"
not "DSCPs".  That's really what it is. From an RMON probe's POV,
the DSCP value is just another observable attribute in the packet.

I don't think the data flow through a forwarding device is relevant
to RMON. An RMON probe (conceptually) is a device that
observes all packets on an interface and collects high level
statistics configured by an administrator.

>network nodes into an orthogonal model used by the monitoring probes. That's

It's up to the administrator to configure which DSCPs are interesting
to monitor, just like all the other observable packet attributes. Perhaps
you are suggesting that a DSMON probe could get this configuration
from a DS forwarding device? Which one? A probe can sit "on the wire"
between (or near) several such devices.  I agree automatic configuration
is always nice to have, but it's not required in the first release of the MIB.

>module should not go off on its own in defining new management models for

I'd argue this is exactly what DSMON does.
I took the existing RMON-2 features and extended them to
do additional classification based on DSCP value. Application
host and matrix, a TopN of protocol distribution, AL-matrix, etc.
RMON only defines ways to aggregate its own statistics.
I don't see how an administrator (as Dan pointed out, they
already understand the concept of probe-gathered vs. device-gathered
statistics) would confuse the purpose or semantic definitions in the
DSMON-MIB with those in the DIFFSERV-MIB.

>point diving into the details.

It shouldn't be that hard. You must have identified at least one to
come up with your comments in the first place.

Andy

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