[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

snmpconf Re: [Diffserv] Instance amplification in Diffserv MIB



HI,

I hope this post works. Some confusion could be created by me, since
I suddenly was not accepted as a legal post-account for the mailinglist
anymore. Sorry about that.

Jon Saperia wrote:
> 
> on 11/14/2000 5:15 PM, Andrew Smith at andrew@allegronetworks.com wrote:
> 
> > What you are arguing here is a need for some sort of "templating" capability
> > for these objects: this is something that was discussed at length in the early
> > snmpconf meetings (I wasn't at the last one so I don't know if this is still a
> > goal) and was being called "instance amplification". The problem, in brief was
> > "how do we apply a template of values for config parameters (columns) to a
> > whole collection of instances (table entries)?" and there were hopes that
> > snmpconf work would produce some sort of generic solution to this problem.
> > What you are describing here is a local solution for this problem for this
> > particular MIB, so I would ask you and Harrie to comment on whether we are
> > duplicating effort here or just moving this solution from being a snmpconf
> > work item to being a part of this diffserv MIB?

Originally, SNMPCONF was more or less trying to duplicate the managed
objects of
the DiffServ-MIB. When trying to understand the DiffServ-MIB and
speaking with
Joel in Pittsburgh, he came up with the idea of having a more
configurable
DiffServ-MIB, which ment do not use in all tables the interface index
and
interface direction index.

When I thought of what it really ment, I discovered that the
DiffServ-MIB
had a very inconsitent design.

There were 2 ways on how to built datapath. The next pointers pointed
each time
to the next functional datapath element and "the interface index and
interface direction index" connected datapath elements. I found out that
next pointer could point to any other datapath element without
considering the
"the interface index and interface direction index".

With other words "the interface index and interface direction index"
were useless on all tables and would cause even more confusion then
clarity. I discussed this that time with Kwok and others. They
all agreed with me. That is why the DiffServ-MIb is changed.
As a result of this, SNMPCONF can make much eaiser use of the
DiffServ-MIB without duplication the managed objects and
provide them as a configuration object.


This is an example from which I say the "interface index and
interface direction index" is redundant. As you can see
below the 'diffServMeterSucceedNext' points to an entry
associated with a different interface index.

diffServMeterTable
*   ifIndex                       = 1
*   diffServMeterIfDirection      = egress
*   diffServMeterId               = 1
    diffServMeterSucceedNext      =
diffServActionEntry.diffServActionId.2.egress.1
    diffServMeterFailNext         =
diffServActionEntry.diffServActionId.2.ingress.2
    diffServMeterSpecific         = 0.0
    diffServMeterStatus           = active

diffServActionTable
*   ifIndex                       = 2
*   diffServActionIfDirection     = egress
*   diffServActionId              = 1
    diffServActionNext            = 0.0
    diffServActionSpecific        = 0.0
    diffServActionStatus          = active

diffServActionTable
*   ifIndex                       = 2
*   diffServActionIfDirection     = ingress
*   diffServActionId              = 2
    diffServActionNext            = 0.0
    diffServActionSpecific        = 0.0
    diffServActionStatus          = active


> > If the latter then that's just
> > fine but we do need to check for consistency with the solutions being worked
> > on in snmpconf (yes Brian, that would mean a two-way dependency between these
> > work items). If the former then I think that the duplication of solutions
> > would be a Bad Thing.
> 
> Andrew, this is only in response to your general questions about the
> SNMPCONF work. Harrie and others have commented on some of the other
> questions. Instance amplification is a primary goal of the SNMPCONF work.
> The MIB Module Harrie and David Partain are working on is to apply to the
> selected elements (interfaces in this case) the template of values to these
> selected elements.
> 
> There was a desire to see if some of the 'template' tables could be included
> in the standard DiffServ. 

This was a desire, but my example above make it more mandatory,
due to not consistent usage of for instance interface index.
As said before, due to the change in the DiffServ MIB it makes
SNMPCONF usage very simple. We can use the same tables for
datapath 'templates'.

> That is what they have been working on with Kwok.
> There should not be a duplication of solutions.

That was also a goal. No duplication.

Hope this helps.

Harrie
0- Harrie Hazewinkel ---------------------------------------0
 mailto:harrie@covalent.net            phone:+1-415-536-5221
0-----------------------------------------------------------0