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

Re: snmpconf General Functional Questions - Policy Groups and Priority


Comments inline.


Matt White
Ericsson IP Infrastructure

On Fri, 7 Jul 2000, Jon Saperia wrote:

> on 07/07/2000 12:57 PM, Matt White at mwhite@torrentnet.com wrote:
> > For this reason, I think it might be worthwhile to decide how we're going
> > to deal with conflicting policies.  How to deal with manual configuration
> > may fall out of how we deal with conflicting policies.  At the very least,
> > we may get some ideas from that discussion.
> Matt, I believe we did and even had consensus on the list on June 24th. Even
> Bert weighed in :-) 

I must be missing Bert's message and perhaps a few others.  My mailbox
seems to indicate no real consensus on what to do when Policy A sets OID1
to X and Policy B sets OID1 to Y.  The only recent message I have from
Bert states that if the element gives priority to Policy B and Policy B is
subsequently removed, then we should not go back and try to figure out
what value OID1 had before and change back.  I agree with this
wholeheartedly.  I also don't think that OID1 should automatically be set
to the value indicated by Policy A except to note that policy deletion is
probably a wizard time to re-evaluate the policies still on the device.

However, we seem to be talking about keeping a table containing every
instance on the device that is "under policy control" so that we know when
an operator makes a modification to an instance that was otherwise set by
policy.  The exact nature of how that works differs depending on whether
we take your path or the path suggested by Steve.  

I am merely asserting at this point that, if such a table is going to
exist, that it would be relatively simple to include as part of it a
pointer back to the policy that caused each row to be included.  It would
then also be a simple matter to have a priority level as part of the
policy table.  Then, when a policy is changing an instance, it could check
to see if that instance is already under policy control and whether the
policy being evaluated has a higher priority level.  If yes, apply the
change, if no, toss it.

Actually, if you are evaluating all policies on a device, it's even
simpler -- just evaluate in reverse priority order.

> The short answer is that the heavy lifting is done by
> the manger. Local conflict resolution has always been done to some degree.
> I gave the example of agents checking resources etc. Beyond that the policy
> system inside a managed element does not do any conflict resolution and
> detection. See my 7/3 posting.

Again, this all seems to be in regard to deleting policies and rollback of
instance values.  I agree.  We can't do this.  The best we can do is
suggest that this might be a good time to re-evaluate those policies still
on the device.

> All of this said, I am pretty convinced that there is significant value in
> adding a policy group and policy priority object to the policy table.
> Specifically group/priority is a way of connecting/prioritizing or doing
> conflict resolution external to the device. If there are 10 policies on a
> device and three related groups of policies, then I would say that there
> would be three policy groups. I would also say that the policy groups should
> be centrally named so that there is consistency across systems.

Agreed.  Although as I mentioned above there seems to be some simple
things that we *could* do on the box.  Note that if we state that devices
should overwrite on equal priorities, devices which cannot handle
prioritizing can opt out by restricting the priority level to a single

> The policy priority should also be organized globally recognizing that local
> optimizations may be needed.

An interesting point.