Subject: snmpconf Conflict Resolution Issues

From: Jon Saperia <[email-masked]>
Date: Thu, 22 Jun 2000 10:18:35 -0400

Here is the second in the group of issues that came out of our interim
meeting.

As before, I will put in my suggestions/thoughts where I have an opinion.

Conflict Resolution Issues:

1. How do we deal with intentional and unintended conflicts.

It is hard to tell between intentional and unintended conflicts between
policies. My suggestion is that this function be left to the policy
application function and not the managed element software.

2. Is conflict detection or resolution a goal?

Both are hard. Unless someone has a specific proposal, I suggest that we
omit this capability or recommend that it be left to the ingenuity of the
equipment or manager software developers.

3. What happens when a policy is deleted? What if anything do you revert to?

In the case of DIFFSERV, I do not see much of a problem since the traffic
that would have been treated will in systems I know about,  pass through the
system subject to the same 'rules' as the rest of the traffic. The problem
is for other types of policy. For example;  a policy that causes the
configuration of primary and secondary DNS servers. If the policy is
removed, the systems could be left without knowing where to send DNS
requests. I do not think we want to have the managed elements keep a scratch
pad either (though some may choose to do this for a number of reasons - and
we should not prohibit this).

My suggestion is that we recommend in the BCP that policy managers that
delete a policy, replace it with a default if appropriate or the parameters
that existed prior to the installation of this policy. This will be a
difficult problem to solve.

4. How many errors are acceptable in a policy? How are they reported?

Just as with the override of policy, failures should be reported on a per
instance basis. That is, if 5 instances fail a status object in the role
table that indicates a policy that includes this instance based on the
evaluation of the policy filter is not in force. This time the reason is a
failure as opposed to an override. There is probably no need for a second
object since the status can not both be failed and overridden.

A notification should be sent in such failure situations only when the
policy is first evaluated, not each time the policy is locally evaluated.

Beyond a managed elements requirements for consistency, we could create
another object that could deal with this, but it is probably best left to
the management application. The management application would also be the
place to determine if a particular value for a MIB Object under policy
control is outside of a policy range which would be helpful. Particular
instances may be tweaked that are under policy control due to a number of
conditions. 

5. What happens when a configured element breaks that is executing a policy?

The object that reflects the element status in the role table should be
updated and a notification sent. The policy ID should be part of all such
notifications for override, failures on initial evaluation/set up and
subsequent failures.

[end of list]

---

From: David Harrington <[email-masked]>
Date: Thu, 22 Jun 2000 13:51:33 -0400

Jon Saperia wrote:
> policies. 

Agreed. I don't think it is significant for us to differentiate these.

> My suggestion is that this function be left to the policy

When you say "this function", do you mean the differentiation of
intended vs. unintended,
or the resolution of conflicts?

> equipment or manager software developers.

I think it needs to be a goal to detect conflict and we should decide
how it should be handled. 
Conflict may result from situational factors. Trying to write conditions
to consider every possible factor would make rules difficult to
understand.

If we leave resolution to the administrator, we need to provide a
mechanism for the administrator to tell the policy application function
that "here is how I want this conflict handled" without forcing the
administrator to go rewrite the policies involved right then and there,
and to ensure that the conflict is re-reported on the next evaluation.

The same conflict may arise multiple times. We should allow the
administrator to define a "policy" to indicate how to resolve such
conflicts in the future. This may be able to be done using a MIB to
drive the conflict resolution (rule 4 overrides rule 3 when conflicts
arise).

Thanks for getting these discussion points out to the list.

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: Fri, 23 Jun 2000 12:20:56 -0400

on 06/22/2000 1:51 PM, David Harrington at [email-masked] wrote:

> When you say "this function", do you mean the differentiation of intended vs.
> unintended, or the resolution of conflicts?
>
I mean the determination between intentional and unintended conflict. In the
case of 'intended' the mechanism you desire in your comment below might be
found in policy group and priority. An intended conflict is one where policy
A sets a value of a particular MIB Object to X and policy B wants it to be
B. Intended in this case means that both policies were 'provisioned' this
way as might be the case of policies that deal with link failures etc. We
have yet to discuss priorities and groups on the list. Specific proposals
from people would be welcome. Anything beyond this should in my view be left
with the application.
> and to ensure that the conflict is re-reported on the next evaluation.

I believe this is part of the application that I suggested above.
> drive the conflict resolution (rule 4 overrides rule 3 when conflicts
See my comment above about priority and groups (work still needs to be done
on this).  Hongal was working on this. Hongal do you have a proposal?

/jon

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 24 Jun 2000 18:24:23 -0400

It is my opinion that deleting a policy should not directly cause a change 
in any attributes of any instances.  It may be reasonable to expect 
(depending upon our evaluation model) that the set of policies in effect 
should be re-evaluated, which my cause some existing policy to change the 
values of some objects.  Trying to perform a direct "unwinding" of a policy 
when it is deleted would, I think, be a very bad idea.

Yours,
Joel M. Halpern

---

From: David Harrington <[email-masked]>
Date: Tue, 27 Jun 2000 15:48:05 -0400

> from people would be welcome. Anything beyond this should in my view be left

Conflict resolution at the application will be difficult because it
doesn't have all the local information, i.e. the instance-specific
expansion and the current situational state of the device.

Conflict resolution is hard, and not all devices will be able to devote
resources to conflict resolution, while other devices can afford the
resources.

I believe it is reasonable to expect that conflict resolution should be
done in both places.
However, that may not always be possible.

I feel that for interoperability reasons, we should define the expected
behavior when a device does support additional conflict resoltuion, and
when it does not. When it does, it would probably be good to have a MIB
that can standardize that behavior, at least to a degree. It may be
useful to have an object that indicates whether the device does
additional conflict resolution (although I'm not sure it is necessary,
if it is only informational and would have no effect on the behavior of
an application). If there are multiple resolution approaches defined, it
might be useful to indicate which are supported by a particular
device/implementation.

There are a number of aspects to conflict resolution - rule priority,
role priority, scheduling overlap, relative size of the intersection of
conflict (possibly useful when there are multiple policies in conflict),
whether rules are inherited or specific to an element, resolution order
(when there are multiple conflicts), operator override, whether one
policy is currently active, which policy satisfies the greatest number
of conditions, which policy modifies the greatest number of managed
objects, which policy affects the greatest number of elements, what
behavior in the case of a tie in resolution (stay as is/pick one
randomly/report an error), whether the USER could be allowed to select
in the case of a tie, etc. 

For device-level resolution, it might be useful to try to standardize
resolution for each aspect using configurable mib tables, and then see
how these can be normalized. For application resolution, it would be
good if we can suggest some approaches to improve consistency across
applications.

---

From: Jon Saperia <[email-masked]>
Date: Wed, 28 Jun 2000 13:10:14 -0400

> when it is deleted would, I think, be a very bad idea.

Folks, I believe that we have consensus on this topic even though my
original postings may not have been clear.

The consensus is that we should not attempt to deal with this in the managed
systems at all for all the previously stated reasons.  I agree. If a manager
wants to do something fancy when deleting a policy that is outside the scope
of the current work.

All agreed?

/jon