RE: RMON and 802.3 harmonization
Without taking upon my shoulders the responsibility of talking on behalf of
the IETF, I can safely comment that the IETF will consider new work, if
there is enough interest from the Internet management community for the
subject, and enough expert working force that commits to be active in doing
the work. The RMON MIB Working Group is right now quite active, but the work
is focused mainly on management of higher layers (transport performance and
application performance monitoring). However, in the future the RMON Working
group or the Ethernet Interfaces and Hub MIB Working Group might look into
new work as a result of the evolution of the IEEE standards - if there is
enough interest and resources for the work to happen.
I agree with Pat's assessment that schedules are important. I would however
like to observe that there is confusion in the industry - among customers
and vendors as well - about which standards apply for an Ethernet interface
or for Ethernet networks to be managed. This is bad enough right now, but it
will become worse as Ethernet seems to extend beyond local boundaries
('first/last mile', 'Ethernet as WAN Protocol'). Access and Carriers
environments have more rigorous management requirements. Unless the 802.3
Working Group takes a more focused approach on the management issues, and
works closer with the IETF to issue one set of management objects definition
and MIBs, the management issue might turn into an obstacle to the speed of
advancement of the technology.
Regards,
Dan
> -----Original Message-----
> From: pat_thaler@xxxxxxxxxxx [SMTP:pat_thaler@xxxxxxxxxxx]
> Sent: Fri November 17 2000 20:03
> To: bob.grow@xxxxxxxxx; millardo@xxxxxxxxxxxxxxxxxx;
> stds-802-3-hssg@xxxxxxxx
> Subject: RMON and 802.3 harmonization
>
>
> 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/