Subject: RE: snmpconf General Functional Questions

From: Dan Romascanu <[email-masked]>
Date: Mon, 12 Jun 2000 10:46:45 +0200

Jon,

I think that making the solution TOO simple, may result it in being
implementable and deployable, but not useful. We probably agree on this. 

However, I do not understand your example about the 'exempted' element. Do
you mean that once a value was overridden, the respective instance can't be
touched any longer, until the 'touch' bit in Joel's second table is cleared?
Who clears this table?

Regards, 

Dan

> -----Original Message-----
> From:	Jon Saperia [SMTP:[email-masked]]
> Sent:	Fri June 09 2000 21:38
> To:	[email-masked]
> Cc:	rap (E-mail)
> Subject:	Re: snmpconf General Functional Questions
> 
> on 06/09/2000 2:43 PM, Andrew Smith at [email-masked] wrote:
> 
> > We dived into this can of worms with COPS-PR. We very quickly swam to
> the
> > edge of the can and got out again and declared (a) time-of-day in the
> device
> > and (b) multiple managers, to be out of scope. Yes, this limits the
> areas of
> > application of the protocol but it does make it implementable and
> > deployable.
> 
> I can see how putting these items out of scope of that work does simplify
> things. I hope we can take a middle ground in terms of assumptions and yet
> get a good improvement. For example, by allowing for the 'override' but
> not
> attempting to roll back and keeping the element 'exempted' once a value
> has
> been overridden. One tool that we do have that may make it more reasonable
> is that we do have access and visibility into the instance specific data.
> 
> /jon

---

From: Jon Saperia <[email-masked]>
Date: Mon, 12 Jun 2000 08:10:40 -0400

> implementable and deployable, but not useful. We probably agree on this.

I think we do.
> touched any longer, until the 'touch' bit in Joel's second table is cleared?
I mean that the respective instance will be skipped each time a policy is
evaluated in the device that 'touches' that instance. This is like adding
another attribute/role to the instance that causes it to 'fail' the role
match in our system. This is how the policy system will know how to exempt
it. The attribute might be the 'exempt' attribute. It would have been placed
there if that instance had been touched by a mechanism other than the policy
system, for example a CLI, web interface, or a non-policy SNMP manager. The
way this works is that the policy system has access to the instances by
definition. It also knows if it changed a value or not.

I have not heard any objection to using the role table, so I assume for now
that is where this attribute is stored though that is not very important.
Once set the only way to reset it is by direct action on this attribute for
this instance. In an SNMP case the manager would sent a set to remove the
attribute. Certainly we have experience with enabling CLI's to have access
to such objects and I would have the CLI also able to remove this attribute.

/jon

---

From: David Harrington <[email-masked]>
Date: Mon, 12 Jun 2000 13:15:22 -0400

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. 

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.

dbh

-- 
---
David Harrington            Network Management Architect Engineer
[email-masked]           Office of the CTO
+1 603 337 2614 - voice     Enterasys Networks
+1 603 332 1524 - fax       Rochester NH, USA

---

From: Jon Saperia <[email-masked]>
Date: Wed, 14 Jun 2000 09:15:47 -0400

> 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.
> evaluation may be done within a different engine, as discussed at the

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. 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. If that is
not acceptable, another object in this table.

/jon

---

From: David Harrington <[email-masked]>
Date: Thu, 15 Jun 2000 13:43:31 -0400

Hi,

comments inline.

dbh

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

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

> 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

Yup. additional objects in these tables.

---

From: Matt White <[email-masked]>
Date: Mon, 19 Jun 2000 15:07:48 -0400 (EDT)

> not acceptable, another object in this table.

While this would work, I think I would prefer to look at the precedence
issue first.  We may come up with a solution to that problem that lends
itself well to solving the manual configuration problem.  Or we may not,
but I'd at least like to see where that goes before we lock ourselves into
a solution to this problem.

-Matt

---

From: Jon Saperia <[email-masked]>
Date: Fri, 23 Jun 2000 12:57:23 -0400

> a solution to this problem.
Matt,

can you clarify what you mean by the precedence issue please?

Thanks
/jon

---

From: Steve Waldbusser <[email-masked]>
Date: Fri, 30 Jun 2000 03:45:02 -0700

I agree that the "touch-bit" needs to be instance specific, but placing it in
the role table is pretty heavyweight because it will turn off *all* policies
that control a particular element. Say I need to override a variable for
firefighting purposes but I don't want to also turn off the policy that applies
QOS to that interface (because that might cause another firefight). The
"touch-bit" should turn off a particular policy from a particular instance.

In the current draft, such a facility exists:

PmTrackingElementToPolicyEntry ::= SEQUENCE {
    pmTrackingElementToPolicyElement          RowPointer,
    pmTrackingElementToPolicyStatus           INTEGER
}
    INDEX       { pmTrackingElementToPolicyElement, pmPolicyIndex }

pmTrackingElementToPolicyStatus OBJECT-TYPE
    SYNTAX      INTEGER {
                    off(0),
                    on(1),
                    forceOff(2)
                }

The forceOff state is the touch-bit. When set, it forcibly disables this policy
from executing on this element.

Also, I don't believe in having these bits set as side-effects of setting an
SNMP variable. Reasons include:
1) An SNMP set for a variable that is under policy control doesn't communicate
the following necessary sentiment: "While I know that this variable is under
policy control, I intend to override that anyway". In other words, the SNMP
engine can't tell whether the request intended to override policy or was an
innocent mistake. It would be hard to say that we're enforcing policy when any
request has carte-blanche to get an exemption.
2) Would require changing instrumentation for all MIBs
3) Doesn't specify which policy to override in those cases where a single
variable is under control of multiple policies.

Steve

---

From: Jon Saperia <[email-masked]>
Date: Thu, 29 Jun 2000 07:42:29 -0400

> "touch-bit" should turn off a particular policy from a particular instance.

Steve I had not intended that the policy be turned off globally. It was just
and indication that a particular element controlled by a policy had been
tweaked. That said, the proposal for the pmTrackingElementToPolicyElement
may be better than using the role table. The change I would make is that we
add an enumeration which is:
    
    modified(3)

This indicates that the values for a specific element in a specific policy
have been changed by a means other than the policy system.
> The forceOff state is the touch-bit. When set, it forcibly disables this
> policy from executing on this element.

This is fine but different. This value would be considered to be under the
control of the policy management system in my view. The modified value
indicates that a CLI or other non-policy based method touched the values for
this element that are associated with this policy.

> request has carte-blanche to get an exemption.

The intent of the user, innocent or not does not matter here. What matters
is that a value that was provisioned via the Policy module was changed by
something other than the policy module. Certainly a well run system would
not give carte-blanche to any user to make modifications. This is one of the
reasons why user based security can be helpful in policy management. I might
configure my systems under policy control so that only certain 'highly
privileged' users can modify the instance level configuration parameters
that are under policy control. They off course need this for fire-fighting
etc. This model is really no different that when a config file is sent to a
router today and is then later modified with a couple of CLI commands by a
network engineer because of one problem or another.

> 2) Would require changing instrumentation for all MIBs.

I do not believe this is so since it is the policy system that will detect
this change, not the instance specific instrumentation. There are several
ways of doing this, one might be during the re-evaluation of the policy
filter associated with each policy. This is not as bad as it might at first
seem since all that is required is to know if a value for an instance is
different than the default contained in the policy action object directly or
in a mechanism or implementation specific module. Another implementation
approach could be to separate this check from the instance evaluation since
the instances are already known. This could be a computationally less costly
approach. For future modules, I suggest more extensive use of notifications.
That way when a notification is generated a more timely update can be done
with less overhead.

> variable is under control of multiple policies.
In this case, one would assume multiple entries in your table, one for each
policy that an element is a member of. In that case the status would be
modified for each policy that the element is a member of.

Thanks
/jon

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 29 Jun 2000 09:33:56 -0400

There are at least two problems that I see being aluded to here.  Both are 
related to the phrase "if a variable is unde3r control of more than one 
policy".  We do need to make sure we understand what we want to happen in 
that case.

1) If you set that variable with SNMP, assuming that the intention is to 
override the policy setting of that variable, then I believe that you are 
overriding ALL the policies which set that variable.  Trying to achieve 
some intermediate state where some of the policies apply to that variable, 
but not all of them, would be better done by actually changing the set of 
roles, rather than trying to force-off.  force-off is for the case when the 
manual intervention is moving the variable out of the policy space temporarily.
2) In practice the variable can not really be set by more than one 
policy.  There is some sort of conflict which has essentially been resolved 
by "last touch wins".  Unless we are forcing order of evaluation of policy 
(and what about order of re-evaluation?) such a conflict resolution 
mechanism is exceedingly risky.  This goes on the conflict resolution thread.

Related to this, I believe that the intention of most of the discussants is 
that if a human being directly modifies a variable whose current state was 
effected by policy, then that variable better be removed from policy 
control automatically.  Otherwise, the user will get unexpected effects 
wherein his changes evaporate periodically (or even worse, some of them 
evaporate, but not all).

Yours,
Joel M. Halpern