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

Re: snmpconf General Functional Questions



Hi,

comments inline.

dbh

> Jon Saperia wrote:
> 
> on 06/12/2000 1:15 PM, David Harrington at dbh@enterasys.com wrote:
> 
> > Hi,
> >
> > I think the exempt bit needs to be instance-specific, to tell which
> > instance has been overridden. If the "touch-bit" can be cleared via
> > SNMP, it will be important to know WHICH instance should be cleared
> if
> > there are multiple instances that have been touched.
> 
> Exactly so. We are all in agreement on this point. That is why I have
> proposed using the role table which is instance specific.

OK. I see my mistake. I read the text, which is ambiguous, and missed
the implications of the RowPointer type. The role table is
element-specific, with a pointer to a row of instances. Hence, knowing
the row that managed object instance is in, you can derive the affected
elements.

The text is very ambiguous, and could stand tightening - "An element is
a group of related MIB variables such as all the variables for
interface#7." A group isn't necessarily a row, although a row is
certainly a group. One row typically will not contain "all the
variables" related to interface#7.
Since element and row seem interchangeable here, why don't we just call
it a row, pmRoleESRow or pmRoleESRowPointer, rather than an element, to
reduce the indirection?

Can I manage scalars within the scope of an element? i.e. SET
function_enable=true?
Is that just a row with length=1? RowPointer with instance 0?
If I have an element pointing to a row, and I dynamically instatiate an
AUGMENTing table, does the element now relate to the new objects as
well?

A role can presumably be related to multiple rows in different tables
using multiple entries.
If I have multiple ATM Permanent Virtual Circuits (I'm allowed to model
circuits as elements), and each circuit requires multiple entries in the
role table to point to the related variables, we end up with a
potentially large number of rows in these tables for each circuit. We
have a potentially huge number of rows for a whole device. Should we
have some scalars or row objects that help to diminish the work
necessary to determine what has changed? e.g. TimeFilter, or
LastChanged, etc.? While notifications may help on this, it may also be
necessary to poll sometimes, such as when a manager reboots.

The search of these huge tables will need to be done for every command
to modify an attribute, whether done by SNMP SET or CLI modify-command
or COPS policy-dump, in order to set the dirty bit. This seems
unreasonably high overhead for every modify command.

> >
> > It may also be important for tracking down a security breach to
> expose
> > which instance was changed.
> >
> > Having the "touch-bit" at the role-abstraction level doesn't allow
> the
> > necessary granularity. I think it might be nice to have a dirty-flag
> at
> > the role level, to easily indicate that one or more instances of the
> 
> > role have been overridden. However, I am concerned that having the
> > touch-bit at this level may be problematic. It may be difficult to
> go
> > from the instance level to the role level easily, as has been
> discussed.
> > This becomes harder in a mid-level manager situation, where the role
> 
> > evaluation may be done within a different engine, as discussed at
> the
> > interim meeting.
> >
> 
> PmRoleESEntry ::= SEQUENCE {
>     pmRoleESElement        RowPointer,
>     pmRoleESString         SnmpAdminString,
>     pmRoleESStatus         RowStatus
> }
> 
> Roles are assigned on an instance specific basis.
> That is the only way
> the
> local mechanisms can know were to apply the policy. 
> I do not see the
> role
> evaluation taking place remotely. One a large machine with many
> interfaces
> and/or S/PVCs numbering into the many hundreds of thousands, the
> evaluation
> has to be done locally. 

It would certainly make sense to do so locally for performance reasons.
Are you suggesting the document say that it MUST be done locally?

For a legacy device without a policy engine, I might like to use a MLM
to evaluate the conditions and perform the resulting SETs from the MLM.
Certainly there will be issues of performance, and I may have to write
my actions carefully to be sure one SET doesn't prevent subsequent SETS
in the same action, but as far as I know, it is allowed, isn't it?

Given the potential size of the role tables, and the limited NVRAM on
many devices, and the CPU load imposed by searching these huge tables, I
can definitely see a need for an MLM to process role evaluation to help
offload these tables and processing.

If it is allowed, then how does a SET to a managed object instance on
remote row/element X by another management application get reflected in
the entry for row/elementX in the role table in the MLM? Obviously
notifications could help here, but are they adequate? For legacy
devices, the notify-on-attribute-value-change functionality won't exist.


> This does not mean that a MLM can not
> participate
> since the MLM application would send the policy filters to the targets
> for
> evaluation.
> 

> I propose that the pmRoleESStatus be the place for the dirty bit. 

pmRoleESStatus is a RowStatus variable. I would think it not a good
design to mix these two purposes.
How would you mark a status of "active AND dirty" and stay within the
enumerations of RowStatus?

> If
> that is
> not acceptable, another object in this table.

Yup. additional objects in these tables.
> 
> /jon

-- 
---
David Harrington            Network Management Architect Engineer
dbh@enterasys.com           Office of the CTO
+1 603 337 2614 - voice     Enterasys Networks
+1 603 332 1524 - fax       Rochester NH, USA