CURRENT_MEETING_REPORT_ Reported by Edward Alcoff/Network Application Technology and Michael Erlinger/Harvey Mudd College Minutes of the Remote LAN Monitoring Working Group (RMONMIB) Introduction The goals for this meeting of the RMONMIB Working Group were to discuss the advancement of RFC 1271 and to discuss the proposed charter for RMON2. Monday's session was devoted to RFC 1271 advancement. Tuesday's session centered around a discussion of the charter for the next generation of RMON (agreed to be designated RMON2---not RMONv2). RFC 1271 Advancement The issues concerning RFC 1271 advancement are: 1. A question was raised with regards to an RMON agent having to capture a packet larger than 1518 bytes, and if so, then how much larger? Options included: o bump the counter, but not capture (is this compliant) o look at part of the packet (but not capture all of the packet) It was the consensus of the group to leave it as currently stated. There are numerous options depending on the particular chip capabilities. Let the implementors do the right thing. Clarify this better in RMON2. 2. The etherHistoryTable has approximately 12 counters while the tokenRingMLHistoryTable has approximately 25 counters, which may have different memory requirements should an RMON agent be required to support both media types. The buckets granted may change, and not be sufficient if going from Ethernet to Token Ring. The point was made that this should not happen very often, and the action to be taken should be straight forward and recoverable. The agent should return ``badValue'' of the data source to the change request (or ``resource unavailable''). A suggestion was made to allow the value of the buckets granted to change. It was also mentioned that this issue is a rehash or a previous debate with regards to an agent changing interfaces. Steve will add text to RFC 1271 to the effect ``If the agent knows (of a change to the interface), then it is to `do the right thing,' within its capabilities.'' 3. On hearing one's own packets, it was deemed important that the agent must account for everything it sends, but it may not be able to ascertain the relative ordering of packets captured that originate from that Mac. Should it just make a ``best effort''? The choices were to add another bit to captureBufferPacketStatus, add text to the RFC describing the problem, or do nothing. It was the consensus of the group to add another bit to captureBufferPacketStatus indicating that order of packets from that Mac are a best guess. Also, noted that the bit is restricted to packets from that Mac---prevents an agent from not maintaining order in the buffer. 4. With the above changes RFC 1271 should be forwarded to the area director with a recommendation of advancement to Draft Standard. Steve committed to a date of 18 April for publication of the revised draft. The Next Generation of RMON - RMON2 The first part of the discussion made clear the notion that there is no charter for such a working group. The results of the discussion would be used to generate a charter for such a working group once the current RMONMIB activities were concluded---namely the advancement of RFC 1271. The chair presented the following issues: o Time frame - strongly suggested that a Proposed RFC be readied within the next 12 months. o Requirements and problems needing to be solved. o What will and will not be considered for RMON2. o RMON2's relationship to the original RMON: - new features - old features to be reconsidered/redesigned - backward compatibility not required o The RMON2 development process, i.e., need for interim meetings of the working group over and above IETF meetings. o RMON2's relationship to SNMPv2. The chair then asked if there were any participants that have done extensions to RMON and would like to present these features for inclusion in RMON2. The chair also solicited implementations from any organization that have extended RMON. The following list of features was created for RMON2 discussion and inclusion in the proposed charter. 1. Statistical analysis that would be protocol independent and move up the stack. (As a side note, it was later agreed that the RMON Working Group would strive for protocol independence.) 2. Address mapping - Network Layer to Data Link (MAC) Layer and vice-versa. 3. Duplicate and/or address change detection. Question asked on whether or not this should be accomplished on the station? 4. The relationship of the Manager-to-Manager MIB in SNMPv2 and associated RMON alarm tables. Suggestion was made to possibly deprecate the older tables. 5. Provide a Host Table for the Network Layer, and perhaps the Transport Layer. 6. Protocol-type distribution through all seven layers of the ISO model; develop paradigm even if not feasible. A question was asked on why this could not be done with the current filtering scheme; the answer was that there would be a need to set up too many filters and the processing would be inefficient. 7. Address the issue of the filter mechanism being constrained by bit-to-bit packet matching, which presents a problem with variable-length packets. 8. Consider how RMON could benefit network security, for example, using the RMON History to provide an accountability and audit trail through the Transport Layer. The security challenge here is to be able to track connectionless protocols such as UDP. An audit trail of port numbers, time and states would be very useful. 9. Noted that RMON for other physical layers should fall to other working groups, such as the IFMIB Working Group, or be taken out of the RMON Working Group and included in new working groups. 10. More performance metrics in RMON to meet the needs of the client-server environment. 11. Concerns of hardware implementation should be considered. For example, optimization of the filter and capture group would reduce the cost of the CPU and improve performance. 12. Align the EtherStats and History Tables with IEEE and/or the repeater MIB. 13. Align with SNMPv2. The working group also discussed whether RFC 1271 should be divided into a generic RMON and an Ethernet RMON. Consensus was reached on keeping Ethernet and generic RMON within the same RFC. Once RFC 1271, with modifications, is advanced to a Draft Standard, the chair will create an RMON2 charter. Attendees Edward Alcoff oldera@nat.com David Arneson arneson@ctron.com Bashir Ashrafi bashraf@chipcom.com Jim Barnes barnes@xylogics.com Andy Bierman abierman@synoptics.com Uri Blumenthal uri@watson.ibm.com Tony Bogovic tjb@bellcore.com Carter Bullard wcb@cert.org Jeff Case case@snmp.com Frank Ciotti frankc@telxon.com Matt Crawford crawdad@fncent.fnal.gov Roger Cyganer cygander@telebit.comm Robert De Mong robert.Demong.amd.com Russell Dietz Russell_Dietz@mcimail.com Art Dong atos@cac.washington.edu David Engel david@ods.com Michael Erlinger mike@jarthur.claremont.edu Louis Fernandez lff@sequent.com John Flick johnf@hprnljf.rose.hp.com Walter Guilarte guilarte@wg.com Stuart Hale stu_hale@vnet.ibm.com Daniel Hansen danh@ngc.com Duane Harkness duaneh@atc.boeing.com John Hopprich hopprich@davidsys.com Jeff Hughes jeff@col.hp.com Robin Iddon robini@cix.compulink.co.uk Bent Jensen bent@cisco.com Jeff Johnson jjohnson@cisco.com Vince Jones 72077.1615@compuserve.com Paul Kingsley pmk@hpcsos.col.hp.com Richard Kooijman r.kooijman@et.tudelft.nl Cheryl Krupczak cheryl@empiretech.com Kenrick Kutzler kkutzler@synoptics.com Welson Lin welsonl@nat.com Faye Ly fly@synoptics.com Carl Madison carl@zeus.st.3com.com Evan McGinnis bem@3com.com Dwayne McIntosh mcintosh@sleepy.ns.us.boeing.com Jim McQuaid mcquaid@wg.com Bob Morgan morgan@networking.stanford.edu Kenneth Mueller ken@cmc.com Robert Natale natale@acec.com Roxanne Nisbet bsvnvgk@bell-atl.com Bill Norton wbn@merit.edu Richard Paine painer@ct.si.cs.boeing.com Andrew Pearson pearson@snmp.com David Perkins dperkins@synoptics.com Randy Presuhn randy@peer.com Venkat Rangan venkat.rangan@nashua.hp.com Guenter Roeck roeck@conware.de Dan Romascanu dan@lannet.com Blair Sanders bbs@sanders.itg.ti.com Michael Scanlon scanlon@ftp.com Timon Sloane timon@timonware.com Robert Snyder snyder@cisco.com Ira Steckler isteckle@chipcom.com Rudolph Sterner rudy.sterner@amd.com Bob Stewart rlstewart@eng.xyplex.com Richard Sweatt rsweatt@synoptics.com William Wagner dpi@world.std.com Steven Waldbusser swol@andrew.cmu.edu Dick Wallace dick@concord.com David Walters walters@wg.com Glenn Waters gwaters@bnr.ca Chris Wellens chrisw@netcom.com Bert Wijnen wijnen@vnet.ibm.com Peter Wilson peter_wilson@3mail.3com.com Shian-Tung Wong shian@dcsd.sj.nec.com Jeff Yarnell jeffya@protools.com Kiho Yum kxy@nsd.3com.com Dan Zerkle zerkle@cs.ucdavis.edu