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

Re: snmpconf BCP re: policy layering

Comments inline.
> 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.

Thanks, I re-read this section and it seemed quite clear that instance 
independence was explicit in that section. That said, I am happy to modify the 
introductory sentence in that section from:

"In summary, implementation and mechanism specific MIB objects occupy the same 
level of abstraction in our hierarchy."


"In summary, implementation and mechanism specific MIB objects occupy the same 
level of abstraction in our hierarchy and are independent of any specific 
instance in the device."
> 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.

It is at the bottom of the 'abstraction' chain and is presented for 
completeness - it is part of the hierarchy. In a sense the lowest level beyond 
which (at the present time) we can not abstract further. The dictionary uses 
for it's first definition of abstract,

   1 a : disassociated from any specific instance <abstract entity> 

This is what was on my mind when I started this (now nearly two years ago).

> For example, you could say that "ifInErrors" is a mechanism-independent
> abstraction of:
>   Ethernet
>        dot3StatsAlignmentErrors, dot3StatsFCSErrors, 
>        dot3StatsFrameTooLongs, ...
>   Token Ring
>        dot5StatsLineErrors, dot5StatsBurstErrors, 
>        dot5StatsACErrors, ...
>   etc.
> Using ifInErrors gives me the benefits of abstraction in that I don't
> need to understand the details of the mechanism (token ring or
> ethernet).

I think this proposal mixes two concepts that should be separate. What you 
propose and is a great idea for MIB writers is what I would sometimes call 
aggregate objects. In the example above we are aggregating on an interface all 
errors for a particular media type then aggregating it further to a single MIB 
Object - an aggregate object as well that is for the entire machine which is 
the 'total' of all the instances. The second concept, and the one we have 
focused on in this work is the abstraction part of configuration parameters 
which implies a sameness not required of your counter aggregation example. 
That said we do not close the door to the association of aggregates such as 
you propose with mechanisms. In fact this is what I expect will happen when 
people start doing service level reporting using SNMPCONF.

> 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:
>   instance-specific/mechanism-specific:
>       dot3StatsAlignmentErrors.7
>   instance-specific/mechanism-independent:
>       ifInErrors.7
>   instance-independent/mechanism-specific:
>       dot3StatsAlignmentErrors on all trunk ports
>   instance-independent/mechanism-independent:
>       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.

Please see my points above about why I kept instance-dependence as part of the 
layering. It is the bottom. Please also see the point about the dangers of 
mixing non-like things. While such aggregations may be quite helpful (e.g., 
all errors for all media types for all instances controlled by a policy), such 
aggregations while convenience may not always be meaningful.
> >    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.

Implementation specific is to private vendor extension as mechanism-specific 
is to standards body defined.
> >    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.
> Regards,
> Steve
> Steve


Jon Saperia		     saperia@jdscons.com
			     Phone: 617-744-1079
			     Fax:   617-249-0874