Re: [EFM] Performance monitoring, installation, trouble shoot ing.
Bob,
The reason an ILEC wants proven tools like loopbacks and BERT tests is that
it could prevent a truck roll. If they can show, often in real time, that the
problem is not on their side of the DEMARC, they can eliminate one side of the
problem and go right on to helping the customer trouble-shoot their side. Or,
having shown that it is on their side, go out with some good starting
information. Saving a truck roll means saving big bucks.
Thanks,
George
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.
>
> > -----Original Message-----
> > From: Chou, Joey [mailto:joey.chou@xxxxxxxxx]
> > Sent: Wednesday, January 23, 2002 6:01 PM
> > To: carlosal@xxxxxxxxxxxxxxxxxx; Geoff Thompson
> > Cc: bob.barrett@xxxxxxxxxxxxxxx; mattsquire@xxxxxxx;
> > stds-802-3-efm-oam@ieee.org; stds-802-3-efm@ieee.org
> > Subject: [EFM] RE: [EFM-OAM] Performance monitoring, installation,
> > trouble shoot ing.
> >
> >
> >
> > Geoff and Carlos,
> >
> > End-to-end QoS is required, if the IP networks were to
> > support the mix of
> > real-time (e.g. voice, video) and non-real-time(e.g. data)
> > applications. It
> > is true that several mechanisms, such as Diffserv, RSVP,
> > MPLS, have been
> > designed in the upper layers to support QoS. However, the
> > true end-to-end
> > QoS will not happen until QoS is supported in every network
> > segment along
> > the path. 802.1D user_priority uses 3 bits in the 802.1Q VLAN
> > tag to define
> > 8 types of traffic riding in the Ethernet frame.
> >
> > I thought there should be a need for an OAM requirement to
> > support 802.1D
> > user_priority bits to prevent voice packets from blocking by
> > huge Ethernet
> > data packets.
> >
> > Regards,
> >
> > Joey Chou
> > Intel
> >
begin:vcard
n:Schroeder;George
tel;work:503-466-7500
x-mozilla-html:FALSE
url:www.credence.com
org:Credence Systems Corporation
adr:;;5975 Pinefarm Place;Hillsboro;Oregon;97124;USA
version:2.1
email;internet:George_Schroeder@xxxxxxxxxxxx
title:Senior Applications Engineer
end:vcard