Subject: RE: snmpconf Conflict Resolution Issues

From: "Francis Reichmeyer (IPHighway MA)" <[email-masked]>
Date: Thu, 22 Jun 2000 14:15:42 -0400

Jon, quick question. What's an intentional conflict between policies?
Thanks,
-Fran

> -----Original Message-----
> From: Jon Saperia [mailto:[email-masked]]
> Sent: Thursday, June 22, 2000 10:19 AM
> To: snmpconf
> Subject: snmpconf Conflict Resolution Issues
> 
> 
> 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: Jon Saperia <[email-masked]>
Date: Fri, 23 Jun 2000 12:54:42 -0400

> Jon, quick question. What's an intentional conflict between policies?

I do not recall what others might have meant at the meeting. In simple
terms, a conflict is one where provisioned (downloaded) policies are sent to
a device that have conflicting values for an object.

Andrew pointed out, and he is correct that this is to be avoided. The place
where it will happen is when one policy is intended as a policy to become
effective in failure conditions and replace another policy. This is where
the idea of policy groups and priority are helpful. For example if a policy
evaluates to 'true' when there is a failure condition of some sort and it
has a higher priority, then it would overwrite the other policy. Actually
there would not be a conflict.

Hope this helps.

/jon

---

From: Andy Bierman <[email-masked]>
Date: Sat, 24 Jun 2000 10:35:04 -0700

> a device that have conflicting values for an object.

I made some comments at the interim in this area, but
it was to point out the need for explicit evaluation precedence.

There are conflicts that can be detected at load time:
  Policy 1: All interfaces with ifSpeed from 10MBit to 100MBit 
            get 'bronze' QoS
  Policy 2: All 100MBit interfaces connected to dept. WEB servers 
            gets 'gold' QoS

There are conflicts that can only be detected at run time:
  Policy 1: All interfaces with ifSpeed from 10MBit to 100MBit 
            get 'bronze' QoS
  Policy 2: The interface attached to the Engineering WEB server 
            gets 'gold' QoS

In each of these cases, policy 2 must have higher precedence.

This is no 'automatic' conflict resolution.
You need a real development environment with a real debug tool,
and some engineers who know what they're doing. 
Just moving the program to the device doesn't make the programming 
work go away.

> there would not be a conflict.

Andy