[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: snmpconf BCP re: policy layering
Jon Saperia wrote:
> The distinction you make is understood. The objection is that the value
> add of the additional dimension to which you speak does not outweigh the
> additional complexity. Once again this taxonomy does not need to become
> a class hierarchy - it was not intended to be one.
> If you have a specific proposal for a praragraph as I requested the
> other week, please make it otherwise we will go with the single
> modification we agreed to last week on this list.
I'm not saying the taxonomy isn't good enough, I'm concerned that it's
broken. The fixes to it aren't complex so I think we should fix it.
I can't really see how to fix things by adding a paragraph. Various
parts of Section 7.1 need to be modified. The text below shows how this
can be fixed and still stay simple.
Policy-based management seeks to simplify management by reducing
complexity in two ways: instance-independence and through layers of
A management instance exists for each of the many elements in a
managed system. Instance-specific configuration data is tied to a single
instance. Instance-independent configuration data isn't tied to a
particular instance but is shared across multiple instances. Because
instance-independent information is shared, there are fewer distinct
configurations to create and manage which makes management less
complex and more efficient.
For example, configuring gold QOS on interface #7 is an
instance-specific operation, while configuring gold QOS on all trunk
ports is an instance-independent operation.
Higher-layer abstractions hide technology details present in
underlying layers. The higher layer is thus simpler because it
requires less technology-specific knowledge and usually contains fewer
parameters to configure.
A hierarchy of abstraction layers has been identified where each layer
hides details of the layer below it and provides more details than the
layer above it. These layers are:
The implementation-specific layer is the base, unabstracted
layer. It contains all technology details including, notably,
implementation details from vendor to vendor. This is the
fundamental unit of abstraction.
A "mechanism" is a specific way to realize a function. For
example, in the area of routing, BGP has a number of mechanisms
that are used to realize specific behavior. The mechanism-specific
layer abstracts out all vendor-specific and implementation-specific
details, leaving only the details of the particular mechanism.
Many standards are an excellent example of information at the
mechanism-specific layer in that they describe all of the details
of the mechanism but don't describe the details of vendor
extensions that may exist.
A domain refers to all mechanisms used for a common technology
domain. For example, BGP would be one domain that contains many
mechanisms. The domain-specific layer abstracts out all details
of the individual mechanism, leaving only the details of the
An example of domain-specific MIB objects are the objects in the
ifTable which provide a mechanism-independent abstraction of
various interface types (i.e. ethernet and T3 are different
A service is a technology-independent, externally-visible task
such as routing or QOS. The service layer abstracts out all
details of the technology domain.
To demonstrate how a few of these layers might work, an example
related to the HVAC MIB would be:
Mechanism A: Uses a heating element and a fan and provides
the following controls:
Mechanism B: Uses forced steam through radiators and
provides the following control:
Abstracts the two mechanisms above and provides one control:
Abstracts the domain above and provides one control:
Combination of techniques
Management operations can employ both instance-independence and
abstraction gaining the benefits of both techniques. An operation
can be classified in one of 8 categories:
implementation-specific | | |
mechanism-specific | | |
domain-specific | | |
service-level | | |
Some examples of how several of the combinations might be used are:
mechanism-specific and instance-specific:
set heatingElementPower in room B29 to 80%
set fanSpeed in room B29 to 50%
mechanism-specific and instance-independent:
set heatingElementPower in unoccupied rooms to 20%
set fanSpeed in unoccupied rooms to 25%
service-level and instance-specific:
set desiredTemperature in room B29 to 70 degrees
service-level and instance-independent
set desiredTemperature in unoccupied rooms to 62 degrees
- Network Interfaces
mechanism-specific and instance-specific
mechanism-specific and instance-independent
get dot3StatsAlignmentErrors on all trunk ports
domain-specific and instance-specific
domain-specific and instance-independent
get ifInErrors on all trunk ports