Re: RMON and 802.3 harmonization
Hi,
Can someone send a pointer to the updated version of
RMON requirements?
Thanks,
James
--- pat_thaler@xxxxxxxxxxx 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@xxxxxxxxx]
> Sent: Thursday, November 16, 2000 5:23 PM
> To: 'Howard Frazier'; stds-802-3-hssg@xxxxxxxx
> 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@xxxxxxxxxxxxxxxxxx]
> Sent: Thursday, November 16, 2000 4:28 PM
> To: stds-802-3-hssg@xxxxxxxx
> 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@xxxxxxxxxxx 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@xxxxxxxxx]
> > Sent: Thursday, November 16, 2000 10:45 AM
> > To: stds-802-3-hssg@xxxxxxxx
> > 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@xxxxxxxxxxx
> [mailto:pat_thaler@xxxxxxxxxxx]
> > Sent: Thursday, November 16, 2000 9:12 AM
> > To: bob.grow@xxxxxxxxx; stds-802-3-hssg@xxxxxxxx
> > 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@xxxxxxxxx]
> > Sent: Wednesday, November 15, 2000 3:22 PM
> > To: stds-802-3-hssg@xxxxxxxx
> > 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/