Subject: ifmib working group update

From: Ted Brunner <[email-masked]>
Date: Fri, 13 Mar 1998 16:25:40 -0800

This is an update on the if-mib working group.

The test mib (draft-ietf-ifmib-testmib-03.txt)
has been recommended to the Area Director for
promotion to proposed standard.  There had been
no negative discussion of it since I last brought
up the issue (nor any other discussion.)

RFC 2233 was issued in November as proposed standard,
and the first opportunity for it to be promoted to
draft standard would be in May.  Identifying
implementations is one item of business.
There have been some recent messages about issues and
problems with 2233 which were shaken out by implementation.
None appear very big.

At this point, I don't see enough business that must be conducted
face to face in order to warrent a meeting in LA,
(taking into account the crowded schedule there.)

The meeting slot which I reserved just in case,
will be released - provided the working group agrees.

If I'm forgeting something please bring it up.

Ted Brunner		Video and Networking Division
			Tektronix
			MS 50-490
[email-masked]	14150 SW Karl Braun
503.627.1317		Beaverton OR 97005

---

From: Gary Hanson <[email-masked]>
Date: Mon, 16 Mar 1998 09:06:56 -0800 (PST)

Ted and if-mib WG,

One issue that I raised recently in the context of the trunk-mib WG
documents relates to the ifStackTable.  I would assume that it had
been discussed on this list before, but I'll risk raising it again.

For managers that do NOT keep full copies of the polled objects from
the managed entities (e.g., copies of everything reported in the
ifTable, ifXTable, ifStackTable, etc.), but which NEED to traverse
up and down the stacked interfaces, the ifStackTable has somewhat of
a shortcoming: it can be traversed easily (by walking) from higher
to lower level interfaces, but it cannot always be so easily traversed
from lower to higher level interfaces.  This is, of course, because
the ifStackEntry is INDEXed first by ifStackHigherLayer and second by
ifStackLowerLayer.  Walking over ifStackStatus.H will find all of the
ifStackStatus.H.Lx entries, but walking over ifStackStatus.Hx.L would
presume that the manager already knows the value(s) of Hx that apply,
which isn't the case when the manager is trying to learn which higher
layer interface(s) are stacked on top of a given interface.

This may not be a problem for managed entities that have few interfaces
to be modeled, but it can lead to inefficiencies when there are dozens,
or hundreds, or even thousands of interfaces in the ifTable, with lots
of these interfaces stacked on top of and beneath each other.  A common
example would be to find the interface(s) that may be stacked above a
given physical layer interface.

In these cases, the manager that "knows" a lower interface ifIndex value
L and wishes to "learn" the higher interface ifIndex value(s) H1..Hn
is forced to walk the entire ifStackStatus attribute, searching for such
entries that are indexed as ifStackStatus.Hx.L.  This MIB walk would
need to traverse the entire ifStackStatus column (worst case) to find
all higher level interfaces, and on average would need to traverse half
of the ifStackStatus column to find the single higher interface stacked
on top of a given interface.  At low SNMP bandwidths, or with somewhat
large tables, this could render some common management operation to be
perceived to be "SLOW", since the manager must do lots of walking.

I am curious to know whether there is any interest in adding a second
"inverted" interface stack table to the IF-MIB, with exactly the same
semantics as the existing ifStackTable, but with the INDEX elements
reversed.  Such an ifInverseStackTable could be quite useful in such
situations as I have described, and might be worthy of being put in
the standard IF-MIB.

I am conscious of the desire to progress the IF-MIB to draft standard
maturity level, so I would want to be sure that such an enhancement,
if desired, would not endanger us having to spin the IF-MIB at proposed
standard one more time.  There seems to be allowance for such "minor
changes" even at that point, so I am not sure it would necessarily be
an issue.

Note that the trunk-mib WG chose to add several objects to their MIBs
to facilitate lower to higher level interface traversals.  However,
these MIBs also needed special treatment, since the interfaces that
were stacked also involved channel numbers, which were usually part of
the stack traversal that needed to be optimized.

Comments?

Regards,
Gary

P.S.

I am also curious why the ifStackHigherLayer and ifStackLowerLayer
objects were defined to be Integer32 instead of InterfaceIndexOrZero.
Was this just an oversight, or was there some intended but unstated
purpose for negative INDEX values?  Could this "legally" be changed
to InterfaceIndexOrZero, assuming that was the original intent and
the current actual usage?

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

---

From: Keith McCloghrie <[email-masked]>
Date: Tue, 17 Mar 1998 00:25:06 -0800 (PST)

Gary,

While the number of ifIndex values has been relatively small, the
extra expense of an "ifInverseStackTable" did not seem necessary.
As you point out, with the use of individual ifIndex values for each
DS0 channel within a DS1, and each DS1 channel in a DS3 (similarly,
the equivalent E1/E3 channelization), the table now has a lot greater
benefit.  Although it is perhaps still only necessary for particular
types of interfaces, or for a significant number of interfaces.  At
this stage, unless the Area Director can provide assurances on it
not affecting the IF-MIB's promotability, I would suggest that the
addition of this new table be in a new MIB.

Keith.

PS. Wrt. why ifStackHigherLayer and ifStackLowerLayer have syntax of
Integer32 (instead of InterfaceIndexOrZero), they were defined in 1573,
and InterfaceIndexOrZero was not defined until 2233, and of course,
changing the syntax of an existing MIB object is illegal.

---

From: Jeff Johnson <[email-masked]>
Date: Tue, 17 Mar 1998 10:14:04 -0800

>If I'm forgeting something please bring it up.

I think discussion of implementation issues is worthy of a meeting slot.
However, I do agree that we probably don't need a 2 hour slot.  Perhaps we
could swap for one of the many 1 hour slots apparently still available on
Tuesday?

/jeff