Subject: snmpconf General Functional Questions

From: Jon Saperia <[email-masked]>
Date: Thu, 08 Jun 2000 08:49:48 -0400

This note is the first in the series that I said I would send. It contains
the items under the General Functional Questions heading that appeared in
the minutes of our interim meeting.  This time I have put in my 'editorial
comments'. I would like to get feedback/consensus on these issues so that we
can impact the appropriate draft documents. For those items that I do not
have a strong feeling or view, I did not say much or said no comment.

> General Functional Questions:
> 
> 1. Should operators be able to override policy? Where is it useful to
> restrict this in the architecture - fall out issues?

Yes. It is an essential operational component for operators to be able to
change one or more elements that are under policy control. For the purposes
of this discussion, an element could be anything from an entire system,
software that runs on it, or an individual queue on an interface. I do not
believe we should restrict the ability to override policy in the
architecture. I believe that this approach raises several issues. I have
added my suggestions for their resolution - I am sure there may be others.

   A. Notification of the change to operators - I believe that a
notification  should be sent from the managed element to the configured
managers for the system. The notification should contain the following
information: user, time of change, and the objects that were changed. The
instance values will be known to the system and would be conveyed to the
manager as in any other notification. The preferred notification for all of
our would should be an inform.

   B. Where is the override shown on managed system. The managed system
should reflect this in the status objects contained in the the Policy Table,
and when an implementation and/or mechanism specific Module is in use, the
change(s) should be reflected in the relevant status objects contained in
that modules table. We may want to consider a marking for the Role table so
show when an element that is under policy control contains one or more
objects that have other than 'default' values.

   C. How long is the override in effect? I recommend until one of two
events. First, some source outside the policy system changes the value(s)
back to the defaults. In which case there will no longer be the difference
detected in point B above. The most common source will be the CLI. Second, a
policy is reloaded to a system which should override the overrides.

   D. What if the override causes a fault or failure in one or more
operating policies? - I see this as no different than failures under other
circumstances. The same rules (that we have not yet worked out) should
apply.

> 
> 2. We need to more fully specify terminology regarding capabilities type and
> sub-type.

I would like to propose the following hierarchy for capabilities that uses
the same terms we agreed on at the interim meeting:

     Capability Type - Support for a particular technology domain such as
DIFFSERV or INTSERV or WEB Services or DNS.

    Capability Sub-Type - support for a particular mechanism such as RED,
WRED, APACHE, BIND, etc.

    Capability type and sub-type should be standardized values.
> 
> 3. What do we call capabilities that are beyond type and sub-type such as
> those found in the mechanism and implementation specific modules? The
> mechanism for their discovery is?

If an implementation specific technology were also available that would
appear as a vendor specific sub-type. Note that this does not include the
specific parameters that would appear in a mechanism or implementation
specific policy module. A policy management application would know of the
presence of such a module from the sub type value(s) in the policy module
and would be able to learn the details through a direct query to tables in
the implementation and mechanism specific tables. This is not unlike some
SNMP based discovery methods used for network topology today where the
results returned from the query of one table lead to the interrogation of
other tables. There is an implication here for tables that have not yet been
populated since there will be no instances. This can be worked out without
adding additional MIB objects. One method is to create a reserved row that
is the first row of the table.

I would also like to suggest that as sub-systems go up or down and make
their information available to the Policy Module, that an INFORM be sent to
make things more efficient.
> 
> 4. Are capabilities and capacity information part of the policy decision?

There are several questions here:

    A. Where is the policy decision made? Ultimately capabilities and
capacity do impact what happens in the real world. For example, if we
attempt to configure name server parameters on a system without a name
server one would expect a no such error from an agent. In a sense this is a
type of capability check.  If I attempt to provision a new service on a
router and the packet forwarding engine is already at capacity, ultimately
the policy will fail - though the failures might occur at very small time
intervals. The question posed by this point is - Should these factors impact
a policy management applications decision about whether or not to send or
modify a policy in a managed device. I think the answer should be yes.

    A. Is this a mandatory requirement of the architecture, or is it allowed
within the architecture that these factors impact the decision? I believe
that within the architecture of SNMP based configuration, there is no
restriction or requirement that these factors be taken into account. Even
though the architecture does not require it, I believe it is a useful
optimization for these factors to be taken into consideration since it will
be operationally beneficial.

    B. Can/Should capabilities impact what an application sends to an
element. This question would be relevant regardless of where the application
ran, in a managed element itself, in a 'mid-level' manager, or in a
centralized station? Yes.

    C. Can/Should capacity information similarly impact the policy decision?
Yes.

These answers beg the question about where does the information come from?
The capability information is described in the previous question. Capacity
information has several relevant sub parts.

   - First is total capacity for a system to perform some function.
   - Second is the amount of that capacity that remains averaged over some
time interval.
   - Third is amount desired/needed for the new policy.
   - Fourth is reserve to be held (some systems are under-provisioned as a
matter of policy for backup in certain failure conditions)

In some cases, the capacity information will be directly available such as
with ifSpeed. In some cases, objects that are direct reflections of capacity
may not be available or algorithmically determinable, though they can be
counted as in the number of packets forwarded, or the number of WEB pages
served. In these cases, I would say that we should consider the addition of
a table that can be used similar to our role tables. This would contain
total capacity, reserved capacity, and allow for the aggregation of used
resources. The concept of policy groups is helpful here since we may want to
aggregate usage based on related policies. In some cases, capacity is not
relevant as in the case of a policy that requires a particular version of
software. In this case it would be allowable for the capacity object to be
null.
   
> 
> 5. How do we do duration time calculations?

Before the Interim meeting, Hongal had started some work on time, schedules,
etc as had Steve. I have no strong feelings in this are or specific
suggestions.
> 
> 6. How do we represent and deal with time of day in the policy expression?
> 
ibid., except we should be able to express things with durations and
single/one time fire rules.

> 7. Time based rules are good things, there are some scheduling approach
> options:
> What light weight options do we want to allow?
> Do we require the device to know about time of day?

Same, perhaps Steve, Hongal and others could make suggestions.
> 
> 8. Would like to test a filter to get to the pointer to the attributes that
> have been changed as a result of the policy.

I agree this would be a good function. We talked very briefly during the
meeting about testing. We need a specific proposal about testing and
verification.
> 
> 9. Do the debug tables do enough?  Do they need to change or should they be
> removed? What is needed to improve them and is it worth the cost?

This is related to the previous question. I believe the answer is that there
is high value. The question is what is the cost and until we can evaluate a
specific proposal that is hard to judge. Does anyone have a specific
proposal. Mike MacFaden has been a strong supporter of testing and
verification - any suggestions?
> 
> 10. When was a system last touched? What was changed and when was a
> constellation of policies changed?
> 
I see value in last changed objects for several of the tables including most
of the tables in the Policy Module. The reason is that when debugging a
network, the network engineer may not have access to the centralized
management information so having it available 'on the box' would be of
benefit.

> 11. How do capabilities work?

See previous comments.
> 
> 12. How do we represent capacity and information about utilization?

See previous comments, though I know we need to do more work here.
> 
> 13. General issue of debugging policies and the PmTracking table. How useful
> is this and how do we want to support the function? Is more needed for these
> tables?

See comments on question 9.
> 
> 14. How do we deal with revision of a single policy and sets of policies? Do
> we have policy groups, and policy priorities. How will we represent them?

I believe that groups are helpful for some of the reasons previously stated.
I also think that priority is helpful. Unfortunately this raises the
question of whether priority spans groups. I believe it should and that we
can construct the policy tables to accommodate this with a single object and
some rules. For example if there are 32 policies, and a new policy is added
that needs to be number 2. The previous number 2 becomes 3 and so on.
> 
> 15. Is there fate sharing between policies in groups, if so how is this
> specified?

I am not sure this is necessarily a good idea. Do others have comments?
> 
> 16. How often do policy evaluations run?
> 
My view is that this will need to vary, but his does not answer the
question. I believe that this will get resolved when we have the 'iteration'
discussions. Andy had some views and Steve is working on this. Any
proposals?

> 17. Storage-type clarification for policies, are they all non-volitile?
>
I am not sure we should mandate this, but I would recommend they be
non-volatile.
 
> 18. Do/can-we start/stop polices as groups?

I believe that this is 'a good thing' if not too costly and that we should
specifically support it with policy group objects.

> 
> 19. Resolution of the forced off in the pmTracking tracking table?
> 
no comment.

> 20. Do we want to allow cascading policy what are the implications?

nc. for now.
> 
> 21. What are legitimate policy names?
> 
I do not believe the architecture or our recommended approach to
implementation should pose many limitations. Are there specific
recommendations.

> 22. Notifications - what is the proper role, what are the proper
> notifications to be developed?

See previous comments.
> [end of list]

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 08 Jun 2000 10:22:16 -0400

I would agree that the ability to override policy on a "local" basis is 
important.  There are several ways to look at this, some of which I think 
are problematic.

1) Unless we change the SNMP semantics (something we all agree we should 
not do), there is a basic multi-manager capability of SNMP.  As such, 
something set at a policy level can be changed at the instance level.  I 
think it would both be significant effort and undesirable to change this.

1a) The immediate question then becomes what indications one expects of 
this change.  Trying to keep enough track of what objects are effected by 
policies such that when a person changes an instance object a higher level 
policy marking is automatically created reflecting the override seems 
problematic.

1b) There is the whole question of how / when policies are neforced.  if we 
consider that policy actions are taken when policy conditions are checked 
and verified, we still have the question of when the conditions are 
rechecked.  If they are rechecked periodically, and if the conditions 
include the state of the variable to be changed, then it is quite easy to 
see that a human being trying to change an isntance object might find it 
continually changing back.  He would then need to somehow track down the 
policy that is controlling that, and somehow have a way to disable the policy.
1b') The disabling of the policy is probably only supposed to happen for 
some specific instance, not all instances in the box.  But one would not 
want to have to change the roles attached to an instance just to disable a 
policy, would you?  Similarly, what happens if the manager sends a new set 
of policies?  How will those effect this override?

1c) There can easily be more than one policy which affects an instance 
variable (for example, different policies for different times of day).  I 
can not see an obvious heuristic for deciding what the operator wants done 
with the nighttime policy when he changes a variable and turns off the 
daytime policy.

My own conclusion is that
A) we need to spell out clearly how and when policies take effect and 
maintain effect.
B) That most of the rest needs to be left to the structuring of the policy 
conditions.  For example, one could add a role that is "exempted", and in 
all ones policies include "and not exempted".  That may not be the best 
solution, and we certainly can not mandate it.  But trying to solve all of 
the interactions in "override are simply impractical.  The only alternative 
I can see is a COPS-like mechanism where there is no override at all.

Yours,
Joel M. Halpern

---

From: Jon Saperia <[email-masked]>
Date: Fri, 09 Jun 2000 08:35:19 -0400

Joel,

Thanks very much for the thoughtful comments. Some of the issues I think I
have some ideas about. Others are a bit more difficult. Perhaps others have
ideas.

/jon

> think it would both be significant effort and undesirable to change this.

agreed.
> policy marking is automatically created reflecting the override seems

Perhaps I am being dense about this point because I do not understand why
this is true. We know exactly what instances are in a policy because we
evaluated the role table and it was based on the result of the evaluation
that we knew which instances the policy was applied to.  Additionally when
we made the atomic change either via cli or and non-policy enabled SNMP
system, the instance that was touched was part of the configuration command.
What have I missed.
> continually changing back.  He would then need to somehow track down the

It is for this reason that I suggested that if an object is brought out of
the policy by having a value changed that it be some marked (perhaps in the
role table, perhaps elsewhere). The object stays out of the policy until
either the big hammer is used and the entire policy is loaded again. This is
different than the policy being evaluated again - which will happen on a
routine basis in the managed device, how routing we still have not
established. You point made me see two things:

    1. The element does not need to inform software that realizes the Policy
Module when such a change is made. This is true because it is only really
relevant when the policy is re-evaluated. The disadvantage of this approach
is that some time might lag between the change and the time the notification
is sent to the central policy manager. This can be somewhat mitigated by the
configuration of informs from the managed object to the management system.
This will only work in the case of configuration change notifications built
into the basis system outside of any policy. Not  common today, but not hard
to add in the future. It can be further mitigated, depending on the policy
re-evaluation interval.

    2. The second point that your comment made me think about is that it is
probably wrong to have suggested that the element be moved back into policy
when the value that was changed was made the same again through any means
other than the policy mechanism. For example if a value of 2 is the policy
and a user makes it 3 and then later changes it back to a 2, I suggest that
the object is still outside the scope of the policy and should be so marked.
The way it becomes a member again is if the value that I have talked about
in the role table is deleted, or the entire policy is reloaded - the big
hammer approach that I am not real fond of.

> of policies?  How will those effect this override?

I like this idea of disabling parts of the policy. I suggest exactly the
same mechanism as I described above. The only difference here is that the
human sets an attribute value rather than the software that realizes the
Policy MIB Module.
> with the nighttime policy when he changes a variable and turns off the

This is much harder. My knee jerk reaction that probably is wrong is that
the policy that is changed with regard to an element is the one in effect
when the change is made. For example if there are two policies a work hours
policy and a non-work hours policy and the value of a specific instance of
an object is changed during the work hours policy then that object is no
longer in the work hours policy. The non-work hours policy applies.
> A) we need to spell out clearly how and when policies take effect and

agreed. proposals are welcome.

> I can see is a COPS-like mechanism where there is no override at all.

I was thinking something along the lines of what you said. An entry would be
made in the role, or perhaps other table, that indicates that a policy has
be exempted on this instance.  That would be sufficient. One problem I have
with the COPS-PR model is that it just does not deal with the inevitable
fact that people will make micro adjustments other than to reload the entire
policy. That could be a very expensive operation.

---

From: Matt White <[email-masked]>
Date: Fri, 9 Jun 2000 13:27:45 -0400 (EDT)

> system, the instance that was touched was part of the configuration command.

In fact, we can probably store policy affected object identifiers in a
table and then mark them when they are locally modified.  To return that
object to its policy based state, we simply remove the marking.

The questions then become:
*  What happens to marked objects if the policy affecting them is removed?
   Are they removed from the table or do they remain in case the policy
   affecting them is reinstated?  I lean towards the later due to
   time-based policies, if nothing else.
*  Do we want to mark local modifications prior to policies being applied?
   It seems to me that we want to do this as well.

So maybe what we really want is a "Don't touch" table of locally
configured OIDs and the ability to delete OIDs from that table when the
local configuration is no longer relevant?

-Matt
----
Matt White
Ericsson IP Infrastructure

---

From: Jon Saperia <[email-masked]>
Date: Fri, 09 Jun 2000 13:55:52 -0400

> object to its policy based state, we simply remove the marking.

Yes, I think we are saying the same thing.
> time-based policies, if nothing else.

I think that the marking must be policy specific due to time. In one of my
previous examples, I mentioned the work and non-work hours case. I think the
exemption should contain the policyID and description. I know that the ids
may get reused, that is why the description is helpful.

> It seems to me that we want to do this as well.

I am not sure what this means until an element has been identified as being
associated with one or more policies. I think many items could be in the
role table and never be in a policy. I think this only becomes interesting
after an element has been put under policy control. That said as another
part of this working group's activity, we are developing a BCP for
configuration in which we suggest that any time a configuration is changed
that the information about the change be send to the central manager. Seems
like good management practice to me.
> local configuration is no longer relevant?

I think the 'don't touch' is an attribute of an element (instance) if it has
been placed under policy control and has then been modified by something
other than the policy system. The don't touch can only be helpful I think if
it is that specific and the don't touch is associated with a policy. What do
you think?

/jon

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 09 Jun 2000 14:20:57 -0400

It may be as straight-forward as you and Jon suggest.
But, somehow, I can see ending up in interesting states.

For example, using the daytime / nighttime case, someone overrides the 
current (daytime) policy on some instance.  It becomes night, and the 
nighttime policy takes effect.  It was not overriden.  Then, it is no 
longer nighttime.  But, the daytime policy is still overriden.  So the 
instances remains set as the nighttime policy specified?  That is unlikely 
to be the desired effect.  But I tend to strongly shy away from policies 
which can unwind themselves to "previous" states where those are unspecified.

The obvious alternative is that if an object is touched manually, then it 
is blocked from policy. Or maybe only from policies which were already in 
the box when the attribute was changed?
Still looks complicated to me.

Yours,
Joel

---

From: Dale Francisco <[email-masked]>
Date: Fri, 9 Jun 2000 11:32:34 -0700 (PDT)

I think most of the override scenarios will revolve
around debugging and firefighting.  If an instance
really needs to remain in an "override" state for
a long time, then the policy itself needs to change.

For simplicity, it seems to me that once a manual
override happens, the instance variable has to stay
in its new state until the manual override
is manually removed.

Dale

---

From: Jon Saperia <[email-masked]>
Date: Fri, 09 Jun 2000 14:44:43 -0400

> a long time, then the policy itself needs to change.
This is probably true. I think the way this would work is either by
rewriting the policyFilter or by changing the role(s) for the elements that
one does not want in the policy any more.

> in its new state until the manual override
Yes, I think so.

/jon

---

From: Jon Saperia <[email-masked]>
Date: Fri, 09 Jun 2000 14:52:45 -0400

> Still looks complicated to me.

You may be winning me over. What would you say to a rule:

If an element under policy control has any attribute (read MIB Object)
changed that is under policy control, then it has the exemption bit set that
Matt and I wrote about (the don't touch bit) set. It remains in this state
until manually changed back. Dale made a good point that is at some point
the policy might need to change.

/jon

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 09 Jun 2000 15:42:49 -0400

This is an implementable, well defined behavior.  I could live with it.

It would be nice if the implementation were simpler than I imagine, so let 
me describe what I think the implementation effect is:
1) There is a table of objects for which the "do not touch" bit has been 
set.  When policy actions are being considered, such objects may not be 
effected.  [This relates to the question of failures of policies which 
effect several related objects.  TBD.]  This table probably should be SNMP 
visible.
2) There must be a table (whether visible to SNMP or not) or all elements 
which have actually been touched by policy.  [Removal of entries from this 
table must be tied to the maintenance of policy and the removal mechanisms 
for policy.  It may need to know which policies touched the object to 
handle policy removal).
3) When an object is manipulated directly using low level mechanisms (CLI, 
SNMP, ...) the table in (2) is checked.  If the object is in said table, 
then an entry is made in the table in (1).

This does seem to require updating the direct manipulation subsystem when 
policy is added, which is unfortunate, but probably inevitable.

Yours,
Joel M. Halpern

---

From: Matt White <[email-masked]>
Date: Mon, 12 Jun 2000 12:01:59 -0400 (EDT)

> it is that specific and the don't touch is associated with a policy. What do

The problem is what happens if an element is locally modified and then put
under policy control?  I don't think we want to allow policies to
overwrite existing explicit (manual) configuration when they are first
instantiated.

The way I view this is that, at any given time, there will be some number
of policies being enforced on a device.  These policies will conflict with
eachother (that seems unavoidable).  We need a mechanism for resolving
this conflict regardless.  Now, if we view manual configuration as a
"policy" of the highest priority, the conflict resolution mechanism that
we already need can be used to give us the behaviour that we want.

So, what I suggest is a table of OIDs and RowPointers to the policies that
are modifying them (there can be multiple policies per OID).  Manual
configuration can be a special policy that always exists.  Each policy
then has a priority assigned to it that is used to determine which policy
of the conflicting policies take effect.

-Matt

Matt White

---

From: David Harrington <[email-masked]>
Date: Mon, 12 Jun 2000 12:47:38 -0400

> overwrite existing explicit (manual) configuration when they are first
If I understand correctly what you are arguing for, I think we do want
to allow policies to override existing manual configuration when they
are first instantiated. 

The purpose of putting something under policy control is to standardize
the application of the policy throughout the system. When we first apply
policy, we must assume that there is a desire to apply the policy to all
appropriate elements, and we do not necessarily know the current state
of the target elements. If we want something exempted from the standard
policy, it should identified in the policy or in a higher-priority
policy. If manual configuration occurs AFTER the policy has been
applied, then that manual configuration should be a higher priority
until the "touch-bit" has been cleared (or it is otherwise configured to
resume standard policy).

Iy may be that you are saying that once a manual configuration has been
"logged" in the table being proposed to identify overrides (so that we
do understand the current state of the element), then we don't want
newly-instantiated policies to override the "logged" override, then I
agree with you.

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: Mon, 12 Jun 2000 12:52:33 -0400

> overwrite existing explicit (manual) configuration when they are first

This is a good point and a bit of the chicken and egg problem. In an earlier
posting I said another way to override a manual selection in addition to the
one we have been discussing is to reload the policy. It seems this is an
explicit user directed method. This is important since I agree we do not
want to overwrite existing explicit manual configuration. That is why I also
suggested that manual intervention on the role table is required in the case
of an object that has been overridden by manual change.  The meaning of
reload (as opposed to update) policy is the same as first time load. I think
these times, by definition you want to override manual settings. Remember
that manual overrides can be added and maintained indefinitely as needed. Of
course a policy full of manual overrides probably should not be a policy.
> of the conflicting policies take effect.
I had not thought about the current mechanism as a conflict related one
until you pointed it out. I do not want to start the general conflict
discussion in this thread, so perhaps another separate email. I am not clear
what OIDS you reference here, OIDs of the modified instances? Lets make this
a separate thread. In a day or so, I will try to consolidate what we have
discussed with regard to overrides.

/jon