Subject: [Diffserv] Adding stuff to Diffserv MIB?

From: Andrew Smith <[email-masked]>
Date: Mon, 12 Jun 2000 13:47:14 -0700

Since we're on that topic, one other thing that ought to be added to the
Diffserv MIB is some sort of reporting of device "capabilities" (along the
lines of some of the things in RMON MIBs, for example). This is one of the
areas that makes a MIB as generic as this one far more useful to a manager.
I won't push this if nobody else thinks it a worthwhile addition - I guess
it could be a follow-on piece of work but, in my opinion, it gets close to
being necessary for use of the MIB for configuration.

Andrew

> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Monday, June 12, 2000 12:59 PM
> To: Yasusi Kanada
> Cc: Ricardo Cadime; [email-masked]
> Subject: Re: [Diffserv] draft-kanada-diffserv-qospifmib-00.txt
> 
> 
> Kanada-san,
> 
> As has been mentioned before, it's much easier to add things 
> to a MIB than
> to remove them later. So the plan is for the MIB to contain 
> the minimum
> agreed features initially. At this stage I don't see much 
> support in the
> WG for adding items to the standard. But of course you can make your
> proposals when we conduct the WG last call.
> 
>   Brian Carpenter
>   diffserv co-chair
> 
> Yasusi Kanada wrote:
> > 
> > On Mon, Jun 12, 2000, Ricardo Cadime <[email-masked]> wrote:
> > >The draft draft-kanada-diffserv-qospifmib-00.txt has 
> expired in April.
> > >There are a new vesion somewhere?
> > >
> > >Should its functionality be replaced by Diffserv-MIB or other??
> > 
> > There is no updated version because Kathy said this MIB should be
> > merged into Diffserv MIB, and I agreed.  The original version is
> > still available from
> > 
> http://www.kanadas.com/activenet/draft-kanada-diffserv-qospifm
> ib-00.txt
> > 
> > Kwok Chan and I made efforts to "merge the MIBs", but some fruits of
> > our efforts has gone in the recent update (-03) of the MIB draft.
> > I think they should return.
> > 
> > ---
> > Yasusi Kanada, Ph.D,  WWW: http://www.kanadas.com/
> > Email: [email-masked] (day), [email-masked] (night)
> > Network Systems Research Dept., Central Research Lab., Hitachi Ltd.
> > ---
> > 
> > _______________________________________________
> > diffserv mailing list
> > [email-masked]
> > http://www1.ietf.org/mailman/listinfo/diffserv
> > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
> 
> 
> 
> _______________________________________________
> diffserv mailing list
> [email-masked]
> http://www1.ietf.org/mailman/listinfo/diffserv
> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
> 

_______________________________________________
diffserv mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 12 Jun 2000 16:58:24 -0500

Andrew,

Wouldn't that be something that the SNMPCONF MIB would cover?

   Brian

---

From: Fred Baker <[email-masked]>
Date: Mon, 12 Jun 2000 17:23:52 -0700

>Wouldn't that be something that the SNMPCONF MIB would cover?

I sure hope not. The SNMPCONF MIB should allow them to determine what roles 
are there and download SNMP objects for roles, period. If it is not only 
generic but has specific stuff to extend specific MIBs ("this interface has 
three queues, use them how you will", "this interface is capable of having 
two IP subnets configured on it"), it will be a huge MIB.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 12 Jun 2000 20:58:20 -0500

> two IP subnets configured on it"), it will be a huge MIB.

OK, understood, thanks.

  Brian

---

From: Jon Saperia <[email-masked]>
Date: Tue, 13 Jun 2000 07:12:50 -0400

>> two IP subnets configured on it"), it will be a huge MIB.
Fred is correct, here is a bit of brief detail - I do not want to clutter
the email list:

There is a fairly small Policy MIB Module - what was called the SNMPCONF MIB
above:

- As Fred indicated, it is generic and is for downloading roles.
- It contains a table of capabilities so managers know what type of policies
the managed device supports.
- It has as a Policy Table with a list of policies and status and pointers
to calendar information for those policies that run on a schedule.

In the case of a complex technology like DIFFSERV, the Policy MIB Module
Points to what we call mechanism specific MIB Modules that contain the
details of the technology. These are not instance specific modules, but
contain 'default' values for the instances that match the roles for a
particular policy. This means that if there were 100 interfaces with 10
parameters each for a policy the manager would only send have to send the
'default value' for the 10 parameters and the rule for the selection of the
100 interfaces. We are working on one such module for DIFFSERV as a
practical example to contain such defaults. It points to the MIB Module you
folks are already defining which is for information that is instance
specific. 

Vendor specific extensions work just like they do for any other SNMP MIB
Module. If a vendor had private extensions for their system that had 10
unique parameters for the FOO queuing method for example, one would expect
those to be in the vendors private module as is the norm. The vendor should
also create what we call an implementation specific set of extensions to the
standard mechanisms defined in the example I cited above so they can be
under policy control as well.

Hope this was not so brief that it was confusing. Details of what we are
doing are on the SNMPCONF WG page.

/jon