Subject: dsx0BundleMappedIfIndex became less flexible!

From: Gary Hanson <[email-masked]>
Date: Mon, 2 Mar 1998 19:41:49 -0800 (PST)

Dave, IESG, and other trunk-mib-ers,

I have a substantive comment on draft-ietf-trunkmib-ds0-mib-05.txt.

I believe the current dsx0BundleMappedIfIndex approach is less flexible
than the original suggestion for adding dsx0BundleMappedIfIndex.  Having
this object in a new dsx0BundleMappingTable, and having it indexed by
a ds1 ifIndex and the first ds0 channel number in the bundle limits its
usefulness only to those cases where the manager knows these two values.
It does not help in the following two cases:

- The manager knows a ds1 ifIndex (X) and some ds0 channel number N
  other than the first one in the ds0Bundle, and wants to locate the
  ds0Bundle ifIndex (H) in which the ds0 channel has been bundled.
  With the current definition of dsx0BundleMappedIfIndex, this lookup
  is not made available.  Either the manager has to try lower numbered
  channel numbers, testing each ds0Bundle found to see if it is stacked
  above a ds0 with ifIndex (Y) where dsx0Ds0ChannelNumber.Y equals N,
  or else the manager has to find some other way to locate ds0Bundle
  ifIndex values, and test each of them similarly.

- The manager knows a ds0 ifIndex (X) and wants to locate the ds0Bundle
  ifIndex (H) in which the ds0 has been bundled.  The manager is still
  forced to walk the ifStackStatus attribute looking for entries of the
  form ifStackStatus.H.X, which can be a time-consuming process.  Even
  if the manager first finds the ds1 ifIndex (L) by a table lookup of
  (L = next of ifStackStatus.X) and then finds the DS0 channel number
  (N) via a second table lookup (N = get dsx0Ds0ChannelNumber.X), there
  is no guarantee that this will be the first DS0 channel number, and
  so the first problem mentioned above may still have to be overcome.

Modifying the definition of the dsx0BundleMappedIfIndex to allow for
indexing by the channel number N for ANY ds0 in a ds0Bundle would solve
both problems, but not as efficiently as the original proposal.

I propose removing the current dsx0BundleMappingTable altogether, and
replacing it with the original proposal for dsx0BundleMappedIfIndex, in
which the object is placed directly in the dsx0ConfigTable, and indexed
by ds0 ifIndex.  Here is some SMIv2 for the revised object.  Note that
I have renamed it here as dsx0Ds0BundleMappedIfIndex to avoid confusion
with the current definition for the object of the same spelling.  Both
spellings would be fine with me, although the longer spelling may help
indicate that it is a DS0 to DS0 Bundle mapping that is provided.  I
also fixed the mistaken references of ds0Bundle(80) and ds0Bundle(81)
to be ds0Bundle(82).

          dsx0Ds0BundleMappedIfIndex OBJECT-TYPE
               SYNTAX  InterfaceIndexOrZero
               MAX-ACCESS  read-only
               STATUS  current
               DESCRIPTION
                      "This object indicates the ifIndex value assigned by
                      the agent for the ds0Bundle(82) ifEntry to which the
                      given ds0(81) ifEntry may belong.

                      If the given ds0(81) ifEntry does not belong to any
                      dsx0Bundle(82) ifEntry, then this object has a value
                      of zero.

                      While this object provides information that can also
                      be found in the ifStackTable, it provides this same
                      information with a single table lookup, rather than
                      by walking the ifStackTable to find the possibly
                      non-existent dsx0Bundle(82) ifTable entry that may
                      be stacked above the given ds0(81) ifTable entry."
              ::= { dsx0ConfigEntry 8 }

With an object of this semantics, the capabilities provided by the
current definition of dsx0BundleMappedIfIndex would still be possible
with a predetermined number of get operations, namely two.  In other
words, instead of mapping from ds1 ifIndex X and FIRST ds0 channel
number N to ds0Bundle ifIndex H in one step:

        get H = dsx0BundleMappedIfIndex.X.N

the manager could do the same thing for ANY ds0 channel number in the
ds0Bundle in two steps:

        get Y = dsx0ChanMappedIfIndex.X.N
        get H = dsx0Ds0BundleMappedIfIndex.Y

As a test of the sufficiency of the current MIB objects, I listed the
mappings that a manager might want to perform involving interfaces and
channel numbers.  Here are the three common mappings I thought of:

- For a given ifEntry X, find its corresponding channel number N.

  This is usually a trivial SNMP get operation of a single attribute.

- For a given ifEntry X and channel number N, find the higher ifEntry H
  that is stacked above ifEntry X.

  This can be an arduous, time-consuming process for the manager, unless
  it maintains a complete cache of the interfaces.  This is the type of
  mappings for which it is important to have optimal instrumentation.

- For a given ifEntry X, find the lower ifEntry L that is stacked below
  ifEntry X.  A ds0Bundle ifEntry X may have multiple such lower
  ifEntries.

  This is usually a simple SNMP get-next operation

Here is what I found in trying to do this mappings using the current
MIB objects.  Note that for some mappings there are at least two
possible techniques.  In these cases, I listed the unoptimized technique
first, followed by an optimized technique that we either have provided
(or should provide).  In some cases, the optimized technique would have
to involve the standardization of an ifInverseStackTable, which would
provide the same information as in the IF-MIB's ifStackTable, but in an
inverted manner, indexed first by the lower ifIndex followed by the
higher ifIndex.  Such a table would facilitate finding the mapping(s)
from an interface to the interface(s) stacked on top of it, which would
currently require walking the ifStackTable looking for entries of the
form ifStackStatus.H.X, where X was the ifIndex of the known lower
interface.

For a given ifEntry X, find its corresponding channel number N.

ifType of X   Possible technique(s)
------------  ------------------------------------------------------

ds0Bundle     N/A

ds0           N = get dsx0Ds0ChannelNumber.X

ds1 (DS1/E1)  N = get dsx1Ds1ChannelNumber.X
              (this would be either a channel number within a DS3/E3,
              or a channel number within a DS2/E2)

ds1 (DS2/E2)  N = get dsx1Ds1ChannelNumber.X

ds3 (DS3/E3)  N/A

For a given ifEntry X and channel number N, find the higher ifEntry H
that is stacked above ifEntry X.

ifType of X   Channel N    ifType of H   Possible technique(s)
------------  -----------  ------------  ----------------------------------

ds0Bundle     N/A          (various)     walk for ifStackStatus.H.X
                                             or
                                         H = next of ifInverseStackStatus.X
                                         (a non-standard technique)

ds0           N/A          (various)     walk for ifStackStatus.H.X
                                             or
                                         H = next of ifInverseStackStatus.X
                                         (a non-standard technique)

ds0           N/A          ds0Bundle     walk for ifStackStatus.H.X
                                             or
                                         H = get dsx0BundleMappedIfIndex.X
                                         (was original proposed technique)

ds1 (DS1/E1)  1..24/0..31  ds0           walk for all ifStackStatus.H.X and
                                         test each dsx0Ds0ChannelNumber.H
                                         to see if it equals N
                                             or
                                         H = get dsx0ChanMappedIfIndex.X.N

ds1 (DS1/E1)  1..24/0..31  ds0Bundle     H = get dsx0BundleMappedIfIndex.X.N
                                         (this only works for the first ds0
                                         channel number N in the ds0Bundle)
                                             or
                                         use combinations of two techniques
                                         listed above to map from ds1 to
                                         ds0, then from ds0 to ds0Bundle:
                                         Y = get dsx0ChanMappedIfIndex.X.N
                                         H = get dsx0BundleMappedIfIndex.Y

ds1 (DS2/E2)  1..4/1..4    ds1 (DS1/E1)  walk for all ifStackStatus.H.X and
                                         test each dsx1Ds1ChannelNumber.H
                                         to see if it equals N
                                             or
                                         H = get dsx1ChanMappedIfIndex.X.N

ds3 (DS3/E3)  1..28/1..16  ds1 (DS1/E1)  walk for all ifStackStatus.H.X and
                                         test each dsx1Ds1ChannelNumber.H
                                         to see if it equals N
                                             or
                                         H = get dsx1ChanMappedIfIndex.X.N

ds3 (DS3/E3)  1..7/1..4    ds1 (DS2/E2)  walk for all ifStackStatus.H.X and
                                         test each dsx1Ds1ChannelNumber.H
                                         to see if it equals N
                                             or
                                         H = get dsx1ChanMappedIfIndex.X.N

For a given ifEntry X, find the lower ifEntry L that is stacked below
ifEntry X.  A ds0Bundle ifEntry X may have multiple such lower ifEntries.
Note that stacking ds1 and ds3 interfaces on top of higher tributary
interfaces (e.g., sonetVT), while not excluded, is not considered here.

ifType of X   ifType of L   Possible technique(s)
------------  ------------  ----------------------------------------

ds0Bundle     ds0           walk for all ifStackStatus.X.L

ds0           ds1 (DS1/E1)  L = next of ifStackStatus.X

ds1 (DS1/E1)  ds1 (DS2/E2)  L = next of ifStackStatus.X

ds1 (DS1/E1)  ds3 (DS3/E3)  L = next of ifStackStatus.X

ds1 (DS2/E2)  ds3 (DS3/E3)  L = next of ifStackStatus.X

Eventually it would be helpful to have an ifInverseStackTable, with an
ifInverseStackStatus attribute to do the inverse mapping from low to
higher interfaces.  This could be added to the IF-MIB at some point.

I have some other editorial comments on the various trunk-mib drafts
(DS3-MIB, DS1-MIB, DS0-MIB, and DS0BUNDLE-MIB), but I have not yet typed
them up.  They are not major, and only clear up some errors that might
confuse the reader.  However, I wanted to get this comment sent out as
early as I could, so I'll send this without further delay.
 
Regards,
Gary

 ______
| ///  |       TM   Gary Hanson                [email-masked]
|   ADC|Kentrox     14375 NW Science Park Dr.  503-641-3321 (FAX)
|______|            Portland, Oregon  97229    800-733-5511 x6333

---

From: Fred Baker <[email-masked]>
Date: Tue, 3 Mar 1998 09:29:51 -0800

>I have a substantive comment on draft-ietf-trunkmib-ds0-mib-05.txt.

DS0 MIB has been under development for nearly two years now, and has been
somewhere between the working group and the IESG for about a year. You have
not brought this to the working group before.

Are you saying that now, all of a sudden, you can't live with it? Now, in
the second IETF last call, you need substantive changes?

How important is this?

>early as I could, so I'll send this without further delay.

WRITE THEM UP! You have had *years* to comment on them, and you have been
active on the list to make your comments known.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
	If at first you don't succeed, call it version 1.0.

---

From: Fred Baker <[email-masked]>
Date: Tue, 3 Mar 1998 09:29:51 -0800

How important is this?

---

From: Gary Hanson <[email-masked]>
Date: Thu, 5 Mar 1998 17:26:38 -0800 (PST)

Fred,

The comments I already sent in express my concern about something that
was added in the most recent draft document for the DS0-MIB and the
DS0BUNDLE-MIB.  The things that were added had been based on proposals
from myself from several weeks earlier, mostly relating to providing a
mechanism for SNMP managers to overcome a shortcoming of the ifStackTable
(the fact that it is easy to traverse from higher to lower interfaces,
but considerably more difficult to traverse from lower to higher
interfaces).

I personally could live without those enhancements.  However, I believe
that they help make the DS0-MIB and DS0BUNDLE-MIB much more usable, and
defining them in a standard way would facilitate usage of a common
mechanism.  I also believe that the original proposal was more flexible
than what Dave had actually editted into the ds0-mib-05 draft.

The other comments on the various trunk-mib WG drafts (which I have
written up and will send promptly) reflect my opinion of what substantive
improvements (all minor) and editorial improvements could be made within
the last call process of the drafts, and in no way reflect a belief that
the working group has to go through another process of rehashing.

All I can say is that I have written some lists of items that I think
could bear some improvement.  If the IESG wants to see the improvements
made today, I can support that decision.  If the IESG wants to keep the
lists for future consideration for the next round of trunk-mib WG document
advancements, I would be disappointed, but I could certainly understand
the motivation for postponing the changes.  All I can say is take a look
through the comments and see whether you think they need to be addressed 
now, in the future, or never.

I appreciate the sense of urgency, but I thought that a last call was to
ask for any outstanding comments, whatever they may be, from whomever may
produce them, and regardless of whether they had a chance earlier to make
such comments.

Regards,
Gary

---

From: Gary Hanson <[email-masked]>
Date: Thu, 5 Mar 1998 17:26:38 -0800 (PST)

Fred,

Regards,
Gary

---

From: Fred Baker <[email-masked]>
Date: Thu, 5 Mar 1998 22:16:28 -0800

Tom, it sounds like we'll have to take all those documents back until we've
sorted out Bob's concerns. We'll run a working group last call and ask for
another network management directorate review prior to requesting another
IETF last call.

---

From: Fred Baker <[email-masked]>
Date: Thu, 5 Mar 1998 22:16:28 -0800