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

From: Andrew Smith <[email-masked]>
Date: Thu, 06 Jul 2000 11:22:51 -0700

David,

I'm a bit worried about the scalability of this approach, but maybe I'm
misunderstanding something about the proposal: are you saying that the "manager"
would create all the rows in this table, one row for every low-level object
instance that is affected by a high-level policy? That could be literally
thousands of entries per-device for a single high-level rule. Alternatively, if
the device creates them automagically, wouldn't some more interesting indexing
be better, rather than having to plough through a flat list? (It's not clear
from your MIB-fragment which you intended).

But I'm still not clear on all the downsides to strategy (1). To me, if you (the
manager) know which high-level rules map to which low-level MIBs/table then
there is no problem to go to that MIB (or to a MIB that AUGMENTs tables in that
low-level MIB) to debug it. You're going to have to know about the different
indexing requirements of the low-level tables anyhow, in order to make sense of
the results so I'm not convinced that the centralised approach can be used to
make any sort of useful generic "policy debugger" tool.

Andrew

David Partain wrote:
> 
> Greetings,
> 
> While speaking with Jon and Harrie, we talked about the need
> to have a way to "debug" policies.  Basically, there needs to
> be something showing the relationship between a policy in the
> policy MIB and its instantiation "lower" down.
> 
> We want this so that there is a way of correlating policies
> with things that are broken.  If you don't who's implementing
> a policy or the parameters that cause the change you want
> (or the change you _didn't_ want), you cannot debug it.
> 
> 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.
> 
> So, we propose that something along the lines of the objects
> below be added to the policyMgt MIB in
> draft-ietf-snmpconf-pm-??.txt.  The arguments for this are:
> 
>   1) If we don't put the relationship pointers in a central
>      place we have to spread them all over (if we're going to
>      have the information available). Thus, putting them in
>      the POLICY-MANAGEMENT-MIB avoids defining them in each
>      implementation-specific MIB.
> 
>   2) From an implementation-specific MIB module it is not
>      possible to know all relationships of applied policies. The
>      other way around is that when a policy is applied, the
>      management station should already select which
>      implementation-specific or instance-specific objects
>      are applicable.
> 
>   3) Having the relationships in a central place makes them
>      useful for debugging policies. For instance, if multiple
>      pointers from everywhere pointing to a policy in the Policy
>      MIB module you could have well overlooked 1 relationship.
> 
> We're obviously not attached to any names.  If someone has a
> better way of solving this problem, those ideas are greatly
> appreciated.
> 
> pmPolicyMechanismTable OBJECT-TYPE
>     SYNTAX       SEQUENCE OF PmPolicyMechanismEntry
>     STATUS       current
>     DESCRIPTION
>         "This table is used to show the relationships
>         from policies to mechanism specific policy definitions."
>     ::= policyMgt xx }
> 
> -- uses a shared index with the pmPolicyTable
> pmPolicyMechanismEntry OBJECT-TYPE
>     SYNTAX       PmPolicyMechanismEntry
>     STATUS       current
>     DESCRIPTION
>         "An row of the pmPolicyMechanismTable."
>     INDEX { pmPolicyIndex, pmPolicyMechanismIndex }
>     ::= pmPolicyMechanismTable 1 }
> 
> PmPolicyMechanismEntry SEQUENCE ::=
>     pmPolicyMechanismIndex      Unsigned32,
>     pmPolicyMechanismPointer    RowPointer
>     }
> 
> pmPolicyMechanismIndex OBJECT-TYPE
>     SYNTAX       INTEGER (1..2147483647)
>     STATUS       current
>     DESCRIPTION
>         "A unique index for the mechanism pointers."
>     ::= pmPolicyMechanismEntry 1 }
> 
> pmPolicyMechanismPointer OBJECT-TYPE
>     SYNTAX       RowPointer
>     STATUS       current
>     DESCRIPTION
>         "A row pointer that connects a policy instantiated at
>         'pmPolicyIndex' to mechanism specific."
>    ::= pmPolicyMechanismEntry 1 }
> 
> Your comments are welcome.
> 
> With kind regards,
> 
> --
> David Partain                  [email-masked]
> Ericsson Radio Systems AB      Tel: +46 13 28 41 44
> Research and Innovation        Fax: +46 13 28 75 67
> P.O. Box 1248
> SE-581 12  Linköping, Sweden

---

From: Jon Saperia <[email-masked]>
Date: Fri, 07 Jul 2000 09:07:46 -0400

on 07/06/2000 2:22 PM, Andrew Smith at [email-masked] wrote:

> misunderstanding something about the proposal: are you saying that the
> "manager" would create all the rows in this table, one row for every low-level
> object instance that is affected by a high-level policy? That could be
> literally thousands of entries per-device for a single high-level rule.
> Alternatively, if the device creates them automagically, wouldn't some more
> interesting indexing be better, rather than having to plough through a flat
> list? (It's not clear from your MIB-fragment which you intended).
> 

Andrew, David P. is on holiday so he may not be able to respond quickly. It
is definitely not the case that there would be a row in the table David
described for every object instance. The pointer that is referred to in the
proposed addition to the Policy MIB Module is a row pointer to the mechanism
and implementation specific MIB Modules. In the case of the DiffServ MIB
Module that David and Harrie are working on.
 
> But I'm still not clear on all the downsides to strategy (1). To me, if you
> (the manager) know which high-level rules map to which low-level MIBs/table
> then there is no problem to go to that MIB (or to a MIB that AUGMENTs tables
> in that low-level MIB) to debug it. You're going to have to know about the
> different indexing requirements of the low-level tables anyhow, in order to
> make sense of the results so I'm not convinced that the centralised approach
> can be used to make any sort of useful generic "policy debugger" tool.
> 
I am not sure that this has been presented with enough background to be
clear yet. I believe what was intended is:
                   
Policy Module
    |
    |
PolicyTable           Proposed Table of 2 objects AUGMENTS Policy Table
    |
    |-PolicyEntry.1-->pmPolicyMechanismIndex,pmPolicyMechanismPointer
    |-PolicyEntry.2-->pmPolicyMechanismIndex,pmPolicyMechanismPointer

In the case of the work in David and Harries module, the
pmPolicyMechanismPointer would be a RowPointer to an entry in the
diffPolicyPHBTable. It contains a diffPolicyPHBId Object that is the index
to the table.
        
This table would allow pointing to multiple mechanism and implementation
specific tables for a single policy. It would also allow an entry in the
diffPolicyPHBTable to be referenced by many policies.

/jon

---

From: Steve Waldbusser <[email-masked]>
Date: Wed, 12 Jul 2000 21:36:28 -0700

> doesn't), while avoiding the problems that are associated with

I agree that #3 is the best.

> draft-ietf-snmpconf-pm-??.txt. 
> ...
> PmPolicyMechanismEntry SEQUENCE ::= {
> ...

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

---

From: Jon Saperia <[email-masked]>
Date: Wed, 26 Jul 2000 09:45:47 -0400

> 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.
> ::= { 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

---

From: Steve Waldbusser <[email-masked]>
Date: Thu, 27 Jul 2000 11:11:55 -0700

> based on this 'template'. From the recently posted draft:

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

diffPolicyPHBTable

policyFilter

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.

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