NOTE: This charter is a snapshot of the 41st IETF Meeting in Los Angeles, California. It may now be out-of-date. Last Modified: 12-Feb-98
Chair(s):
Theodore Brunner <ted.brunner@tek.com>
Internet Area Director(s):
Jeffrey Burgan <burgan@home.net>
Thomas Narten <narten@raleigh.ibm.com>
Internet Area Advisor:
Thomas Narten <narten@raleigh.ibm.com>
Mailing Lists:
General Discussion:if-mib@vnd.tek.com
To Subscribe: majordomo@vnd.tek.com
In Body: subscribe if-mib your_email_address
Archive: ftp://thumper.bellcore.com/pub/tob/ifmib
Description of Working Group:
The Interfaces MIB working group is reactivated and chartered to accomplish one task: to prepare a recommendation to the IESG evaluating RFC 1573 with respect to the standards track.
The recommendation will document implementation, interoperability, and deployment experience. If this experiences suggests that changes should be made to the documents, new drafts may be prepared.
The recommendation will report one of four outcomes: that the RFC should be advanced from proposed to draft status, without changes (if no problems are found); that a draft prepared by the working group, should replace the RFC, and be designated a draft standard (if only minor changes are made); that a draft prepared by the working group, should replace the RFC, and be designated a proposed standard (if major changes or feature enhancements are made); or, that the RFC should be designated as historic (if this technology is problematic).
Goals and Milestones:
Done |
|
Issue a call for implementation and operations experience with RFC1573 |
Done |
|
Meet at 33rd IETF to review RFC1573 to ascertain if it is ready to be elevated to Draft Standard status. |
Done |
|
Post a internet-draft of the revised interfaces mib |
Done |
|
Meet at Dallas IETF |
Done |
|
Post a internet-draft of the interface test mib |
Done |
|
Meet at Montreal IETF |
Mar 97 |
|
Submit the interfaces MIB to the IESG for consideration as a Draft Standard |
Internet-Drafts:
· Definitions of Managed Objects for System and Interface Testing
Request For Comments:
RFC |
Status |
Title |
RFC1573 |
PS |
Evolution of the Interfaces Group of MIB-II |
RFC1643 |
S |
Definitions of Managed Objects for the Ethernet-like Interface Types |
RFC1650 |
PS |
Definitions of Managed Objects for the Ethernet-like Interface Types using SMIv2 |
RFC1694 |
DS |
Definitions of Managed Objects for SMDS Interfaces using SMIv2 |
RFC1749 |
PS |
IEEE 802.5 Station Source Routing MIB using SMIv2 |
RFC2233 |
PS |
The Interfaces Group MIB using SMIv2 |
Minutes of the Interfaces MIB (ifmib) Working Group
Reported by the chair, Ted Brunner (Tektronix)
Agenda Bashed
There was concern from Kevin Koenig (Ascend), supported by John Shriver (Shiva), that the interface model does not scale well to several hundreds of interfaces. The case of DS0 was cited. This topic returns below.
I. The Tunnel MIB - Dave Thayler (Microsoft)
The tunnel MIB has been developed with the support and critical oversight of various people working on specific tunnel MIBs (e.g., L2TP MIB) and was presented in the PPP Extensions Working Group. It was thought that the IFMIB working group would be a better administrative home for it.
The OID subtree for the MIB is pointed to by the ifType of tunnel(131), in the same manner as other media specific mibs. The tunnel mib identifies further encapsulations, if any (e.g., none, L2TP, GRE, L2F). (Note that, as of April 6th, IANA had not published the assignment tunnel(131) in the IANAifType module ftp://ftp.isi.edu/mib/ianaiftype.mib)
During Dave's presentation, it was suggested that the method of choosing the value of ifIndex be cloned from the LANE MIB.
The tunnel MIB was accepted as an official draft of the working group, and after the suggested changes are made it can be offered as a proposed standard.
II. Implementation Experience with RFC2233 - Jeff Johnson (Red Back Networks)
On the list, Jeff had pointed out various editorial errors in 2233. These had been noted by the editor.
Jeff pointed out two potential implementation problems with sparse tables.
ifIndex ifName ifInOctets
1 ethernet1 2356
2 serial1 -
... ... ...
257 serial256 -
258 tokenring1 5439
Gotcha 1:
In response to a getnext ifInOctets.1 the agent should not successively call each serial driver (1 - 256) only to discover there is no ifInOctets. The agent should check that ifInOctets exists for the interface before calling the serial driver for a value.
Gotcha 2:
In response to a getnext ifInOctets.1, ifName.1 the agent, after calling the correct driver for ifInOctets, should not use that call for ifName - and return tokenring1.
By way of explaining his implementation concerns, Jeff described the box he worked on. Called a subscriber management system, it accepts parallel frame relay or parallel atm circuits from a digital subscriber line access multiplexor (DSLAM) and creates a circuit to an outgoing frame relay or atm circuit.
Some discussion followed, leading to an accepted interface layering model for this box: -multiple interface stacks (e.g. ppp over atm, ppp over frame relay), -a router with virtual interfaces and physical interfaces (atm and fr), -and a programmable cross connect between the two. With this model, a manageable stacking of interfaces follows, allowing the ifStack table and the interface state to be kept with acceptable complexity.
Discussion followed on the usefulness of the lowerLayerDown state of ifOperStatus. It was accepted as useful.
Discussion followed on the advisability of making a DS0 circuit an interface. Two wg members said they did not do so. It was accepted that 2233 gave sufficient leeway to implementors so that they may make this choice.
Jeff reported that he had implemented 64bit counters and the ifStack ifXTable. He had not implemented write capability, nor the ifRecvAddrTable.
III. Implementation Experience with RFC2233 - Bob Stewart (cisco)
The correct contact person is Sandra Durham who is not yet finished.
IV. Implementation Experience with RFC2233 - Kevin Koenig (Ascend)
The implementation is two months away.
V. Implementation Experience with RFC2233 - Ken White (IBM)
Ken reported that the System 390 implementation includes 64bit counters, particularly with ATM, and the ifStack table, but not the ifRecvAddr table.
VI. Implementation Experience with RFC2233 - Joan Cucchiara (Bay)
The correct contact person is John Seligson. Bay has implemented 64bit counters, the ifStack table and the ifRecvAddr table.
VII. Implementation Experience with RFC2233 - Jeff Case (SNMP Research)
Jeff discussed "open systems" in which a master agent is purchased from one vendor and several interface cards each with a subordinate agent are purchased from other vendors. The prime examples are multihomed Unix and NT systems.
His reasoning goes as follows:
In an open system the ifStack Table is simply not implementable. Such systems are therefor not in compliance with RFC 1573 or 2233. RFP writers generally quote RFC numbers, not conformance statements within the RFC. Given the state of the network management market, we should be making SNMP as market friendly as possible. In general the working group agreed.
Several options were discussed:
- The hard line: ifStack table is useful and open systems are not capable,
- The softy: make ifStack table optional,
- An administrative shuffle: put ifStack in a separate RFC,
- MIB magic: write a new conformance statement.
At the same time the wg also considered an inverse stack table, which reverses the indices of the ifStack table, thereby showing the interface layering from the bottom up. It is a recurring request, and has gained more support. As the number of interfaces increases the advantages of supporting inverse sorting has increased, but the cost of supporting it may increase with large numbers of interfaces.
Several straw polls were taken to assess the feeling of the wg, leading to a first choice and second choice for resolving this.
First choice:
- -Split the document as follows,
- -Remove the ifStack table from the current internet draft,
- -The module name ifMIB remains unchanged,
- -This edited text moves forward to draft standard.
- -Create a second internet draft with the ifStack table,
- -Add the inverse stack table,
- -This new text moves forward to proposed standard.
Second choice:
- -Don't split the document.
- -In the compliance module ifCompliance2, object ifStackStatus, change the MIN-ACCESS to not-accessible,
- -Edit the compliance/conformance appropriately,
- -The module name ifMIB remains unchanged,
- -This edited text moves forward to draft standard.
- -Create a second internet draft with the inverse stack table,
- -This new text moves forward to proposed standard.
The working group chair took the responsibility for speaking with the appropriate area directors to figure out whether we progress with choice one or choice two.
None Received