Received: from cnri by ietf.org id aa26788; 12 Feb 97 19:01 EST Received: from inet2.tek.com by CNRI.Reston.VA.US id aa23098; 12 Feb 97 19:01 EST Received: from bocote.vndad.tek.com by inet2.tek.com id ; Wed, 12 Feb 1997 15:45:01 -0800 Received: (from daemon@localhost) by bocote.vndad.tek.com (8.7.5/8.7.3) id PAA13813 for if-mib-outgoing; Wed, 12 Feb 1997 15:44:58 -0800 (PST) Received: from icebox.vndad.tek.com (icebox.vndad.tek.com [128.181.120.101]) by bocote.vndad.tek.com (8.7.5/8.7.3) with ESMTP id PAA13807; Wed, 12 Feb 1997 15:44:57 -0800 (PST) Received: from icebox (localhost [127.0.0.1]) by icebox.vndad.tek.com (8.7.5/8.7.3) with ESMTP id PAA03425; Wed, 12 Feb 1997 15:52:01 -0800 (PST) Message-Id: <199702122352.PAA03425@icebox.vndad.tek.com> To: if-mib@bocote.vndad.tek.com Cc: tedb@vndad.tek.com Subject: implementation reports From: Ted Brunner Date: Wed, 12 Feb 1997 15:52:01 -0800 Sender: if-mib-owner@vndad.tek.com Precedence: bulk In a previous message I requested implementation reports from the wg. These are necessary to promote this Internet Draft to RFC status, and in particular to draft standard. As of now, I have one report (it was very prompt) and one promise. Please take the time to report on your companies implementation of the interfaces mib. Send reports directly to me, or to the list, preferably with a subject heading mentioning implementation. If you ask me to, I will keep the info you send to me anonymous. Ted Brunner Video and Networking Division Tektronix MS 50-490 ted.brunner@tek.com 14150 SW Karl Braun 503.627.1317 Beaverton OR 97005   Received: from cnri by ietf.org id aa18469; 13 Feb 97 18:52 EST Received: from inet2.tek.com by CNRI.Reston.VA.US id aa07873; 13 Feb 97 18:52 EST Received: from bocote.vndad.tek.com by inet2.tek.com id ; Thu, 13 Feb 1997 15:33:09 -0800 Received: (from daemon@localhost) by bocote.vndad.tek.com (8.7.5/8.7.3) id PAA15528 for if-mib-outgoing; Thu, 13 Feb 1997 15:33:06 -0800 (PST) Received: from tektronix.tek.com (tektronix.tek.com [134.62.8.103]) by bocote.vndad.tek.com (8.7.5/8.7.3) with ESMTP id PAA15522 for ; Thu, 13 Feb 1997 15:33:04 -0800 (PST) Received: from inet1.tek.com (inet1.tek.com [134.62.48.21]) by tektronix.tek.com (8.7.5/8.7.3) with SMTP id PAA23959 for ; Thu, 13 Feb 1997 15:32:58 -0800 (PST) Received: from mailhost1.BayNetworks.COM by inet1.tek.com id ; Thu, 13 Feb 1997 15:32:53 -0800 Received: from ns1.BayNetworks.COM ([134.177.1.107]) by mailhost1.BayNetworks.COM (8.8.3/BNET-96/12/06-E) with ESMTP id PAA07778; Thu, 13 Feb 1997 15:32:46 -0800 (PST) for Received: from pobox.engeast.BayNetworks.COM (pobox.corpeast.baynetworks.com [192.32.151.199]) by ns1.BayNetworks.COM (8.8.3/BNET-97/01/07-I) with ESMTP id PAA23250; Thu, 13 Feb 1997 15:32:43 -0800 (PST) for Posted-Date: Thu, 13 Feb 1997 15:32:43 -0800 (PST) Received: from torino.engeast (torino [192.32.243.128]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-SVR4-S) with SMTP id SAA15526; Thu, 13 Feb 1997 18:32:45 -0500 for Received: from torino (localhost) by torino.engeast (4.1/SMI-4.1) id AA09567; Thu, 13 Feb 97 18:32:44 EST Message-Id: <3303A49B.6201DD56@BayNetworks.com> Date: Thu, 13 Feb 1997 18:32:43 -0500 From: Jonathon Madsen X-Mailer: Mozilla 2.0 (X11; I; SunOS 4.1.3_U1 sun4m) Mime-Version: 1.0 To: if-mib@vndad.tek.com Subject: Bay Networks' rfc1573 implementation Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: if-mib-owner@vndad.tek.com Precedence: bulk Bay Networks has an implementation of the evolved ifTable. We have implemented all objects except for those of type Counter64, ifTestTable and ifRcvAddressTable. We do not supports sets to the ifPromiscuousMode, ifAlias, ifStackStatus objects. We do support sets to ifAdminStatus and ifLinkUpDownTrapEnable for some interfaces. This implementation will roll out with new product and software releases over the next year. The text below details some of the implementation experience for this MIB. The target platforms for this implementaion presented some unique challenges to the development of an evolved ifTable. Specifically, the platforms may include scattered counter support, dynamic software recovery, mapping to physical issues, symmetric multi-processing, and multi-line interfaces. - Scattered counter support. In our implementation, multiple embedded applications may support different portions (columns) of the ifEntry and ifXEntry rows. As embedded applications may provide or withdraw support for columns of a row at any time, some compliance "policeing" was required. In order to ensure that compliance groups were supported atomically, logic was added to "hide" incomplete rows until all the relevent columns were supported. Additionally, if multiple applications provide support for the same object instance, our implementation must aggregate object values during method requests. - Dynamic software recovery. As applications and counter support may come and go independently, the ifCounterDiscontinuityTime object became invaluable. This reduced the number of conditions under which a new ifIndex value had to be re-assigned. Another by-product of this behavior is the impact to maintaining ifOperStatus throughout a stack. When layers below an interface row change status it is sometimes required to change the ifOperStatus of the interface row above those layers. Properly handling this situation can become resource intensive if some interfaces are frequently "bouncing". - Mapping to physical. As ifIndex is not guarenteed to represent any information about the physical location of an interface, our implementation returns a non-volatile tag in ifAlias. this tag can be parsed to determine the physical location of an interface if a connector is present. Future plans are to support the entAliasTable to represent this mapping. - Symmetric multi-processing. Our system architecture consists of several "slots" running independently of one another. It was necessary for us to come up with a scheme to arbitrate the ifIndex space across all slots. It is worth noting that the collection of slots is veiwed as a single agent. In order to do this, we needed to implement an index server to distribute unique indices as interfaces were created. Initially, ifIndices are contiguous from 1 to ifNumber but are not guarenteed to remain so when perturbed by hot swap, reconfiguration, etc. - Multi-line interfaces. We also had to address the issue of associating interfaces with the layer three applcations. For example in the using the ipAddrTable to correlate an IP interface to a ethernet interface is relatively straightforward. However, if under that IP interface you have multiple interfaces ( multi-line, load sharing etc. ) there needs to be a way to associate that IP interface with multiple physical interfaces below it. The approach we took was to add another row of type propVirtual above the multiple ethernet interfaces. The ifIndex of this propVirtual row then became the one that was associated with the IP interface thus transferring the responsibility of correlating an IP address to an actual physical interface to the NMS. The NMS is required to traverse the ifStackTable to obtain this information. We have not yet done exhaustive testing against a large sample of management applications. We may run into some of the same issues that Scott Mordock reported from the Cisco implementation (sparse tables, etc.) in which case adding a few switches which make the ifTable more friendly is easily accomplished. It would be nice to hear from NMS application vendors that are preparing to handle the evolved ifTable.   Received: from cnri by ietf.org id aa09765; 15 Feb 97 11:19 EST Received: from inet1.tek.com by CNRI.Reston.VA.US id aa15384; 15 Feb 97 11:19 EST Received: from bocote.vndad.tek.com by inet1.tek.com id ; Sat, 15 Feb 1997 08:02:46 -0800 Received: (from daemon@localhost) by bocote.vndad.tek.com (8.7.5/8.7.3) id IAA18405 for if-mib-outgoing; Sat, 15 Feb 1997 08:02:43 -0800 (PST) Received: from tektronix.tek.com (tektronix.tek.com [134.62.8.103]) by bocote.vndad.tek.com (8.7.5/8.7.3) with ESMTP id IAA18399 for ; Sat, 15 Feb 1997 08:02:40 -0800 (PST) From: kennethw@vnet.ibm.com Received: from inet2.tek.com (inet2-en1.tek.com [134.62.8.58]) by tektronix.tek.com (8.7.5/8.7.3) with SMTP id IAA29471 for ; Sat, 15 Feb 1997 08:02:39 -0800 (PST) Received: from VNET.IBM.COM by inet2.tek.com id ; Sat, 15 Feb 1997 08:02:38 -0800 Message-Id: <199702151602.IAA11539@inet2.tek.com> Received: from RALVM12 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 9517; Sat, 15 Feb 97 11:02:34 EST Date: Sat, 15 Feb 97 10:57:57 EST To: if-mib@vndad.tek.com Subject: IBM TCP/IP for MVS RFC1573 implementation Sender: if-mib-owner@vndad.tek.com Precedence: bulk The IBM TCP/IP for MVS product has implemented the February 22 1996 version of the ifMib (draft-ietf-ifmib-mib-03.txt). We continued to support those objects that were previously defined by RFC 1213 and implemented the ifXTable and ifStackTable. We didn't implement the ifRcvAddressTable. The ifStackTable was useful in showing the relationship between interfaces. We have propVirtual interfaces that are stacked above physical. The ifStackTable provides a method of showing this relationship without resorting to use of ifIndex sequences. The ifXEntry provides addition useful information. ifName and ifLinkUpDownTrapEnable are very useful. The HC counters are nice but can be painful to implement. Didn't do anything with ifStackLastChange in the ifStackTable since the subagent (we use DPI, RFC1592, as our subagent technology) that is responsible for these objects has no idea when an interface entry was changed nor for that matter its relationship to sysUpTime. sysUpTime is ugly when implementing subagents and an actual interface layer than run asynchronous to a SNMP agent. I do agree with the comments made to the mailing list that its too late to change. In general, the ifMib is very useful and well written. We hope to implement the new version of the ifMib once it becomes a proposed standard. Ken White   Received: from cnri by ietf.org id aa07730; 16 Feb 97 10:10 EST Received: from inet1.tek.com by CNRI.Reston.VA.US id aa11483; 16 Feb 97 10:10 EST Received: from bocote.vndad.tek.com by inet1.tek.com id ; Sun, 16 Feb 1997 06:57:32 -0800 Received: (from daemon@localhost) by bocote.vndad.tek.com (8.7.5/8.7.3) id GAA19026 for if-mib-outgoing; Sun, 16 Feb 1997 06:57:29 -0800 (PST) Received: from tektronix.tek.com (tektronix.tek.com [134.62.8.103]) by bocote.vndad.tek.com (8.7.5/8.7.3) with ESMTP id GAA19020; Sun, 16 Feb 1997 06:57:28 -0800 (PST) Received: from inet1.tek.com (inet1.tek.com [134.62.48.21]) by tektronix.tek.com (8.7.5/8.7.3) with SMTP id GAA11630; Sun, 16 Feb 1997 06:57:26 -0800 (PST) Received: from rnd-gate.rad.co.il by inet1.tek.com id ; Sun, 16 Feb 1997 06:57:19 -0800 Received: from smtp-gateway.rad.co.il ([176.189.111.1]) by rnd-gate.rad.co.il (8.7.3/8.7.3) with SMTP id QAA18785; Sun, 16 Feb 1997 16:47:01 +0200 (IST) Received: by smtp-gateway.rad.co.il with Microsoft Mail id <33072047@smtp-gateway.rad.co.il>; Sun, 16 Feb 97 16:57:11 EST From: Rina Nathaniel To: if-mib , Ted Brunner Cc: tedb Subject: RE: RFC 1573 implementation report, by R.N.D Networks Date: Sun, 16 Feb 97 16:56:00 EST Message-ID: <33072047@smtp-gateway.rad.co.il> Encoding: 62 TEXT X-Mailer: Microsoft Mail V3.0 Sender: if-mib-owner@vndad.tek.com Precedence: bulk R.N.D Networks has an implementation of the If-MIB draft-ietf-ifmib-mib-03.txt in two products Vgate and PRT. Vgate is as switch router with interfaces type 10/100ET. PRT is a small router with one ET and two WAN interfaces with Frame Relay and ISDN option. We continue to support RFC1213, and implemented the ifXTable and ifStackTable. The ifStackTable was useful in showing the relationship between interfaces. We have propVirtual interfaces that are stacked above physical. The ifStackTable provides a method of showing Virtual LAN IP/IPX etc. (an interface type propVirtual above the multiple physical interfaces of the same ifType). The IfIndex of this propVirtual is associate with the IP/IPX address. We use the same method for broadcast restriction for some protocols and to enable backup between interfaces. We have a management application that shows the user per each physical interface which interfaces were define above it, and enables him to change configuration dynamically. We think that the interface MIB is very useful and well written. We hope to implement the new version of the ifMib once it becomes a proposed standard. Rina Nathaniel R.N.D Networks Ltd. 972.3.6459556 ---------- From: Ted Brunner[SMTP:ted.brunner@tek.com] Sent: eai ?aeoe 12 oa?aa? 1997 15:52 To: if-mib Cc: tedb Subject: implementation reports In a previous message I requested implementation reports from the wg. These are necessary to promote this Internet Draft to RFC status, and in particular to draft standard. As of now, I have one report (it was very prompt) and one promise. Please take the time to report on your companies implementation of the interfaces mib. Send reports directly to me, or to the list, preferably with a subject heading mentioning implementation. If you ask me to, I will keep the info you send to me anonymous. Ted Brunner Video and Networking Division Tektronix MS 50-490 ted.brunner@tek.com 14150 SW Karl Braun 503.627.1317 Beaverton OR 97005   Received: from cnri by ietf.org id aa12394; 20 Feb 97 11:56 EST Received: from inet1.tek.com by CNRI.Reston.VA.US id aa15203; 20 Feb 97 11:57 EST Received: from bocote.vndad.tek.com by inet1.tek.com id ; Thu, 20 Feb 1997 08:41:14 -0800 Received: (from daemon@localhost) by bocote.vndad.tek.com (8.7.5/8.7.3) id IAA25473 for if-mib-outgoing; Thu, 20 Feb 1997 08:41:12 -0800 (PST) Received: from tektronix.tek.com (tektronix.tek.com [134.62.8.103]) by bocote.vndad.tek.com (8.7.5/8.7.3) with ESMTP id IAA25467 for ; Thu, 20 Feb 1997 08:41:10 -0800 (PST) Received: from inet2.tek.com (inet2-en1.tek.com [134.62.8.58]) by tektronix.tek.com (8.7.5/8.7.3) with SMTP id IAA09035 for ; Thu, 20 Feb 1997 08:41:08 -0800 (PST) Received: from mailhost2.BayNetworks.COM by inet2.tek.com id ; Thu, 20 Feb 1997 08:41:06 -0800 Received: from ns1.BayNetworks.COM ([134.177.1.107]) by mailhost2.BayNetworks.COM (8.8.5/BNET-96/12/06-E) with ESMTP id IAA10816; Thu, 20 Feb 1997 08:38:28 -0800 (PST) for Received: from pobox.engeast.BayNetworks.COM (pobox.corpeast.baynetworks.com [192.32.151.199]) by ns1.BayNetworks.COM (8.8.3/BNET-97/01/07-I) with ESMTP id IAA03623; Thu, 20 Feb 1997 08:40:59 -0800 (PST) for Posted-Date: Thu, 20 Feb 1997 08:40:59 -0800 (PST) Received: from mcgiffert.engeast (mcgiffert [192.32.243.54]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-SVR4-S) with SMTP id LAA00730; Thu, 20 Feb 1997 11:41:01 -0500 for Received: from mcgiffert (localhost) by mcgiffert.engeast (4.1/SMI-4.1) id AA08207; Thu, 20 Feb 97 11:40:55 EST Message-Id: <330C7E96.592990BB@BayNetworks.com> Date: Thu, 20 Feb 1997 11:40:54 -0500 From: Steve Onishi Organization: Embedded Agent Software Development X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 4.1.4 sun4m) Mime-Version: 1.0 To: if-mib@vndad.tek.com Subject: An ifTable ? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: if-mib-owner@vndad.tek.com Precedence: bulk Should the ifOldObjectsGroup be part of the MANDATORY groups to ensure backwards compatibility with older apps? We've found that some apps are "surprised" when these non-mandatory objects aren't there. /StO