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

Re: snmpconf Conflict Resolution Issues





Jon Saperia wrote:
> >
> 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.
> >>

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.

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