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

Re: [EFM] Re: [802.3ae] query -LayerMgmtReceiveCounters


 From a technical aspect, you are very correct.  The purpose of not 
allowing a corrupted frame to get to an application is the issue as a 
technical requirement.  The reason that I am bringing a little more 
visibility to this issue is that there are non-technical issue involved 
with the EFM market and broad market acceptance of EFM technology.

The aspect of supporting and documenting the adherence to the contractual 
requirements of service level agreements is an ongoing problem in the 
service provider community.  One of the primary reasons for all of the "out 
of band" functions in the legacy service provider technology is the need to 
be able to document adherence to SLAs.  This becomes very important as 
economic issues between service providers and customers tend to take on an 
adversarial quality. (This is the best way that I could word this and stay 
within the IEEE guidelines.)

It is up to the service provider's support and operations people to qualify 
the requirements of any one technology for a particular SLA .  Business 
support and operations people have to then also quantify the economic 
aspects of the services that a particular technology will support, given 
the SLA it can support.

In short, it is up to the business, support, and operations people of the 
service providers that determine whether it is a "don't care", not the 
vendors of EFM.

Thank you,
Roy Bynum

At 09:52 AM 3/7/2002 -0800, Shimon Muller wrote:
> >  From what you are saying then is that bit errors in certain locations may
> > not be recognized as bit errors.  This would mean that if the performance
> > monitoring function is at the frame error level, it may not be 100%
> > accurate.  Is that correct?
>The short answer is yes.
>The long answer is: Who cares? The important thing is that a corrupted frame
>is not passed to an application and the probability of an undetected error is
>not affected. Furthermore, although the count may not be "100% accurate", it
>is pretty close to that. Keep in mind, for this error to be missed by the CRC
>counter, it has to occur in the first six bytes of a frame AND not violate
>the coding rules in the physical layer. I will leave it to you figure out the
>probability for such an event, but I would assert that it is pretty low...
>                                                 Shimon.