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

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
> 
> 
>