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

RE: [EFM] Performance monitoring, installation, trouble shooting .

My apologies for sending out a message in support of loopback without any
explanation and the confusion and resultant discussion it evoked.

Let me try again...

I can try to inform the community on one aspect of loopback.  We have a
method to apply loopback tests on DS1 service using remotely controlled test
systems.  We can tell if a DS1 service that can traverse multiple offices
and terminals is in failure in different portions, fault isolation.  We need
to know if the problem is at our equipment at the customer location before
we hand off the interface. If EFM standards could incorporate such a feature
in its solutions, that would be a good thing for any operator, whether they
have alot of market share or not. Its a distinct feature of an access
network that we need information to tell us that the problem with the
circuit is in our network or the customers network after the interface.  

For example, people in SBC operations are saying that Gigabit P2P interfaces
need this type of functionality.  I would extend that to say that a P2MP
ONT/ONU with a T1, GIgE customer interface should have such a feature and
the method could be made to work with the automated test systems embedded in
operators networks.  For new entrants with a clean start, an opportunity
exists for someone to build automated test sets for them.

Roy, your right, it is a requirement to have loopback with TDM services and
likely for new services by either the same method or something equivalent.

Finally, bringing together OAM for P2MP, P2P, copper in common is a worthy
goal. SBC is trying to find a single position on OAM (frame vs. preamble),
since different people in the company in different groups have the different
areas, finding a common position is not so easy. We are trying to get back
to the group on that as we have had multiple requests to comment.


Broadband Access Group
SBC Technology Resources, Inc
4698 Willow Road
Pleasanton, CA 94588

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: Charles Cook [mailto:cicook@xxxxxxxxx]
Sent: Monday, February 18, 2002 6:47 AM
To: mattsquire@xxxxxxx
Cc: Roy Bynum; Mccammon, Kent G.;
Subject: Re: [EFM] Performance monitoring, installation, trouble
shooting .

To add to the SBC comment:  Loopback functionality is a basic functionality
is a requirement of most (if not all) service providers.  Loopback
is a requirement for Qwest as well.


Matt Squire wrote:

> I'll repeat the current status of loopback within OAM.
> - A ping connectivity test is a requirement.
> - A loopback mode is a requirement.
> - Controlling the state of the loopback mode at the other end of a link
> is a requirement.
> There is also a group of people that believe that the functionality of
> loopback can be achieved without a loopback mode, but enhancing the MIBS
> and the PHY functionality.  They are actively investigating the
> possibility.  When and if they think they can show equivalent
> functionality, the results will be presented to the reflector.  At that
> point everyone can judge whether the alternate method provides
> equivalent function.
> Loopback itself is a function.  The function is used to fulfill certain
> operational requirements.  If those requirements can be met with other
> methods, and this point can be provent to the group as whole (including
> Kent), then the other methods deserve consideration.  I don't think this
> is in any way conflicts with Kent's statement (though I'm sure he'll
> correct me if I'm wrong).
> Loopback will remain a requirement until someone can prove to the OAM
> group that there is a better way.
> - Matt
> Roy Bynum wrote:
> >
> > 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
> > 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
> > 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
> > 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
> > >