Re: RMON and 802.3 harmonization
Pat,
I don't buy that argument for a minute. I will not get into a semantic
discussion of what constitutes a "proposal", a "feature" or a "technical
change". It comes down to the concensus of the group as to what's in,
and what's out of 802.3ae. The question is whether inclusion of this
work would adversely affect the schedule for completion of 802.3ae.
My personal opinion is that the schedule impact would be nil.
As to the first mile activities, there may be new management objects,
and if there are, the group will specify them. However that doesn't mean
that an EFM project (IF one is approved) should take on the responsibility
for aligning the IETF and 802.3 MIBs.
The fact is that hardware and software designers and their customers need
a definitive MIB specification. If we want rapid deployment and acceptance
of 10 Gig, we should make sure that the definitive spec is produced.
Howard Frazier
DomiNet Systems
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
> deliminating
> > the frame on the PCS without the RS changing that determination.
> >
> > --Bob Grow
> >
> > -----Original Message-----
> > From: THALER,PAT (A-Roseville,ex1) [mailto:pat_thaler@xxxxxxxxxxx]
> > Sent: Wednesday, November 15, 2000 1:52 PM
> > To: Grow, Bob; 'James Colin'; stds-802-3-hssg@xxxxxxxx
> > Subject: RE: RUNT Packets
> >
> > Bob,
> >
> > I do not understand your point. At lower speeds, there are four possible
> > causes of a runt -
> >
> > A noise hit causes a short event on a segment which arrives at a repeater,
> > since ther repeater never transmits less than a minimum size fragment it
> > sends a runt.
> >
> > A collision fragment
> >
> > A noise hit that causes an end delimiter to be detected in error.
> >
> > Someone transmitted a frame smaller than the minimum frame size. (Is this
> > the protocol error you referred to?)
> >
> > Therefore, at the lower speeds, runts can be caused by noise, the normal
> > operation of CSMA/CD or transmission shorter than the minimum. For full
> > duplex they are only caused by noise or transmission shorter than minimum.
> >
> > Pat
> >
> > -----Original Message-----
> > From: Grow, Bob [mailto:bob.grow@xxxxxxxxx]
> > Sent: Tuesday, November 14, 2000 10:52 AM
> > To: 'James Colin'; stds-802-3-hssg@xxxxxxxx
> > Subject: RE: RUNT Packets
> >
> > A minimum frame size was established at 10 Mb/s to assure that collisions
> > were detected. Shorter "runt" frames are an error and are commonly
> counted
> > and monitored in management databases. In the desire to maintain
> > consistency over all speeds of ethernet, we should attempt to preserve
> > similar error properties. If the RS turns an error created by
> transmission
> > noise into a protocol error (e.g., runt frame) we are violating the
> > objective to make things look the same.
> >
> > --Bob Grow
> >
> > -----Original Message-----
> > From: James Colin [mailto:james_colin_j@xxxxxxxxx]
> > Sent: Tuesday, November 14, 2000 2:50 AM
> > To: stds-802-3-hssg@xxxxxxxx
> > Subject: RUNT Packets
> >
> > Louis, Bob
> > Can you explain the term "runt packets"?
> > Thank you,
> > James
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Yahoo! Calendar - Get organized for the holidays!
> > http://calendar.yahoo.com/