RE: [EFM] Performance monitoring, installation, trouble shoot ing .
Kent,
I have found that if you do not use strong enough language, the vendors
that may not have what you require, will attempt to "interpret" your words
so that they can mean something totally different than what you
intended. If I am correct, you may want to resend your comment and use the
words "our operations requires that ability". If you check with your
equipment "certification" people for edge access infrastructure, you may
find that loop back functionality at the physical layer is a hard
requirement, just like it is on T1/T3 infrastructure today. I know that it
was a requirement the large service provider that I was previously with.
Thank you,
Roy Bynum
At 04:18 PM 2/15/2002 -0800, kmccammon@xxxxxxxxxxx wrote:
>Bob,
>Loopback functionality is important for SBC, our operations need that
>ability.
>-Kent
>
>Kent G. McCammon
>Broadband Access Group
>SBC Technology Resources, Inc
>4698 Willow Road
>Pleasanton, CA 94588
>925-598-1246
>kmccammon@xxxxxxxxxxx
>
>The proposals in this submission have been formulated to assist Standards
>committees. This document is offered to the committee as a basis for
>discussion and is not binding on SBC Communications or any of its
>subsidiaries or affiliates. The requirements are subject to change in form
>and in numerical values after more study. SBC specifically reserves the
>right to add to, or amend, the quantitative statements made herein. Nothing
>contained herein shall be construed as conferring by implication, estoppel,
>or otherwise any license or right under any patent, whether or not the use
>of information herein necessarily employs an invention of any existing or
>later issued patent.
>
>
>
> > -----Original Message-----
> > From: Matt Squire [mailto:mattsquire@xxxxxxx]
> > Sent: Sunday, January 27, 2002 9:04 AM
> > To: Bob Barrett
> > Cc: joey.chou@intel.com; stds-802-3-efm@ieee.org
> > Subject: 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.
> > >
> >