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

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





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

That is not how my proposal would work. Using the example I gave
earlier:

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)

Every time diffPolicyPHBTarget.37 is set to a value, it spits out a
number of
implementation-specific commands to the element specified by the value.
So one
entry in the PHB table above will control many interfaces. It is the
policyFilter that decides which interfaces at any given moment.

The implementation-specific MIB will act like this:
Input                             Output
set diffPolicyPHBTarget.37=5
                                  set value A for interface 5
                                  set value B for interface 5
                                  set value C for interface 5
                                  set value D for interface 5

set diffPolicyPHBTarget.37=8
                                  set value A for interface 8
                                  set value B for interface 8
                                  set value C for interface 8
                                  set value D for interface 8


So when one policyAction references one entry in the
implementation-specific MIB, it actually does so for all N elements that
the policy applies to. Further, other policies may also have references
to the same entry in the impl-specific MIB.


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

This is more complex and still suffers from a number of the problems I
described
earlier. Specifically I think that issues 1, 4, 5 (copied below) are
still
problems.

Steve


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