Re: [EFM] Re: [802.3ae] query -LayerMgmtReceiveCounters
Shimon,
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.