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

snmpconf BCP re: policy layering

I have some general comments and questions about the policy layering
taxonomy in the BCP.

>    7.2.  Conceptual Layering
>    In order to present the principles of policy based management with
>    SNMP, we will create a MIB Module called the Building Heating
>    Ventilation and Air Conditioning (HVAC) MIB Module. This allows the
>    discussion to focus on the new principles as opposed to a specific
>    area of technology. Note that while the focus of this discussion is
>    on configuration, the abstractions discussed in this section could
>    equally apply to fault, performance, accounting or security objects.
>    Instance-Specific
>    Instance-specific information refers to values associated with a
>    specific instance in a managed element. One example would be the
>    number of octets that were received on a particular interface,
>    ifInOctets. In our example MIB Module, we will have fan and
>    temperature settings for every control panel in the building. Imagine
>    how many there would be in a 50-story office building or multi-acre
>    office park. Network operators have a similar problem, in all of the
>    parameters for the many routers and the interfaces they contain.
>    Each interface will have an ever increasing number of values that
>    must be configured to deliver specialized services such as
>    Differentiated Services.
>    Mechanism-Specific
>    The first layer of abstraction above the familiar instance-specific

Nothing in this section actually says that mechanism-specific MIB
objects are instance-independent (i.e. a characteristic of being a layer
above instance-specific is to be instance-independent). If that's what
is meant it should be stated here.

Assuming that's what is meant, however, I don't think that should be a 
characteristic of the mechanism-specific layer. The mechanism,
implementation, domain, and service layers provide *abstraction* as you
move through the layers. However, instance-independence provides
simplification by reducing the number of instances but it doesn't
provide abstraction.

For example, you could say that "ifInErrors" is a mechanism-independent
abstraction of:
       dot3StatsAlignmentErrors, dot3StatsFCSErrors, 
       dot3StatsFrameTooLongs, ...
  Token Ring
       dot5StatsLineErrors, dot5StatsBurstErrors, 
       dot5StatsACErrors, ...

Using ifInErrors gives me the benefits of abstraction in that I don't
need to understand the details of the mechanism (token ring or

Turning to instance-dependence, an instance-specific usage would be to
request the "ifInErrors on interfaces #7 and #11" and an
instance-independent usage would be to request the "ifInErrors on all
trunk ports".

Putting these together, I can have 4 types of statements:
      dot3StatsAlignmentErrors on all trunk ports
      ifInErrors on all trunk ports

If you place instance-independence at the bottom of the
abstraction-layer stack, first of all it doesn't fit because
instance-independence isn't an abstraction layer and second of all it
doesn't take into account the instance-specific/mechanism-independent
case above.

If a typical instance looks like dot3StatsAlignmentErrors.7,
instance-independence messes around with the stuff to the right of the
dot (.) and abstraction-layers mess around with the stuff to the left of
the dot.

Also, note that the abstraction layer is an attribute of a MIB object
(ifInErrors vs. dot3StatsAlignmentErrors) while instance-independence is
not an attribute of the MIB object definition, but of how that object is
used. This is true even in the HVAC MIB which, while it makes it
*easier* to achieve instance-independence, is only instance-independent
if it is used that way (I can still use the HVAC MIB in an
instance-specific way).

I'd suggest that the issue of instance-dependence be separated from the
issue of the abstraction layer. A management operation is then described
as being instance-independent or not and as being at a particular layer.
So I'd take instance-specific out of the hierarchy and have it described
right before the hierarchy.

>    level is called "mechanism-specific". This is the level that contains
>    the defaults that would be used to assign values to instance-specific
>    objects.

I'm not sure why this ties mechanism-specific to the issue of defaults.
"Defaults" isn't really an abstraction mechanism. The next paragraph
really says it better. I think that the discussion of defaults should be
removed from this section to keep the focus on the 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. As a result, there are many parameters
>    that apply specifically to BGP and its associated mechanisms that it
>    uses to accomplish it's routing task such as time-out values etc.,
>    that BGP uses to accomplish its routing task.
>    MIB objects that are mechanism-specific are the defaults used for
>    instance-specific MIB object creation or modification. They are the
>    defaults for standard instance-specific MIB objects when used in an
>    SNMP-based policy system. In our HVAC example, we have several
>    mechanisms that are used in the standard MIB module to control how
>    fast a fan is to turn and what position a switch is to be in for
>    heating or cooling.
>    Mechanisms have on additional attribute that distinguishes them. They
>    are technologies defined in standards that are used within a
>    particular domain as in our routing example. Mechanism-specific MIB
>    Objects then, are a layer of abstraction above standards-based
>    instance-specific MIB objects.

I think there's a typo somewhere. The 2nd sentence says that mechanisms
are defined in standards (ergo standards are mechanism-specific,
right?). Then the 3rd sentence says that mechanism-specific is a layer
above standards-based. Where did I go wrong?

Also, I think it's dangerous to typecast standards-based objects into a
particular architectural category because as soon as a standard is
written including higher-level objects then this will be wrong.

>    Implementation-Specific
>    Vendors often add special capabilities to standards as a way of
>    meeting special customer requirements or differentiating themselves
>    from competitors.  Implementation-Specific MIB objects have the same
>    properties as mechanism-specific ones except they have been created
>    as abstractions for vendor created instance-specific MIB objects.
>    These special capabilities are often a result of the implementation
>    approach that a vendor has used for the product, which is the reason
>    for the term "implementation-specific". In our HVAC example, some
>    vendors might extend the standard to include features that
>    distinguish their products from their competition. In our example MIB
>    module, the system is a sophisticated one and allows for the control
>    of the humidity, which is not part of the HVAC standard MIB Module
>    and as such there would be no mechanism-specific MIB objects for
>    humidity.
>    In summary, implementation and mechanism specific MIB objects occupy
>    the same level of abstraction in our hierarchy. The only difference
>    is that mechanism-specific MIB Objects are defined in a standards
>    body, while implementation-specific objects are defined by vendors in
>    the same way that vendors define their extensions today.

This surprised me a bit. I would have thought that
implementation-specific was the lowest layer of abstraction (i.e. vendor
MIBs). The mechanism-specific layer (today's standard MIBs) abstracts
out implementation details but leaves mechanism details. The
domain-specific layer in turn abstracts out mechanism-specific details
but leaves domain-specific details.

>    Higher Levels of Abstraction
>    If the world consisted of only of MIB and protocol experts, the
>    abstractions described above would be sufficient. They enable the
>    efficient transfer of information from management systems to managed
>    devices. The fact is that many people who know nothing about the
>    protocol details need to use systems that manage SNMP-based
>    configuration data that know nothing about the protocol details.
>    There are vendor and model differences that make the addition of two
>    layers above the mechanism and implementation-specific layer helpful.
>    The higher levels of abstraction that are defined next help achieve
>    some important operational goals and make it possible to write better
>    management software. Here are some of benefits for organizing SNMP-
>    based information into higher levels of abstraction:
>         1. Abstract the details of the differences in technology away
>         from the users. This is a common principle in
>         programming. The user of a service should not have to know
>         the details of how the service is implemented. OSPF and BGP
>         are both routing protocols but have different "knobs". If you
>         want to add a new system to the network today, you must have
>         an expert in both if you use both technologies. Different
>         implementations of WEB servers have different "knobs". To
>         change a configuration or add a new service to each, you need
>         a person who knows the individual knobs. A solution to this
>         is to write software that abstracts above this level.
>         2. Abstract the differences from one vendor to another. Even
>         when standard technologies are implemented, vendors will have
>         variations. In a multi-vendor environment this means that not
>         only do you require technology experts, but you have to have
>         experts who know the differences in the knobs for each
>         technology for each vendor. In the case of SNMP, these knobs
>         are MIB Objects.
>    Domain-Specific
>    A useful way to abstract information above that which is exposed in
>    instance-specific,implementation or mechanism-specific MIB Objects is
>    at the level of "domain'.
>    A domain is a short-hand way of referring to all mechanisms used for
>    a common task or provisioning of a particular technology.. In the
>    routing examples we have been using, BGP would be one domain that
>    contains many mechanisms. This is also true for OSPF. The same is

I think many people would have thought that routing was the domain and
BGP was the mechanism. Could we see how some technologies fit into the
hierarchy to make sure that it works? We might need to think harder
about the names of these layers and the number of layers. An example
would also help my understanding of the services layer below which I'm 
also having a hard time visualizing.

>    true in the area of Quality of Service, there are many areas of
>    technology (domains) that could be used to deliver quality of
>    service. Differentiated Services or 802.1p are two examples that have
>    very different mechanisms. Our HVAC MIB module has a single knob for
>    the mechanism that is used to control the climate inside a building.
>    In our case, the desired temperature is the knob which causes fan
>    speed to change.  It is possible to imagine a very different set of
>    technology that instead of using fans, controlled exposure of solar
>    cells to change the temperature. The SNMP infrastructure gives us a
>    number of convenient ways to reference domains though the mapping is
>    not always perfect. These handles include the base OID of a MIB
>    Module or the tables in a MIB Module.
>    Since the OIDs are not necessarily contiguous, several of them may be
>    used to specify a domain. In the future IANA could become a registry
>    for such identifiers.

Why will we need to reference domains? 

This sounds a lot like ifSpecific which turned out to be a poor idea.

>    The Services Layer
>    Some management applications may find it helpful to present one layer
>    of abstraction above the domain level: services. At this layer we no
>    longer refer to specific technologies such as BGP, OSPF, or
>    Differentiated Services. We refer to routing or Quality of Service.
>    This is the layer that many business operate at. One example is that
>    they sell Web or Name services without referencing the specific
>    technology domain that will be used to realize the service. For
>    example, n most circumstances they, will certainly not reference the
>    mechanisms used to realize the Web Services.