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

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 6 Nov 2001 11:58:45 +0200

Hi Andy,

,
> 
> 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 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')
- 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.

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

Actually you are making a point for the need of a DS-MON MIB. However,
you miss the fact that the DS-MON MIB requires support for many objects
whose purpose is to determine the functionality and health status of the
router, queues, etc. which are not necessarily of interest for a network
monitoring tool. When RMON showed up it cleaned out from the Ethernet
MIB some objects which were considered not relevant for the monitoring
of the network, but were otherwise very useful to debug the status of an
Ethernet interface.

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

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. 

Regards,

Dan

> Andrew

_______________________________________________
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

_______________________________________________
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: Tue, 06 Nov 2001 13:16:17 +0100

snipping...

"Romascanu, Dan (Dan)" wrote:
...
> his monitoring probe) a coarser set of code points values (like 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.)

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

...
> experience, these two views are complementary, and are both needed.

No disagreement there. But they can be complementary without
being inconsistent.

   Brian

---

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

>confusion with diffserv traffic aggregates.

I agree the aggProfile groupings are only as meaningful as the
administrator makes them. Whether the DSCP values grouped
together should be, in terms of the actual DIFFSERV config,
is totally unknown to the probe. DSCPs are just more numbers to a probe.

>at least for presentation.)

Actually, this is how I wanted the MIB to be, and how I originally wrote it.
I would love it if aggregation groups were tossed and a simple
Dscp INDEX was used instead. This is probably how all SW implementations
will work anyway.

I believe it was Andrew who originally said we needed to aggregate DSCP
counters and other RMONMIB WG members agreed.

An existence proof can be found with VLAN counters in switches,
especially for 'backplane' counters.

Let's say you pick an arbitrary small number of VLANs (or DSCPs) that
can actually be counted at line rate at the same time, because every counter
cost HW real estate (and therefore money).

It's relatively easy for an administrator to figure out which VLANs (or DSCPs)
need attention when debugging network problems, and direct the switch
to collect statistics on just those values.

>the DSMIB, and count a subset of the same things?

RMON probes just listen on interfaces, many times attached to a hub
or switch 'SPAN' (or mirror) port. They cannot tell if another device
somewhere on the network dropped a packet. An administrator needs
to get drop counts from the device that did the dropping.

>No disagreement there. But they can be complementary without

We don't really agree they are inconsistent.  I don't think a model of the
internal data path of a forwarding device is inconsistent with the remote
monitoring model for counter aggregation.

For the sake of argument, what changes to the DSMON-MIB do you think
are needed to be complementary and consistent?

>    Brian

Andy