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

Re: snmpconf Pointers from Policy MIB -> implementation-specificMIB



on 07/13/2000 12:36 AM, Steve Waldbusser at waldbusser@nextbeacon.com wrote:

> 
> David Partain wrote:
> 
>> Different strategies are possible.  Three are:
>> 
>> - pointers from the "lower" MIBs (implementation-specific)
>> into the policy MIB
>> 
>> - shared indices between the policy MIB and the
>> implementation-specific MIBs
>> 
>> - pointers from the policy MIB into the implementation-specific
>> MIBs
>> 
>> This was discussed at the last interim meeting, and the best
>> approach appears to be the last of them.  It allows the most
>> flexibility with respect to how many places to point to (which #2
>> doesn't), while avoiding the problems that are associated with
>> #1.
> 
> I agree that #3 is the best.

I think we are all in agreement on this issue now. We have to work out the
details.
> 
> 
>> So, we propose that something along the lines of the objects
>> below be added to the policyMgt MIB in
>> draft-ietf-snmpconf-pm-??.txt.
>> ...
>> PmPolicyMechanismEntry SEQUENCE ::= {
>> pmPolicyMechanismIndex      Unsigned32,
>> pmPolicyMechanismPointer    RowPointer
>> }
>> ...
> 
> I think there's a better way to implement #3. Add a settable object
> to the implementation-specific MIB that, when set, causes it to act.
> The contents of the set contains the identity of the target element.
> 
> For example, in the diffserv policy MIB, you would have:
> 
> diffPolicyPHBTarget OBJECT-TYPE
> SYNTAX      Integer32
> MAX-ACCESS  read-create
> STATUS      current
> DESCRIPTION
> "This object is set with the ifIndex value of the interface
> to be configured. When this object is set, the associated
> interface will be configured with the per-hop-behavior
> described by this entry."
> ::= { diffPolicyPHBEntry xx }

A couple of problems here if I understand this proposal:

1. We were talking about a pointer from the Policy MIB Module to the
mechanism or implementation specific MIB Module. Your example seems to have
added an object to the DiffServ Policy MIB Module. This is not a show
stopper since the way you propose it the object is 'set' via the policy MIB
Module. I have a proposal below that I think makes this work.

2. The PHB Table in the current DiffServ Policy MIB Module draft is not
instance/element specific. Many instances in a system might be configured
based on this 'template'. From the recently posted draft:

>> - The diffPolicyPHBTable provides managed objects for
>> per-hop-behavior configuration. This table contains
>> RowPointers into subsequent tables in such a way that the
>> Traffic Control Block (TCB) can be created as soon as a
>> configuration is made active.
>> 

The mechanism and implementation specific MIB Modules will not as a rule
have instance specific information such as ifIndex.

All this said, you make what I think are some really good points in the rest
of the note which I have left attached. I think we can make this all work as
you suggest and get all the benefits you describe(though I am skeptical
about the Mid-level manager piece).

A side effect is that if more than one policy wishes to use a mechanism or
implementation specific set of parameters, additional duplicate rows must be
created in each module. In this case we are talking about the DiffServ
mechanisms, but the problem is generic.

What we would do is change your definition and substitute the following
object:

diffPolicyPHBPolicy OBJECT-TYPE
SYNTAX      Integer32
MAX-ACCESS  read-write
STATUS      current
DESCRIPTION
"When this MIB Module is used in conjunction with the Policy MIB Module, the
policyAction portion of the policy can contain a command to set this object
to the value of the pmPolicyIndex that will use the PHB definitions defined
in this row of the diffPolicyPHBTable. In the case where the policyAction
points to an entry in the diffPolicyPHBTable that already has a value for
this object, then the values from that row will be copied into a new row and
this value will be filled in with the pmPolicyIndex of the policy that
caused the creation of this row. When a policy is removed, all created rows
are to be deleted. When a policy is removed that did not create this row,
then this value shall be set to 0 indicating this row is not currently used
by any policy on the system."
::= { diffPolicyPHBEntry xx }

All this is a bit awkward, but is the only way I have thought of to date to
avoid having to manually create duplicate rows for policies that will have
the same mechanism and implementation specific parameters. I think this will
happen a lot. What will be different are the instances to which they are
applied.

/jon

> Then a policy action can contain a command to set this variable
> to 7 (for example), and cause the specified PHB to be applied to
> interface #7.
> 
> For example:
> 
> diffPolicyPHBTable
> ID Descr                       TrafficID           Action
> 37  "Mark SAP/R3 with DSCP 7"   ptr to SAP 6tuple   ptr to Mark command
> 51  ...
> 
> 
> policyFilter     
> (type == interface) && roleMatch("Access")
> policyAction
> setint(diffPolicyPHBTarget.37, $1)
> 
> In other words, foreach interface that is access, set
> diffPolicyPHBTarget.3 to the ifindex of the interface.
> 
> This is more in keeping with the original architecture we agreed
> upon some time ago (and re-affirmed at the last meeting,
> ref.: "Instance Dependent, Mechanism Independent Service").
> 
> Benefits over the RowPointer include:
> 
> 1. Allows mid-level-manager implementations
> We would like to have MLM implementations where the policy
> evaluation happens on one machine which enforces policy on
> a number of systems in a sub-domain. Unfortunately, a
> RowPointer has significance only within an agent so it can't
> be used in an MLM implementation.
> 
> 2. Avoids uncertainty over which executes, the script or rowpointer
> If the pmPolicyTable had both the rowPointer object as well as
> policyAction, it would be unclear what to do when both
> the RowPointer and the policyAction were set.
> 
> 3. Allows conditionals to be used
> Since policyActions are scripts they can contain conditionals
> such as:
> if (capMatch("diffServ"))  -- If diffserv is supported
> setint(diffPolicyPHBTarget.3, $1)
> else
> setint(802PolicyTarget.7, $1)
> -- i.e. 802 implementation-specific MIB
> 
> A RowPointer wouldn't allow such a construct.
> 
> 4. Allows service of implementation-specific MIB to be used
> independently of Policy MIB
> Allows any SNMP application to use the diffPolicyMIB to configure
> per-hop-behavior.
> 
> 5. The RowPointer mechanism only allows actions on "this element".
> A fair amount of the time we will want to perform an action on
> an element related to "this element". Scripts will have the
> ability to follow these relationships and select the correct
> target address.
> 
> 
> Steve