Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/rmonmib/rmonmib-minutes-94mar.txt

Text File | 1994-06-06 | 10KB | 246 lines

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            [e-mail]
David Arneson            [e-mail]
Bashir Ashrafi           [e-mail]
Jim Barnes               [e-mail]
Andy Bierman             [e-mail]
Uri Blumenthal           [e-mail]
Tony Bogovic             [e-mail]
Carter Bullard           [e-mail]
Jeff Case                [e-mail]
Frank Ciotti             [e-mail]
Matt Crawford            [e-mail]
Roger Cyganer            [e-mail]
Robert De Mong           robert.Demong.amd.com
Russell Dietz            [e-mail]
Art Dong                 [e-mail]
David Engel              [e-mail]
Michael Erlinger         [e-mail]
Louis Fernandez          [e-mail]
John Flick               [e-mail]
Walter Guilarte          [e-mail]
Stuart Hale              [e-mail]
Daniel Hansen            [e-mail]
Duane Harkness           [e-mail]
John Hopprich            [e-mail]
Jeff Hughes              [e-mail]
Robin Iddon              [e-mail]
Bent Jensen              [e-mail]
Jeff Johnson             [e-mail]
Vince Jones              [e-mail]
Paul Kingsley            [e-mail]
Richard Kooijman         [e-mail]
Cheryl Krupczak          [e-mail]
Kenrick Kutzler          [e-mail]
Welson Lin               [e-mail]
Faye Ly                  [e-mail]
Carl Madison             [e-mail]
Evan McGinnis            [e-mail]
Dwayne McIntosh          [e-mail]
Jim McQuaid              [e-mail]
Bob Morgan               [e-mail]
Kenneth Mueller          [e-mail]
Robert Natale            [e-mail]
Roxanne Nisbet           [e-mail]
Bill Norton              [e-mail]
Richard Paine            [e-mail]
Andrew Pearson           [e-mail]
David Perkins            [e-mail]
Randy Presuhn            [e-mail]
Venkat Rangan            [e-mail]
Guenter Roeck            [e-mail]
Dan Romascanu            [e-mail]
Blair Sanders            [e-mail]
Michael Scanlon          [e-mail]
Timon Sloane             [e-mail]
Robert Snyder            [e-mail]
Ira Steckler             [e-mail]
Rudolph Sterner          [e-mail]
Bob Stewart              [e-mail]
Richard Sweatt           [e-mail]
William Wagner           [e-mail]
Steven Waldbusser        [e-mail]
Dick Wallace             [e-mail]
David Walters            [e-mail]
Glenn Waters             [e-mail]
Chris Wellens            [e-mail]
Bert Wijnen              [e-mail]
Peter Wilson             [e-mail]
Shian-Tung Wong          [e-mail]
Jeff Yarnell             [e-mail]
Kiho Yum                 [e-mail]
Dan Zerkle               [e-mail]