Re: [EFM] Performance monitoring, installation, trouble shoot ing.
Standards generally define observable behaviors. Whatever OAM standard
we get will be defined independently of other 802 mechanisms but will
certainly have implementation specific elements - if there wasn't any
wiggle room for implementation differentiation we as vendors wouldn't
invest nearly the same amount of effort in the process.
I've spoken to several providers as a result of the loopback
conversations of the last meeting, and the viewpoint was very
consistent. Loopback is a hated but necessary function for now. The
reason for the necessity is that there has not been any other method
shown to provide same error localization capability. As discussed at
the meeting, it is incumbent upon those that believe loopback can be
done via other methods to justify that position to the rest of the
community. There are several people that have accepted that challenge
and I believe are intending to do just that. The idea was not to use
CRC but to enhance the 802.3 MIBs with better statistics to count
various symbol errors or the like, from which a more accurate bit error
rate estimation could be determined. Whether that can be done has yet
to be seen. Until then, loopback remains an OAM requirement.
But I'm not sure what any of this has to do with the original note which
simply pointed out that Ethernet links do not have embedded QoS. With
Ethernet networks, QoS has always been defined above L2. None of the
transport proposals rely on anything outside of 802.3 scope.
Bob Barrett wrote:
>
> Matt
>
> I agree and furthermore I would asert that the OAM transport of EFM should
> operate reliably under all possible boundary conditions without dependancy
> on other 802 mechaisms which would make the OAM transport dependent on
> implementation specific elements. This is the Etbernet / 802 way is it not?
>
> Service providers test systems under boundary conditions as well as 'normal'
> conditions, and they want the management to work at all times.
>
> I have been at an ILEC test lab this week. The first thing the test guys
> said to me about management was that it must do loopback. The next things
> was that using CRC for BERT is not acceptable as that means the kit looks at
> the payload. TRUE!! They took work all the time as a given. I asked them to
> come to the March meeting and repeat those statements. Their travel budget
> might not allow it but I will request a letter or an email to the group from
> them.
>
> Any ILEC people out there please activily agree or disagree with these
> views - thanks.
>
> Best regards
>
> Bob
>
> -----Original Message-----
> From: owner-stds-802-3-efm@majordomo.ieee.org
> [mailto:owner-stds-802-3-efm@majordomo.ieee.org]On Behalf Of Matt Squire
> Sent: 24 January 2002 16:11
> To: joey.chou@intel.com; stds-802-3-efm-oam@ieee.org
> Cc: stds-802-3-efm@ieee.org
> Subject: RE: [EFM] RE: [EFM-OAM] Performance monitoring, installation,
> trouble shoot ing.
>
> Speaking only for myself...
>
> 802.3 defines an Ethernet link, not a network, and Ethernet links have
> no intrinsic QoS mechanisms. What 802.1D or IP or anyone else does as
> far as prioirty queueing in order to gain access to this link is a
> problem thats important to address - but not here.
>