CURRENT_MEETING_REPORT_ Reported by Kaj Tesink/Bellcore Minutes of the ATM MIB Working Group (ATOMMIB) Ted Brunner kindly volunteered to take notes for these minutes. ATM MIB(s) Work Status A draft has been posted and discussed on the mailing list for some time. The scope is beyond that of ATM Forum's ILMI MIB, which is limited on local interface. A new version of the ILMI MIB will have address registration, and some minor polishing. It has been suggested to maintain, as much as possible, ILMI compatibility and semantics. However, given the larger scope of the IETF ATM MIB, some differences will be unavoidable. Discussion followed on Bellcore's proposed draft MIB. Use of ifTable for ATM Interfaces The central point in this discussion was how the ATM protocol stack must be represented with ifEntries. The resolution was that the following ifEntries are necessary: o One ifEntry for the general ATM layer. o no ifEntries for ATM VC or VP interfaces (this follows the current recommendation of the IFMIB Working Group, and avoids unnecessary ifEntry proliferation and implied performance statistics per VP/VC). o One ifEntry for all combined AAL3/4 and AAL5 interfaces (convergence sublayer). o One ifEntry for all combined AAL1 and AAL2 interfaces (convergence sublayer). The specific mapping of ATM parameters to ifEntry objects was not discussed but is already included in the MIB draft. The Need for ATM Local Interface Configuration Reference in the MIB draft: atmInterfaceConfTable. Some small changes were suggested and agreed: o The objects atmInterfaceTransmissionType and atmInterfaceMediaType are now redundant (the ATM MIB should only be concerned with the ATM layers), o The atmInterfaceIlmiVpiVci requires fixing in the definition (range) and description (how it is used), o A discussion took place on the need to include objects for the maximum number of PVCs and SVCs that can be used. This discussion was deferred to the mailing list. The meaning of atmInterfaceConfVxc was questioned (for PVC or SVC). It was agreed not to clarify the particular use of this object unless the ATM Forum does detail its definition. The Need for ATM Local Interface Statistics These statistics are now represented by an ifEntry. No further statistics were felt necessary. The Need for ATM Local Interface Statistics Per VCC/VPC The draft MIB proposes for each VC and VP interface a counter for the number of received and transmitted cells, and the number of discards due to traffic policing and shaping. These statistics could, for example, be used to detect congestion and configuration problems. Other suggestions were not to include these statistics at all for VC or VP interfaces, suggesting that hardware costs outweigh the benefits. Still another suggestion was to have a different conformance statement for public and private interfaces (i.e., public interfaces do have these statistics, and private interfaces do not). Keith McCloghrie suggested a compromise, i.e., to define a test capability that can measure these statistics for specific VP and VC interfaces for a short amount of time. Kaj Tesink will produce a draft, which will be discussed on the mailing list. The Need for Physical Level Convergence Level Management The current draft MIB specifies managed objects for the DS3 PLCP, and for the SONET TC. The contents of the corresponding tables were reviewed and agreed to. Discussion focused on whether these tables belonged in the ATM MIB or in the DS3 and SONET MIBs respectively. For practical reasons it was decided to keep them in the ATM MIB. Convergence layers for other types of physical facilities were not identified but could be added as needed. The Need for AAL Management Management of the AAL layer was decided to be performed via ifTable (see item b). As a result of this discussion the draft atmAalPointerTables are now redundant and can be removed. The Need for ATM Connection Management A more lengthy discussion took place on this subject. In addition, Ken Rodemann gave a presentation on a generic approach to the management of virtual connections, suggesting a common approach for Frame Relay, X.25, and ATM. The generic approach would serve as a sort of umbrella over connection tables that are specific to the X.25, Frame Relay, or ATM. The contents of the specific tables would not be affected by adoption of the generic approach. Rather, the specific approach would simplify the overall management of connections. Discussion of this topic was, due to lack of time, deferred to the FRNETMIB and IFMIB Working Group meetings. On the specifics of the connection table, the following points were discussed: o It was agreed that a connection table should work for both end-systems and intermediate-systems. o The desire to maintain commonality with the ILMI MIB was expressed. It was also observed that the ILMI MIB does not have a connection table (not in its scope), and that the draft table caused only a difference in OID values for traffic parameters. o The proposed draft makes the point of allowing the creation of a new association between an ingress and egress with a single table row. o A connection table would benefit considerably from a rowStatus column as defined in the SNMPv2 TC. Keith McCloghrie and Ted Brunner were tasked to review connection table alternatives, and post their findings to the mailing list for discussion. The Need for SVC Management Due to lack of time, network management needs for SVCs were not discussed. However, a discussion took place on the scope of the connection table. In general, the observation was supported that the connection table should not state whether it applies to SVCs and/or PVCs, leaving it to implementation as to how the table is applied. See also section, "The Need for ATM Local Interface Configuration," for another SVC related issue. Any Other ATM MIB Needs None were identified. SONET MIB Work The issues discussed had been previously raised on the mailing list. In addition, the particular use of ifTable was discussed. Status The existing Internet-Draft has been kept highly compatible with other trunk MIBs. Only minor comments have been made on the mailing list. Editorial Items o Some ranges in status objects contain typos. o ``other'' should be included in some enumerated lists o Language on SDH should be clarified. o The label ``photonic'' should be changed, since it also applies to electrical interfaces. The Need for Interval and Total Tables The mailing list has pointed out that strictly speaking, these tables are redundant, since they can be deduced from the Current and first Interval tables. It was suggested to delete the Total tables, and leave the number of supported Interval tables as implementation specific. One suggestion was made to support at least an hour's worth of Interval tables. Another value that was suggested was eight hours. Given that some implementations of these tables may already exist, confirmation of this approach will be sought on the mailing list. Use of ifTable This item was reviewed briefly. The conclusion was to have ifEntries as follows: o One ifEntry for the combined SONET photonic, section and line layers for a particular port, o One ifEntry for each SONET path (if used on that port), o One ifEntry for each SONET VT (if used on that port) A new version of the MIB will be posted that accommodates above points. Since not all parts of the MIB do apply to each SONET interface, it is important to specify a precise conformance statement. The new version of the MIB will include this. Attendees Masuma Ahmed mxa@sabre.bellcore.com David Arneson arneson@ctron.com Anders Baardsgaad anders@cc.uit.no Cynthia Bagwell cbagwell@gateway.mitre.org Nutan Behki Nutan_Behki@qmail.newbridge.com Tracy Brown tacox@mail.bellcore.com Theodore Brunner tob@thumper.bellcore.com Jeff Case case@cs.utk.edu Chris Chiotasso chris@andr.ub.com Jonathan Davar jdavar@synoptics.comm David Engel david@ods.com Michael Erlinger mike@jarthur.claremont.edu David Fresquez fresquez@vnet.ibm.com Mike Goguen goguen@synoptics.com Juha Heinanen juha.heinanen@datanet.tele.fi Steven Horowitz witz@chipcom.com Jeff Hughes jeff@col.hp.com Carl Madison carl@startek.com Andrew Malis malis@maelstrom.timeplex.com Keith McCloghrie kzm@hls.com George Mouradian gvm@arch3.att.com Zbigniew Opalka zopalka@agile.com David Perkins dperkins@synoptics.com Drew Perkins ddp@fore.com James Reeves jreeves@synoptics.com Kenneth Rodemann krr@qsun.att.com Dan Romascanu dan@lannet.com Hal Sandick sandick@vnet.ibm.com Jon Saperia saperia@tay.dec.com Jean-Bernard Schmitt jbs@vnet.ibm.com Dono van-Mierop dono_van_mierop@3mail.3com.com James Watt james@newbridge.com Steven Willis steve@wellfleet.com