CURRENT_MEETING_REPORT_ Reported by Steven Waldbusser/CMU Minutes of the Token Ring RMON MIB Working Group (TRMON) Agenda o Identify/Resolve Outstanding Issues o Call for Consensus o Discussion of Future Work Priorities o Discussion of Next Meeting for RMON-related Activities o Implementation Issues for RFC1271 The TRMON Working Group met for one session. At that session, the final outstanding technical issues for the draft were identified and resolved. There was consensus that the resulting draft should be submitted to the Network Management Directorate for eventual publication as a Proposed Standard. The Group then discussed priorities for future work and where a next meeting might take place. There was no clear resolution on these issues. Finally, in the remaining minutes, a few implementation issues for RFC1271 were discussed. Identify/Resolve Outstanding Issues Issue #1: > Again, I think you're right. However, remember it's when the state > changes FROM normalOperation, ringPurgeState, or > monitorContentionState, TO one of the beacon states. I don't think > that changing from one beacon type to another should count as a new > beacon event. Will the ring ever go from one beacon state to another? If so, is this event significant to the operator? ---------------------------------------- Consensus: No one could guarantee that the ring wouldn't go from one beacon state to another, but there was a clear consensus that the network manager would perceive this as going from a broken state to another (very similar) broken state and would not be interested in this trivia. Therefore the original semantics are not changed. ======================================== Issue #2: ringStationOrderOrderIndex, page 44 Why not make the reference node the active monitor. This would simplify the design of the manager application. ---------------------------------------- Consensus: The following observations were made (in roughly the following order): 1. It is helpful to standardize on a reference node. 2. It is easiest on the agent to choose the active monitor as the reference node for a typical implementation strategy. 3. If the active monitor is the reference node, the whole list will shift around (as much as 180 degrees) when the active monitor changes and a new node becomes the reference node. This might happen fairly often and introduces a moment of chaos. 4. If the probe is chosen as the reference node, the problem in #3 goes away. 5. Using the probe as a reference is trivially more complex than using the active monitor. Therefore, the group decided to choose a reference point and to make it the probe. ======================================== Issue #3: tokenRingMLStatsBeaconEvents, page 8 The list of beacon states does not include the beaconRingSignalLossState - I assume that it should (rather than this particular state not counting as a beacon event). ---------------------------------------- Consensus: Yes, the list of beacon events should include the signal loss state. ======================================== Issue #4: tokenRingMLStatsRingPurgeEvents OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of times that the ring enters the ring purge state from normal ring state. The ring purge state that comes in response to the monitor contention or beacon state is not counted." ::= { tokenRingMLStatsEntry 6 } Will the ring always go directly from monitor contention or beacon state to ring purge state? Or should the last sentence say: "The ring purge state that comes in response to the monitor contention or beacon state is not counted, even if the the ring goes to the normal state first." ---------------------------------------- Consensus: The ring should always go directly from these states to the ring purge state, so the original text will be used. ======================================== Issue #5: Should we replace the terminology "monitor contention state" with "claim token state". ---------------------------------------- Consensus: Yes, the "claim token state" more exactly matches the token ring documentation. ======================================== Issue #6: Did we decide to use the IEEE sized RIF field or the smaller 18 byte field as commonly implemented today? Should the larger size be 30 or 32 bytes? ---------------------------------------- Consensus: On the mailing list we had decided to use the larger RIF fields. At the meeting I mentioned that my understanding was that a 32 byte field would be best, but I couldn't quote the reason. The resolution was that I would see if my recollection was accurate and, if so, make the field 32 bytes, otherwise make it 30 bytes. The rationale is that the worst case RIF length is 31 bytes. 32 bytes is a nicer number to process than 31, therefore we should use 32. ======================================== Issue #7: Someone on the mailing list had complained that the 1024 - 2048 bucket was too large to be of use. In the meeting, it was noted that in particular, it would be helpful to have a break in bucket size at the Ethernet MTU so that the probe could detect packets that might be dropped by a 802.5<->ethernet bridge. Further discussion uncovered the fact that because it isn't clear on a packet by packet basis whether the bridge would strip the SNAP header or not; and because the TR RIF field would introduce some more slop; that a useful break between the two buckets couldn't be found. ---------------------------------------- Consensus: This is a worthy problem, but the solution requires more effort than is appropriate for this MIB at this stage, so we will leave the bucket sizes unaltered. ======================================== Call for Consensus The Chair notes that there were no outstanding issues left for the MIB. He asked if there was consensus that the Group should submit this MIB to the SNMP Directorate for review and publication as a Proposed Standard. No objections were noted. Discussion of Future Work Priorities The following items were discussed: 1. Updating RFC1271 from Proposed to Draft Standard (this involves fixing bugs and known interoperability problems) 2. FDDI RMON Extensions 1 3. RMON2 - New features for RMON (Network layer information, protocol distributions, ...) 4. WAN interface Extensions. It was agreed that moving RFC1271 from Proposed to Draft should be our highest priority. Discussions of Future Meetings for RMON-related Activity If the Working Group were to tackle one of these issues, the earliest opportunity to meet would be at the next IETF meeting in Amsterdam. There was some discussion of the merits of this, but no resolution was reached. Discussion of Implementation Issues 1. A vendor noted an interoperability problem when his probe was having an alarm entry created by certain other managers. These managers would create the entry and then immediately issue get requests for the entire row (include alarmValue). His probe would return noSuchName because the first alarm interval had not passed yet and the alarmValue instance had not yet been created. The managers would crash or otherwise refuse to interoperate due to the noSuchName error. The consensus was that the probe was compliant to RFC1271 and that management stations should not break if the alarmValue is not present immediately after row creation. An even more robust strategy would be to handle the lack of alarmVariable at any time. 2. A vendor noted an interoperability problem when his probe was being queried by a certain manager. This manager would query the history table, assuming that three history entries had been configured at startup, apparently as that vendor does on its own probe. When the three entries weren't found, the manager crashed or otherwise refused to interoperate. The consensus was that the manager was the cause of the interoperability problem and that it shouldn't assume any configuration. It was noted however, that while the probe was not obligated to have any particular setup of history entries, that the two entries suggested in the MIB should be configured for the probe to be the ``best citizen'' possible. 3. A recent mailing list discussion was brought up. The RFC1271 host table specifies that ``The host group discovers new hosts on the network by keeping a list of source and destination MAC Addresses seen in good packets.'' The rational for only using good packets is that bad packets may fill the table up with random Mac addresses. 2 It was noted that short and long packets (with correct CRC) are likely to have correct Mac addresses, and might be appropriate for gleaning new hosts. Everybody agreed that the specification is currently very clear on this issue, but that it might be reasonable to modify it in future versions to allow the use of Mac addresses in short and long addresses. Attendees David Arneson arneson@ctron.com David Battle battle@cs.utk.edu Andy Bierman abierman@synoptics.com John Chang changj@ralvm6.vnet.ibm.com Anthony Chow chow_a@wwtc.timeplex.com Manuel Diaz diaz@davidsys.com Sandra Durham sdurham@synoptics.com David Engel david@ods.com Kenneth Giusti kgiusti.chipcom.com Daniel Hansen dan@ngc.com Gerd Holzhauer holzhauer1@applelink.apple.com Jeff Hughes jeff@col.hp.com Kenneth Key key@cs.utk.edu Carl Madison carl@startek.com Evan McGinnis bem@3com.com Tom Nisbet nisbet@tt.com Jon Penner jjp@bscs.uucp David Perkins dperkins@synoptics.com Narendra Popat albin@frontier.com Venkat Rangan venkat@.metrix.com Dan Romascanu dan@lannet.com Marshall Rose mrose@dbc.mtview.ca.us Rick Royston rick@lsumvs.sncc.lsu.edu Paul Serice serice@cos.com Ira Steckler isteckle@chipcom.com Richard Sweatt rsweatt@synoptics.com Geoffrey Thompson thompson@synoptics.com Stephen Tsun snt@3com.com Peter Wilson peter_wilson@3com.com Kiho Yum kxy@nsd.3com.com 3