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., can be different than . 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 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.