CURRENT_MEETING_REPORT_
Reported by Ted Brunner/Tektronix
Minutes of the Interfaces MIB Working Group (IFMIB)
First Meeting
The first meeting of the IFMIB Working Group was held on Tuesday,
18 July.
Implementation experience: Bay Networks, Lannet and Chipcom either do
not yet have implementation experience or it is on their plate. Proteon
will report back later.
_________________________________________________________
| | 1 | 2 | Newbridge |
| | router? | atm switch | FR switch |
|______________|___________|______________|______________|
| ifTable | yes | yes | yes |
| ifXTable | yes | yes | yes |
| 64bit | yes | N/A | N/A |
| ifStack | yes | yes | yes |
| ifRcvAddr | yes | N/A | N/A |
| ifTest | N/A | N/A | N/A |
| linkup/down | | yes | yes |
|______________|___________|______________|______________|
The following problems were reported in using the specification to
implement RFC 1573:
o Some typographical errors, e.g., import counter64.
o Better text is needed about sparse tables.
o More examples and text is needed to explain the allocation of
ifIndex values under error and reboot conditions.
o When a certain case is intended to be disallowed, it is important
to document that rather than having the text silent.
Issues Discussed
o Certain NMS platforms and applications expecting RFC 1213 semantics
break with RFC 1573. Third party apps may break, e.g., allocates
array for interfaces based on ifNumber. ifIndex > ifNumber indexes
out of array. Some cannot handle sparse ifTable, i.e., blanks
between ifIndex values. A version of OpenView for Windows will
break. But it has a bug which is expected to be fixed.
Decision: This cannot be helped. Tell applications developers to
read RFC 1573. Admit that it will break some applications.
o IANAifType values have been added to since RFC 1573 was issued.
This was intent. It was expected that IANA would provide not just
numbers but an ASN.1 module in a easily accessible repository. It
was the intent that the new interfaces document would not have
IANAiftype module in it.
Decision: Ascertain if IANAifType module is available, and if IANA
will make it available at a repository (e.g., venera.isi.edu). If
so, that module will not go into the new document. Provide better
text in the new document for finding module. First try FTP site;
second, ask IANA; third, try mailing list for clarification.
o Reuse of OIDs between RFC 1213 and RFC 1573.
Decision: Further document in 3.2.1 the decision to reuse ifTable
OIDs. Admit it is not optimal. Admit it breaks some NMS
applications. State the choice to deprecate ifTable affects all
existing agents.
Decision: There are ad hoc methods to distinguish RFC 1213 and
RFC 1573 agents. Need not document these.
o Under what conditions does the ifIndex value get reused? Example:
Large switch has ports which get reset either by intervention or in
reboot. The counter values held on the port are zeroed. But
ifTable counters must not decrease. If agent kept counters instead
of swapped out card this is not a problem. Could maintain offset
on agent, and add it to a port's counter value, but then the port
holds different counter values than agent returns. Could assign
new ifIndex to the port.
RFC 1573 says a new ifIndex value should be assigned to avoid a
discontinuity in interface table counters. RFC 1573 and RFC 1213
state there is no persistence of if numbering across reboots.
Proposed: A read-only object (TimeTicks) indicating the sysTime
after which interface counters are valid. If counters were zeroed
by human intervention or hot swapping cards, this object tells when
it happened.
Pro: Clean description.
Con: Need to deprecate existing counters. Need to read timestamp
whenever read counter. Intervention will ``blow away'' other NM
apps reading counters. Some customers seem willing to, but are
there more who would not?
Straw poll taken between keeping existing model, and changing to
new one. Some support for new model. Greater support shown for
keeping existing model.
Decision: Suspend discussion of new proposal, resurrect only if
there is new input. Clarify text of existing model. Consider it
on the list. Make final judgement then.
o The ifStackTable may or may not have explicit top and bottom
layers. While stack is changing, could get ambiguous results with
implied layering.
Decision: Always have explicit top and bottom layers, e.g.,
ifType.1=ethernetCsmacd, ifStackStatus.0.1=active, and
ifStackStatus.1.0=active.
o ifName text is confusing in case of vertical stack of interfaces.
Decision: Provide example in text of case where ifName is not the
same for all interfaces in a vertical stack.
o ifStackTable is organized from top to bottom. Bottom to top
organization is more intuitive in some cases. Agent may organize
itself bottom to top. But agent needs to know entire stack so
cannot avoid constructing it. Manager needs to load entire
ifStackTable to make sense of interfaces, so bottom to top table
would need entire load.
Decision: Do not add bottom to top stackTable.
o ifStackTable can be large, and loading whole thing to ascertain
where there is an interface change can be painful. Proposed: an
indicator of change in stack table, with pointer to where. But may
be several changes so manager cannot avoid loading rest of table.
(Another one of several possible granularities for indicator is for
stackTable as a whole.)
Decision: Do not see sufficient improvement to warrant new
objects.
o Bridge MIB interactions with RFC 1573. Decision: No necessary
changes to bridge MIB seen by existence of RFC 1573.
o Entity MIB interactions with RFC 1573. Decision: No necessary
changes to Entity MIB seen by existence of RFC 1573.
o A configured probe in RMON uses a ``data source OID'' to indicate
where data is to be obtained. It points to an ifIndex. But nv
needs to contain more expressive notion of source that can be
re-pointed if ifIndex value changes. Also, data taken by a probe
is with reference to an ifIndex. After renumbering, this data is
obsolete. But this is the proper behavior when an interface goes
away.
Decision: There are implied problems for RMON because ifIndex does
not have a persistence. But this is understood by RMON Working
Group.
o Various typographical errors concerning ifNumber conformance
statement and ifRecvAddrStatus read/create and ifRecvAddrAddress.
Decision: Keith understands the edits.
Second Meeting
The second meeting of the IFMIB Working Group was held on Thursday,
30 July.
o Currently ifType numbers are being assigned by IANA at request of
(at least) the RFC 1573 editor. There is an IANA Web page of
assigned numbers.
There is no MIB module. Joyce Reynolds received heads up about the
working group's desire for an appropriate posting of our MIB
module.
Decision: The working group chair has an action item to settle
disposition of IANAifTypes.
o ifMTU and other columns. For some interfaces (e.g., LANE client),
these values are unknown by the agent at time of row creation.
Decision: such objects are only instantiated once values are
known, return noSuchInstance prior to that.
o ifIndex values are unique within a context. But are they unique
across contexts? Decision: There is no required correlation of
ifIndex values between Entities. E.g., <ifIndex=1 Entity=1> can be
different than <ifIndex=1 Entity=2>. Supply text to that effect.
o Seeking a unique handle for an interface which is constant across
reboots. ifIndex is unique handle, but is not constant across
reboots.
Is the tuple <ifName ifType> unique? No. Some interfaces do not
have ifName initially (e.g., LANE). The definition of ifName says
there can be vertical stacks of interfaces all with the same name.
Also, load balancing interfaces would naturally have the same
ifName. The definition of ifName states that a zero length string
is sometimes an appropriate value.
There is an overloading in the assignment of ifName: algorithmic
derivation by agent, meaningful name, unique, and possibly
consistent across reboots. This does not work.
More fundamentally, how long must consistency be maintained?
RFC 1573 says between reboots. We are looking at a longer period.
How long? Can ifIndex=1 (for instance) ever be reused then?
Decision: Do we have a constant handle for an interface? No. Can
we find one? Unknown.
o ifAlias was proposed as a r/w object holding key information on the
agent to be shared between NMSs and configuration UIs on the agent.
Example of key use is a circuit number on a D1, phoned to site by
Telco. Size depends on country. 32 digits is sometimes a problem.
64 are OK so far. All proprietary MIBs have such an object --
sometimes it is used to keep notes. ifAlias should be kept in nv
memory. Size of the nv requirements is a problem. Perhaps only
needed by physical links; perhaps a memory pool limit per box is
acceptable. Could leave such function to media-specific MIB.
Decision: Full discussion was cut short. The group feels this is
a useful object. Seems that generic function in interfaces is
right place. Conformance statement should be crafted to limit its
nv requirements.
o ifScratchpad was proposed as a r/w object holding other information
on the agent. Decision: Insufficient support.
o Are there any needs from DS1 MIB rewrite we need to consider?
Conformance categories seem sufficient: ifGeneral and ifStack.
o Are there any needs from character MIB rewrite we need to consider?
RS232 and Parallel port are considered interfaces. A character
stream is not considered a network interface.
o We have no algorithm for determining what is a network interface,
each media-specific MIB working group decides itself. Decision:
Leave decision to media-specific working group.
o notPresent value for interface ifOperStatus? How will NMS behave
differently than if this were ``down''?
o Currently ifEntry has max-access read-only while ifStackTable has
max-access read/write. ifStack access seems broken. Editor feels
the r/w was a typographic error. Could set ifStackTable max-access
to Read/Create or read-only. Three examples where create is
useful: LANE, PPP, DS1 Fractional.
Decision: ifStackTable has max-access of read/create.
o ifTableLastChange proposed to aid NMS in determining whether a
change between reboots. Flagged when an ifTable row added or
deleted. Perhaps unneeded with M2M notifies or linkup/down traps.
But these are not reliable. Decision: Add it.
o ifStackLastChange proposed to aid NMS in determining whether a
change between reboots. Flagged when an ifStack row added or
deleted (synonymous with change in rowstatus) Decision: Add it.
o Read/Write access for ifPhysAddress? Useful for X.25, decnet-style
addresses, some ethernet cards. Decision: Use ifRecvAddr which is
read/create now. Assume you can send with a source address taken
from ifRecvAddrTable.
o If repeaterports are considered interfaces, are there any
repercussions we need to consider? Decision: Need working group
feedback. It does not currently have an interface model.
o TimeStampObject for test result? Support for simultaneous tests on
the same interface? The ifTestTable has no implementation
experience to show. The AToMMIB Working Group an imagine uses for
multiple simultaneous tests. ifTestTable constrained to one test
per interface. It has its roots in the old EtherExtensions MIB.
Decision: Delete the ifTestTable. Consider a generic Test MIB
separate from the interfaces MIB.
Issues Not Considered
o Interface pre-configuration.
o Use temporal domain = next reboot?
o More information when receive ifType = other.