Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

RE: RMON and 802.3 harmonization




RFC 2819 - http://www.ietf.cnri.reston.va.us/rfc/rfc2819.txt


> -----Original Message-----
> From:	James Colin [SMTP:james_colin_j@yahoo.com]
> Sent:	Mon November 20 2000 12:23
> To:	pat_thaler@agilent.com; bob.grow@intel.com;
> millardo@dominetsystems.com; stds-802-3-hssg@ieee.org
> Subject:	Re: RMON and 802.3 harmonization
> 
> 
> Hi,
> Can someone send a pointer to the updated version of
> RMON requirements?
> Thanks,
> James
> --- pat_thaler@agilent.com wrote:
> > 
> > So Bob, I assume that this means I have your
> > permission to reply. But I'll
> > let the runt thread die by renaming the response.
> > Pat
> > 
> > Howard,
> > 
> > We have passed the date for last new feature in
> > 802.3ae and what you propose
> > seems to be a new feature.
> > 
> > If you or others feel that the 802.3 MIB should be
> > augmented to add the
> > objects that RMON counts, then I think the right
> > thing to do is to bring a
> > proposal to 802.3 for that activity. Alternatively,
> > you and the first mile
> > folks might decide it should be included in that
> > project. I think it is too
> > late to add such an activity to 802.3ae without
> > endangering schedule and it
> > really would be a "service to humanity" action. 
> > 
> > Is it actually possible to harmonize 802.3 and RMON
> > MIBs? Won't the IETF
> > continue to evolve RMON adding new objects in the
> > future?
> > 
> > Regards,
> > Pat
> > 
> > -----Original Message-----
> > From: Grow, Bob [mailto:bob.grow@intel.com]
> > Sent: Thursday, November 16, 2000 5:23 PM
> > To: 'Howard Frazier'; stds-802-3-hssg@ieee.org
> > Subject: RE: RUNT Packets
> > 
> > 
> > 
> > So while messages pass on the net, Howard goes and
> > puts the lie to may claim
> > that no one in the thread has proposed any MAC or
> > MIB changes.   [sigh]
> > 
> > --Bob
> > 
> > -----Original Message-----
> > From: Howard Frazier
> > [mailto:millardo@dominetsystems.com]
> > Sent: Thursday, November 16, 2000 4:28 PM
> > To: stds-802-3-hssg@ieee.org
> > Subject: Re: RUNT Packets
> > 
> > 
> > 
> > 
> > 
> > There is something to be said for making the RMON
> > and 802.3 MAC sublayer
> > counters match up, once and for all.
> > 
> > I have spent more time explaining the differences
> > than I would have spent 
> > on simply making them the same. We are kidding
> > ourselves if we think
> > that the RMON statistics aren't important. We are
> > also perpetuating an
> > inefficient process if we continue to crank up the
> > speed in 802.3 while
> > leaving it up to another group to finish the
> > management work. The community
> > of implementers and users that we serve needs to
> > have all of the MAC
> > sublayer 
> > statistics defined for each operating speed. 
> > 
> > With the scope of the "service to humanity" work
> > that is already being
> > done on clause 4, adding in counters for undersized
> > receive events
> > (whether they be RUNTS, UndersizePkts, or the
> > ever-popular "flying
> > pygmies") should be no big deal. It would save a lot
> > of people a lot
> > of head scratching if we did it.
> > 
> > 
> > Howard Frazier
> > DomiNet Systems
> > 
> > pat_thaler@agilent.com wrote:
> > > 
> > > Bob,
> > > 
> > > Undersized packets is something that RMON may have
> > on object for without
> > > 802.3 having a corresponding object. If so, either
> > we can't say anything
> > > about how it is counted because we don't define
> > the object or we can add
> > the
> > > object. To add it in the same way that other MAC
> > frame counters are
> > handled,
> > > we will have to put it into the Pascal of 5.2.4
> > and probably 4.2.9. The
> > > status quo is that its definition is up to RMON.
> > > 
> > > Regards,
> > > Pat
> > > 
> > > -----Original Message-----
> > > From: Grow, Bob [mailto:bob.grow@intel.com]
> > > Sent: Thursday, November 16, 2000 10:45 AM
> > > To: stds-802-3-hssg@ieee.org
> > > Subject: RE: RUNT Packets
> > > 
> > > As Louis said, we we are really focused on
> > undersized frames.  For example
> > > in RMON, undersized frames are either directly
> > counted (e.g.,
> > > etherStatsUndersizePkts) or included in the filter
> > for a counter (e.g.,
> > > etherStatsFragments)
> > > 
> > > --Bob
> > > 
> > > -----Original Message-----
> > > From: pat_thaler@agilent.com
> > [mailto:pat_thaler@agilent.com]
> > > Sent: Thursday, November 16, 2000 9:12 AM
> > > To: bob.grow@intel.com; stds-802-3-hssg@ieee.org
> > > Subject: RE: RUNT Packets
> > > 
> > > Bob,
> > > 
> > > The important point is that runts are not counted
> > by MACs. The MIB
> > > definition that Geoff provided is for aRunts which
> > is a _repeater_ MIB
> > > object. The MAC silently discards packets that are
> > shorter than the
> > minimum.
> > > It has no counter for them. The counter update
> > process,
> > > LayerMgmtReceiveCounters, only runs when a packet
> > that meets minimum
> > packet
> > > size is received. (See 4.2.9 for the MAC receiver
> > and Table 30-1 for a
> > > listing of MIB objects.)
> > > 
> > > Unless someone is proposing creating a new runt
> > MIB object, runts do not
> > > apply to 10 Gig Ethernet because we do not have
> > repeaters.
> > > 
> > > Regards,
> > > Pat
> > > 
> > > -----Original Message-----
> > > From: Grow, Bob [mailto:bob.grow@intel.com]
> > > Sent: Wednesday, November 15, 2000 3:22 PM
> > > To: stds-802-3-hssg@ieee.org
> > > Subject: RE: RUNT Packets
> > > 
> > > Pat:
> > > 
> > > I probably over simplified the 10 Gb/s explanation
> > of runts, my appologies
> > > to those confused by it.  Those that want the
> > precise answer can read the
> > > MIB definition that Geoff Thompson posted from the
> > standard.
> > > 
> > > I was only addressing the noise hit causing
> > detection of an end delimiter,
> > > and transmitting a smaller than minimum frame (a
> > protocol error).  Many
> > see
> > > a high runt count as reason to suspect a device is
> > transgressing protocol
> > by
> > > transmitting the runts.
> > > 
> > > In my haste to get the first draft of clause 46
> > out, any noise hit
> > yielding
> > > one (or more) control characters at the RS would
> > terminate the frame,
> > > including those noise hits converted to Error by
> > the PCS.  The change
> > agreed
> > > to in Tampa was to exclude Error control
> > characters from terminating the
> > > frame, thus significantly reducing the number of
> > noise hits that will
> > result
> > > in counting a runt packet.  This basically places
> > the burden of
> > 
> === message truncated ===
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Calendar - Get organized for the holidays!
> http://calendar.yahoo.com/