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

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




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.


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

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