RE: [EFM] Re: OAM Transport Proposal
This looks OK. There is need for change to accommodate the new type of messages, but the change is incremental. Thanks, Dan
> -----Original Message-----
> From: Rich Taborek [mailto:rtaborek@xxxxxxxxxxxxx]
> Sent: Wednesday, May 01, 2002 7:05 AM
> Cc: stds-802-3-efm@ieee.org
> Subject: Re: [EFM] Re: OAM Transport Proposal
>
>
>
> Dan,
>
> This is all the more reason for not calling the 8-byte OAM
> link message
> sent during IPG in the absence of Ethernet packets a "frame".
> These OAM
> messages never get to the MAC, so they cannot be mistaken for Ethernet
> frames or packets. The OAM link messages have the same format
> as the OAM
> preamble sent along with an Ethernet packet for reasons of
> architectural
> simplicity. What we need is a new name for these messages so they are
> not mistaken for frames or packets.
>
> Best Regards,
> Rich
>
> --
>
> "Romascanu, Dan (Dan)" wrote:
> >
> > > 4) Null/dummy frames break MIBs? I don't think its that bad.
> > > Certainly
> > > the MIB would have to be enhanced with a counter for the
> > > number of such
> > > frames, but the changes are minimal.
> > >
> > >
> > > - Matt
> >
> > It's a little bit more complicated, I am afraid. If the
> required change would be adding one or even more objects,
> this would be certainly palatable. This is not considered as
> 'breaking' current standards. However, changing the threshold
> of what is considered a minimal length frame is a change in
> semantics that would make the existing implementations of the
> Ethernet and RMON MINS counters inaccurate for EFM. It is not
> only that the new type of frames are ignored, but also
> existing counters become inaccurate. We also need to take
> into account that most implementations do this counters in
> silicon. EFM will require replacing the current installed
> base of management silicon and monitoring devices and
> applications, and will not be capable of coming and saying
> 'you can use the current deployed base of applications and
> monitoring problems'.
> >
> > This relates to the later question (#6 in your list) as a
> strong argument to make the null/dummy frames be 'true'
> Ethernet frames of minimal size'.
> >
> > Regards,
> >
> > Dan
>
>
>