Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/trmon/trmon-minutes-93mar.txt

Text File | 1993-05-01 | 11KB | 277 lines

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            [e-mail]
David Battle             [e-mail]
Andy Bierman             [e-mail]
John Chang               [e-mail]
Anthony Chow             [e-mail]
Manuel Diaz              [e-mail]
Sandra Durham            [e-mail]
David Engel              [e-mail]
Kenneth Giusti           kgiusti.chipcom.com
Daniel Hansen            [e-mail]
Gerd Holzhauer           [e-mail]
Jeff Hughes              [e-mail]
Kenneth Key              [e-mail]
Carl Madison             [e-mail]
Evan McGinnis            [e-mail]
Tom Nisbet               [e-mail]
Jon Penner               [e-mail]
David Perkins            [e-mail]
Narendra Popat           [e-mail]
Venkat Rangan            venkat@.metrix.com
Dan Romascanu            [e-mail]
Marshall Rose            [e-mail]
Rick Royston             [e-mail]
Paul Serice              [e-mail]
Ira Steckler             [e-mail]
Richard Sweatt           [e-mail]
Geoffrey Thompson        [e-mail]
Stephen Tsun             [e-mail]
Peter Wilson             [e-mail]
Kiho Yum                 [e-mail]



                                   3