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

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 8 Nov 2001 09:23:00 +0200

Andy,

You probably need to explain me "MIB-wise" how the DS-MON MIB in a probe
which is not a DiffServ router could use the data paths in the DiffServ
MIB in case 1. I tried to go through this exercise, and could not solve
the issue of one probe imports the data path information from the
different DiffServ routers. 

This may be actually simpler for case 2, but here we differ because I do
not think that the information provided by the DiffServ MIB is enough.
I think that operators need the network DS-MON view, because it connects
the DiffServ information on the wire to the network and application
monitoring data, and aggregates it network-wise. This is different from
the local information that can be obtained from each of the DiffServ
routers.

Regards,

Dan

> -----Original Message-----
> From: Andrew Smith [mailto:[email-masked]]
> Sent: Thursday, November 08, 2001 3:54 AM
> To: Romascanu, Dan (Dan)
> Cc: [email-masked]; Diffserv
> Subject: RE: [Diffserv] RE: Differences between DSMON-MIB and 
> DIFFSERV-MIB
> 
> 
> Dan,
> 
> That (#2) was roughly what I had in mind also. To take the two
> implementation cases separately:
> 
> 1. Probe implemented standalone: no reason why the probe 
> could not set up
> "datapaths" for the sole purpose of monitoring traffic. The 
> "front-end" of
> the DSMON MIB could very well use the current Diffserv MIB. 
> There is  the
> benefit of commonality of setup by managers at the expense of 
> additional
> complexity when compared to a dedicated MIB (that's nearly 
> always true). So
> I believe that your concern about deciding on a mapping 
> should be easily
> dealt with.
> 
> 2. Probe implemented inside Diffserv switch/router: front-end 
> of the DSMON
> MIB would beenfit from using the same MIB as the 
> switch/router functions.
> Reduced complexity when compared to an additional 
> DSMON-specific frint-end;
> same benefits as #1.
> 
> Based on this analysis, I think the RMON WG should look 
> seriously at what
> products its members intend to build and evaluate the 
> tradeoffs above. I'm
> not intending to build any products using this MIB so I don't 
> have a leg to
> stand on here .... at this point I'll shut up and let others 
> argue this
> further if they want to.
> 
> Andrew Smith
> 
> 
> 
> -----Original Message-----
> From: Romascanu, Dan (Dan) [mailto:[email-masked]]
> Sent: Tuesday, November 06, 2001 11:25 AM
> To: Andy Bierman
> Cc: Brian E Carpenter; [email-masked]; Harrie Hazewinkel;
> [email-masked]; Diffserv
> Subject: RE: [Diffserv] RE: Differences between DSMON-MIB and
> DIFFSERV-MIB
> 
> 
> 
> > >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.
> >
> What I originally had in mind at #2 was somehow importing the path
> concept from the DiffServ MIB and providing a mapping table. I was
> probably superficial, a more attentive analysis seems to show 
> that there
> is no one-to-one relations, at least when different devices run the
> probe and the router, and this connection needs to be left for the
> application. I would say that Andy's proposed edits at #1 are probably
> enough on what the DS-MON MIB is concerned.
> 
> 
> Regards.
> 
> Dan
> 
> 
> 

_______________________________________________
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: Thu, 8 Nov 2001 00:12:39 -0800

Dan,

Not sure from where you get the "imports the data path information from the
different DiffServ routers" idea: I'm just suggesting that a single
management application is likely to be the source for both configuration
info (for routers) and monitoring of that same configuration (by DSMON
probes, standalone or embedded).

I'm not suggesting that the instances of datapaths 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 ....).

Andrew

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:[email-masked]]
Sent: Wednesday, November 07, 2001 11:23 PM
To: Andrew Smith
Cc: [email-masked]; Diffserv
Subject: RE: [Diffserv] RE: Differences between DSMON-MIB and
DIFFSERV-MIB

Andy,

Regards,

Dan