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

From: Andy Bierman <[email-masked]>
Date: Tue, 06 Nov 2001 10:48:02 -0800

At 02:46 PM 11/6/2001 +0200, Romascanu, Dan (Dan) wrote:
>So, would the following DS-MON MIB changes be satisfactory?
>
>- Rename the *DS-MON aggregation* to something else to avoid confusion
>with the *diffserv aggregates*
>- Support the *diffserv aggregates*, maybe by mapping the rename *DS-MON
>aggregates* into the *diffserv aggregates*
>
>If the answer is yes, we still need to hear the opinion of the DS-MON
>MIB author. I am just looking at it from the perspective of the
>implementation of DS-MON together with other RMON family protocols.

I understand edit #1, but not #2.
Any clarifications are fine with me.
I will spin the draft before the I-D cutoff, and rename things to
make it clear the agent is aggregating counters, totally unrelated to
the concept of a diffserv aggregate.

>Regards,
>Dan

Andy

> > -----Original Message-----
> > From: Brian E Carpenter [mailto:[email-masked]]
> > Sent: Tuesday, November 06, 2001 2:16 PM
> > To: Romascanu, Dan (Dan)
> > Cc: [email-masked]; Harrie Hazewinkel;
> > [email-masked]; Diffserv
> > Subject: Re: [Diffserv] RE: Differences between DSMON-MIB and
> > DIFFSERV-MIB
> >
> >
> > snipping...
> >
> > "Romascanu, Dan (Dan)" wrote:
> > >
> > ...
> > > I would like to point to two separate issues here:
> > >
> > > - It seems to me that there might be cases when the
> > aggregation concept
> > > is two little or two much from a monitoring tool point of
> > view. It might
> > > be too little if the aggregation applies to a specific policy
> > > administrative domain, and packets that are monitored at a certain
> > > monitoring point are the result of them originating from
> > such different
> > > domains. It may be two much because in some real life situations an
> > > operator may need (or may be forced to use because of the
> > limitations of
> > > his monitoring probe) a coarser set of code points values
> > (like default
> > > and 'all-but-default')
> >
> > But the point is that this form of aggregation is pretty much
> > orthogonal to the diffserv architecture. It's meaningless, in terms
> > of diffserv, to add together the statistics of separate traffic
> > aggregates (yes, the word "aggregate" already has a very specific
> > meaning in diffserv, and it is different from the usage in DSMON.)
> > The only case where it might make sense is for PHB groups.
> > The DSMON "aggregates" *in any case* need to be renamed, to avoid
> > confusion with diffserv traffic aggregates.
> >
> > Frankly I don't see the point. Nobody expects to deploy real diffserv
> > networks with more than a few traffic classes (i.e. DSCPs) active.
> > In any case, the theoretical maximum (64) is a small number. Why not
> > just monitor DSCPs? (I agree that an "everything else" bucket
> > is useful,
> > at least for presentation.)
> >
> > > - The other issue is that DiffServ MIB is designed to run
> > in diffserv
> > > routers. It makes assumptions about the agent understanding how such
> > > routers work, and you need this understanding even in the read-only
> > > mode. One cannot make such assumptions about all RMON probes.
> >
> > Correct, that is a valid point: a pure probe can't be expected to
> > have full knowledge of the diffserv configuration. Equally, it
> > can't measure everything, for example it can't count packet drops,
> > which is one of the basic metrics of a diffserv traffic aggregate.
> > But why can't it use the same concept of traffic aggregates as
> > the DSMIB, and count a subset of the same things?
> >
> > ...
> > > >
> > >
> > > yes, there is a 'fundamental' issue here. The issue is in
> > my opinion the
> > > difference between a MIB focused on device management, and a MIB
> > > focusing on network level monitoring. According to my operational
> > > experience, these two views are complementary, and are both needed.
> >
> > No disagreement there. But they can be complementary without
> > being inconsistent.
> >
> >    Brian
> >
>
>_______________________________________________
>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

_______________________________________________
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: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 8 Nov 2001 10:01:12 +0200

Andy,

A network operator using DS-MON will probably use it in the context of
the other RMON. This will allow to provide views that correspond to any
combination of filters that a classifier may provide. The difference is
that the information is based upon the information 'on-the-wire' and not
on the specific implementation of a classifier in the device - which is
local and may be limited to the capabilities of the specific device.

Regards,

Dan
> I'm not suggesting that the instances of data paths in the 
> routers need to
> correspond to the instances datapaths in the probes. I am 
> suggesting that
> the same set of "classifier elements" could be used in both. 
> They may well
> feed into a different set of "counter elements": as Andy has 
> pointed out,
> you may want to count in more, or less, detail in the probe 
> than in the
> router, but it is likely that you'll want to classify in the 
> same way. DSMON
> MIB currently defines its own MIB objects for classifiers, 
> which is silly,
> and these are on DSCP only which is likely to be too limiting 
> for anywhere
> except at the core of the network - the Diffserv architecture 
> admits that
> the edges of a Diffserv domain are likely to be defined by multi-field
> classifiers so you are seriously limiting the use of DSMON if 
> you do not
> acknowledge that fact (is this another result of attempting 
> this work in a
> different WG? Sorry, broken record ....).
>>