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

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



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                  David.Partain@ericsson.com
> 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