Subject: Re: snmpconf BCP re: policy layering

From: Steve Waldbusser <[email-masked]>
Date: Thu, 12 Jul 2001 23:54:43 -0700

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

Instance-independence

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:

  Implementation-specific

    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.

  Mechanism-specific

    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.

  Domain-specific

    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
    mechanisms).

  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

Steve

---

From: Jeff Case <[email-masked]>
Date: Thu, 19 Jul 2001 21:49:43 -0400 (EDT)

wft>Greetings all...

hi

wft>-- We have had well over a year of this document being pored over without 
wft>this need for fundamental refinement.  Mind you, we've discussed this 
wft>taxonomy a lot, so it's not like people just never bothered to read that 
wft>far into the thing.  People smarter than myself like Joel Halpern, R. E. 
wft>Bob Moore, Jeff Case, and Dan Romanescu, who probably will forget more 
wft>about reference modelling in a bad week than I'll ever know, haven't 
wft>advanced or chimed in on this need for greater sophistication/complication 
wft>(although if you folks have just been watching this constructive debate and 
wft>avoiding comment, now's your time to jump in :).

first, thanks for the compliment

i have participated in behind-the-scenes conversations on this topic for
about a year but haven't said much, if anything, on this list about it

i guess i take your cue to jump in 

wft>-- I will advance (upon request :), how I think boring this out to be "two 
wft>dimensions" does in fact create a number of awkward "undefined" squares in 
wft>the matrix.  Briefly, I don't know what it means to have that which is 
wft>service-level-specific-without-regard-to-underlying-refinements *but* 
wft>instance specific, vs. that which is not.  And I wouldn't know as I sit 
wft>here now how to write text into the BCP to describe that.

i am not necessarily asking that you put out the extra effort to advance 
anything but i am unable to think of any examples where there are
"undefined" squares in the matrix unless both the instance independent
square AND the instance dependent square would both be undefined

wft>Anyways, with all respect to Steve (W.) and the constructive advancement of 

:-) you get gold stars for remembering and acting on my request to 
disambiguate the steves ... i think they *_are)_* instance dependent
and i think your solution is better than calling them steve.1 and steve.2 :-)

thanks for doing that

wft>his argument he has made, this is the reason I don't see needing to uncork 
wft>this now to introduce this new ingredient.  With my name on the masthead, 
wft>though, I'm not an ideal source of refutation of the argument, and I'd 
wft>appreciate any other commentary on this which has been silently festering 
wft>so we can figure out how to deal with this one way or another and advance 
wft>this puppy.

this silent festerer generally agrees with joel, i.e., i think that
steve (w.) is headed in the right direction and that this is worth doing:

joel wrote:

jmh>In fact, while the early proposal was to treat "instance" as a completely 
jmh>orthogonal  dimension, the current proposal is more to make it separate but 
jmh>not necessarily universally applicable.  part of the point is that while 
jmh>making it universally applicable makes for odd dead boxes, the current 
jmh>approach does not allow for any combinations at all.
jmh>     I think that you actually highlighted why this separation is useful in 
jmh>your discussion.  It is very helpful for comprehensibility if the end MIB 
jmh>objects actually fit into the framework.  Leaving them completely out (as 
jmh>you suggest you did) leaves out the piece that an SNMP orient reader is 
jmh>going to need.

yeah, what he (joel and/or steve w) said

(although i still don't know what odd dead boxes there might be [but i am
not trying to encourage a lengthy discussion of "old dead boxes" or
"undefined squares"])

best regards,
jdc