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

Abstraction Layers

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
    overall domain.

    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

  Service Layer

    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.

  An example

    To demonstrate how a few of these layers might work, an example
    related to the HVAC MIB would be:

      Mechanism-specific layer

          Mechanism A: Uses a heating element and a fan and provides
                       the following controls:

                           heatingElementPower   Integer32,
                           fanSpeed              Integer32

          Mechanism B: Uses forced steam through radiators and
                       provides the following control:

                           steamFlow             Boolean

      Domain-specific layer

          Abstracts the two mechanisms above and provides one control:

                           heaterOn              Boolean

      Service layer

          Abstracts the domain above and provides one control:

                           desiredTemperature    Integer32

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:

                           instance-specific    instance-independent
implementation-specific |                     |                      |
mechanism-specific      |                     |                      |
domain-specific         |                     |                      |
service-level           |                     |                      |

Some examples of how several of the combinations might be used are:

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

            get dot3StatsAlignmentErrors.7

        mechanism-specific and instance-independent

            get dot3StatsAlignmentErrors on all trunk ports

        domain-specific and instance-specific

            get ifInErrors.7

        domain-specific and instance-independent

            get ifInErrors on all trunk ports