[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
snmpconf General Functional Questions
This note is the first in the series that I said I would send. It contains
the items under the General Functional Questions heading that appeared in
the minutes of our interim meeting. This time I have put in my 'editorial
comments'. I would like to get feedback/consensus on these issues so that we
can impact the appropriate draft documents. For those items that I do not
have a strong feeling or view, I did not say much or said no comment.
> General Functional Questions:
> 1. Should operators be able to override policy? Where is it useful to
> restrict this in the architecture - fall out issues?
Yes. It is an essential operational component for operators to be able to
change one or more elements that are under policy control. For the purposes
of this discussion, an element could be anything from an entire system,
software that runs on it, or an individual queue on an interface. I do not
believe we should restrict the ability to override policy in the
architecture. I believe that this approach raises several issues. I have
added my suggestions for their resolution - I am sure there may be others.
A. Notification of the change to operators - I believe that a
notification should be sent from the managed element to the configured
managers for the system. The notification should contain the following
information: user, time of change, and the objects that were changed. The
instance values will be known to the system and would be conveyed to the
manager as in any other notification. The preferred notification for all of
our would should be an inform.
B. Where is the override shown on managed system. The managed system
should reflect this in the status objects contained in the the Policy Table,
and when an implementation and/or mechanism specific Module is in use, the
change(s) should be reflected in the relevant status objects contained in
that modules table. We may want to consider a marking for the Role table so
show when an element that is under policy control contains one or more
objects that have other than 'default' values.
C. How long is the override in effect? I recommend until one of two
events. First, some source outside the policy system changes the value(s)
back to the defaults. In which case there will no longer be the difference
detected in point B above. The most common source will be the CLI. Second, a
policy is reloaded to a system which should override the overrides.
D. What if the override causes a fault or failure in one or more
operating policies? - I see this as no different than failures under other
circumstances. The same rules (that we have not yet worked out) should
> 2. We need to more fully specify terminology regarding capabilities type and
I would like to propose the following hierarchy for capabilities that uses
the same terms we agreed on at the interim meeting:
Capability Type - Support for a particular technology domain such as
DIFFSERV or INTSERV or WEB Services or DNS.
Capability Sub-Type - support for a particular mechanism such as RED,
WRED, APACHE, BIND, etc.
Capability type and sub-type should be standardized values.
> 3. What do we call capabilities that are beyond type and sub-type such as
> those found in the mechanism and implementation specific modules? The
> mechanism for their discovery is?
If an implementation specific technology were also available that would
appear as a vendor specific sub-type. Note that this does not include the
specific parameters that would appear in a mechanism or implementation
specific policy module. A policy management application would know of the
presence of such a module from the sub type value(s) in the policy module
and would be able to learn the details through a direct query to tables in
the implementation and mechanism specific tables. This is not unlike some
SNMP based discovery methods used for network topology today where the
results returned from the query of one table lead to the interrogation of
other tables. There is an implication here for tables that have not yet been
populated since there will be no instances. This can be worked out without
adding additional MIB objects. One method is to create a reserved row that
is the first row of the table.
I would also like to suggest that as sub-systems go up or down and make
their information available to the Policy Module, that an INFORM be sent to
make things more efficient.
> 4. Are capabilities and capacity information part of the policy decision?
There are several questions here:
A. Where is the policy decision made? Ultimately capabilities and
capacity do impact what happens in the real world. For example, if we
attempt to configure name server parameters on a system without a name
server one would expect a no such error from an agent. In a sense this is a
type of capability check. If I attempt to provision a new service on a
router and the packet forwarding engine is already at capacity, ultimately
the policy will fail - though the failures might occur at very small time
intervals. The question posed by this point is - Should these factors impact
a policy management applications decision about whether or not to send or
modify a policy in a managed device. I think the answer should be yes.
A. Is this a mandatory requirement of the architecture, or is it allowed
within the architecture that these factors impact the decision? I believe
that within the architecture of SNMP based configuration, there is no
restriction or requirement that these factors be taken into account. Even
though the architecture does not require it, I believe it is a useful
optimization for these factors to be taken into consideration since it will
be operationally beneficial.
B. Can/Should capabilities impact what an application sends to an
element. This question would be relevant regardless of where the application
ran, in a managed element itself, in a 'mid-level' manager, or in a
centralized station? Yes.
C. Can/Should capacity information similarly impact the policy decision?
These answers beg the question about where does the information come from?
The capability information is described in the previous question. Capacity
information has several relevant sub parts.
- First is total capacity for a system to perform some function.
- Second is the amount of that capacity that remains averaged over some
- Third is amount desired/needed for the new policy.
- Fourth is reserve to be held (some systems are under-provisioned as a
matter of policy for backup in certain failure conditions)
In some cases, the capacity information will be directly available such as
with ifSpeed. In some cases, objects that are direct reflections of capacity
may not be available or algorithmically determinable, though they can be
counted as in the number of packets forwarded, or the number of WEB pages
served. In these cases, I would say that we should consider the addition of
a table that can be used similar to our role tables. This would contain
total capacity, reserved capacity, and allow for the aggregation of used
resources. The concept of policy groups is helpful here since we may want to
aggregate usage based on related policies. In some cases, capacity is not
relevant as in the case of a policy that requires a particular version of
software. In this case it would be allowable for the capacity object to be
> 5. How do we do duration time calculations?
Before the Interim meeting, Hongal had started some work on time, schedules,
etc as had Steve. I have no strong feelings in this are or specific
> 6. How do we represent and deal with time of day in the policy expression?
ibid., except we should be able to express things with durations and
single/one time fire rules.
> 7. Time based rules are good things, there are some scheduling approach
> What light weight options do we want to allow?
> Do we require the device to know about time of day?
Same, perhaps Steve, Hongal and others could make suggestions.
> 8. Would like to test a filter to get to the pointer to the attributes that
> have been changed as a result of the policy.
I agree this would be a good function. We talked very briefly during the
meeting about testing. We need a specific proposal about testing and
> 9. Do the debug tables do enough? Do they need to change or should they be
> removed? What is needed to improve them and is it worth the cost?
This is related to the previous question. I believe the answer is that there
is high value. The question is what is the cost and until we can evaluate a
specific proposal that is hard to judge. Does anyone have a specific
proposal. Mike MacFaden has been a strong supporter of testing and
verification - any suggestions?
> 10. When was a system last touched? What was changed and when was a
> constellation of policies changed?
I see value in last changed objects for several of the tables including most
of the tables in the Policy Module. The reason is that when debugging a
network, the network engineer may not have access to the centralized
management information so having it available 'on the box' would be of
> 11. How do capabilities work?
See previous comments.
> 12. How do we represent capacity and information about utilization?
See previous comments, though I know we need to do more work here.
> 13. General issue of debugging policies and the PmTracking table. How useful
> is this and how do we want to support the function? Is more needed for these
See comments on question 9.
> 14. How do we deal with revision of a single policy and sets of policies? Do
> we have policy groups, and policy priorities. How will we represent them?
I believe that groups are helpful for some of the reasons previously stated.
I also think that priority is helpful. Unfortunately this raises the
question of whether priority spans groups. I believe it should and that we
can construct the policy tables to accommodate this with a single object and
some rules. For example if there are 32 policies, and a new policy is added
that needs to be number 2. The previous number 2 becomes 3 and so on.
> 15. Is there fate sharing between policies in groups, if so how is this
I am not sure this is necessarily a good idea. Do others have comments?
> 16. How often do policy evaluations run?
My view is that this will need to vary, but his does not answer the
question. I believe that this will get resolved when we have the 'iteration'
discussions. Andy had some views and Steve is working on this. Any
> 17. Storage-type clarification for policies, are they all non-volitile?
I am not sure we should mandate this, but I would recommend they be
> 18. Do/can-we start/stop polices as groups?
I believe that this is 'a good thing' if not too costly and that we should
specifically support it with policy group objects.
> 19. Resolution of the forced off in the pmTracking tracking table?
> 20. Do we want to allow cascading policy what are the implications?
nc. for now.
> 21. What are legitimate policy names?
I do not believe the architecture or our recommended approach to
implementation should pose many limitations. Are there specific
> 22. Notifications - what is the proper role, what are the proper
> notifications to be developed?
See previous comments.
> [end of list]