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

snmpconf BCP taxonomy with atomic/expansion attributes--proposal

I've been discussing the BCP taxonomy conundrum with a variety of people on 
the list, and as is to be expected, the BGP co-authors most of all.  I'd 
like to advance a possible advancement of the model to cover some of the 
ground that I think I've heard Steve {w} (future references to "Steve" 
herein resolve to Steve {w}, although Steve Moulton's input is eagerly 
solicited :) express concerns about.

While I am going to attempt to be very specific at the risk of overkill of 
concepts in this discourse, I am going to start by attempting *really* 
concise (for me :) definitions of the two perspectives that appear to be 
calling for reconciliation.

A number of terms have been coined in the last week to describe the same 
basic notion-- "scope of applicability" (Bob Moore), "localization" (Jon 
Saperia), or "content scope" (mine).  Without belaboring a definition 
again, one important characteristic these notions share is the proximity of 
the end result of policy application to the highest-level default behavior, 
where "highest-level" can be defined by levels of the taxonomy.

Another analysis (one which I think is closer to Steve's) has the primary 
view of policy being a set of values, and the essential thing for a 
taxonomy in this view is to define the relative placement of those values 
in an information model, from the most abstract to the most 
instance-specific or mechanism specific.  This covers not only the modeling 
of policy-settable-values specifically, but in fact the information scope 
of the models used to, for example, be reflected in the scope of the 
pmTrackingPEElement associated with a policy.

Now, one can with relative ease drift into a conceptualization where these 
two perspectives and priorities intersect more than a bit.  To lift from 
snmpconf, the "scope of applicability" approach for a policy is reflected 
in a very clear MIB object operand terms in the pmRoleElement governing its 
element applicability.  Alternately, the MIB objects of interest may be 
reflected in the "applicability scope" as reflected in reported 
pmCapabilities entries.

What these concepts are all pointing to is the property of the application 
of some rule or algorithm that dictates which values of of a number of 
potential values in a policy are applied to an object. For example, if we 
have several policies for how BGP is configured, each policy might contain 
the full set of parameters to fully specify how BGP peers are to relate to 
each other, like time out values. Clearly we can not apply two different 
time out values to the
same BGP peer, we have to select which of the policies to apply to it. That 
is what localization or scope of applicability is about. We decide which 
values a given BGP peer is to have based on some set of rules. We might 
have one set for BGP peers that are speaking with poorly behaved systems 
and another for those speaking to well behaved ones. There could be yet 
another class that have 'hard wired' values for a specific peer that will 
not be overruled by either of the policies.

Ultimately, what underlies both approaches to the essence of policy 
layering, from the point of view of an effective taxonomy, is (at the end 
of the day)

   -- what is the level of "defaulting" or templatization of controls as
      set or accessed by a policy as opposed to its instance-level (or 
      specific) specialization?  Herein, a service-level-broad specification
      would be the most "default"'ed thing of all, whereas the derivation of
      dot3AlignmentErrors for a specific interface on a LAN switch in
      Sheboygan would be the most instance-specific. Overall, defaults as
      a term embodies expansion along lines of mechanism or implementation, but
      the term seems more generally understood outside of this taxonomy.

   -- If "expansion" is the correct term to define going from predominantly
      defaulted (in the terms of the preceding definition) data or
      operational scope to its predominantly instance-specific derivation,
      what is the "flow" and governing characteristics of that expansion for
      an application?

To be sure, in the cold light of day, any application of policy will result 
in the analysis or application of values at the level of the lowest 
granular instance of interest (interface-level, most likely), but the 
characteristics of interest are in the expansion, since different policy 
architectures specify different means of handling this.  A primary goal of 
the SNMPCONF work is the avoidance of sending 'instance' level objects to a 
device in favor of having that instance level expansion take place in the 
device. But regardless, what a policy does is to apply defaults and 
instance-refinements from defaults to instances on a box.  Agreed?

So, to forge ahead, we have inherently clear points of agreement.  We have 
the object definitions (MIB Objects) and instances of them. This part is 
clear, and, I think, not contentious. In a sense you could think of them as 
Classes and instantiations of those classes.

Secondly, we have agreed that there is a hierarchy of abstraction. This 
trails the path of expansion as defined above.

What we'd seek to do is to accomodate the unique identification of the 
relative levels of this expansion, whether it is most pertinently at 
the  instance level or "dimension" as Steve has suggested or throughout the 
entire taxonomy (in an earlier mail, Steve was drawing this in fact as a 
two-dimensional matrix at its most applied, of 
mechanism-dependent/independent vs. instance dependent/independent).

To scale the requirements of managed-object-scope-identification, another 
important characteristic of any abstraction successful for this application 
is the identification of those elements which can directly map to discrete 
defaultable or refinable *objects*.  This is as opposed to those elements 
serving as, for lack of a better word, containment abstraction for many 
such instantiable objects.  This second group of element is unable to be 
directly set or queried).

This sounds much more complicated than I'm trying to make it.  To return to 
a prior example to illustrate this point, bgpHoldTimeConfigured can be on a 
"physical instance", and "The BGP Configuration" can be on a "physical 
instance"--SO, in one sense both are fully expanded.  However, clearly, 
expansion along a different plane must occur to expand "BGP" to 
bgpHoldTimeConfigured and about 60 other such atomic properties "contained" 
in non-atomic object "BGP".

What we have then, are instances of implementation or mechanism-specific 
objects that are differentially applied to  'instances' of the controlled 
element in the box such as the instance of a specific 
bgpPeerKeepAliveConfigured value (an instance of a mechanism specific 
object) applied to specific BGP peers, as a byproduct of their 'BGP' 
instance (which is itself not-instantiable without **expansion** into 
elements the likes of bgpPeerKeepAliveConfigured).

We are quickly approaching the need for a new term to represent what we 
mean. Jon has suggested 'atomic', based on something that emerged in a 
discussion with Steve. (This also has the benefit of not confusing itself 
with 'instance' as it shows up with subtly different meaning elsewhere 
across the  network management phylogeny). That is something that for 
practical purposes would not be further refined or expanded. Ultimately, a 
top level analysis yields service level objects on a device that deal with 
the entirety of the device.  Yet, a given hierarchical level may have 
elements which are atomic, and others which can/may/must be expanded at 
lower levels in the hierarchy--*except* for the atomic level, where further 
decomposition is, by definition, not possible.  To represent as a grid:

    Class Category               Default          Atomic      Can be
                                                              expanded to
                                                              a lower
Service                            X                 X          X

Domain                             X                 X          X

Mechanism                          X                 X          X

Implementation                     X                 X          X

Atomic                                               X

The process of expansion-to-atomic takes place across two dimensions.  One 
is organizational and conceptual.  Routing is an example. At lower levels, 
BGP, a domain level object would required peer and path attribute mechanism 
objects to be supplied before we could configure specific instances of 
peers in the
router. It is this expansion principle that we should also convey. One
of the reasons that this is so important is that management software has
a significant challenge to 'localize' these transformations on the way
down to the atomic level objects.  For example, if we were configuring
DNS, the defaults might be different for devices on one side of the
Mississippi or the other. The DNS defaults might be further refined on
the expansion downward by other considerations of model, vendor,
etc. etc.

The other axis is more consistent with the traditional notion of 
localization-by-instance and is as much physical (or, at least, 
object-corporeal) as conceptual.  To continue with the routing example, we 
could have an
object such as ifInErrs and have a single atomic instance of it in a
managed device. In a sense it is a service level object. It is the case
that for most of the systems I know, there would be a single 'instance'
of it in a managed device.   On the other hand, the expansion of ifInErrs 
to this level of instance-contaimnent is independent of the fact that it 
organizationally needs to expand to dot3StatErrs, dot3StatsAlignmentErrors, 
dot3StatsFCSErrors, dot3StatsFrameTooLongs and so forth seemingl ad 
infinitum. :)

I should probably stop here and ask if the notions of

  -- expansion
  -- atomic object identification
  -- expansion across two dimensions

are deemed usable.  Obviously, the above rambles a fair amount and is not 
representative of how we'd attempt to represent these ideas exactly in the BCP.

Thanks for listening,


Wayne F. Tackabury              Internet: wayne@goldwiretech.com
Gold Wire Technology            Phone: (781) 398-8819
411 Waverley Oaks Rd., Ste 304
Waltham, MA  02452             Cell: (617) 699-6156