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

Re: [EFM] Loop back




Roy:
This operating expense or "opex" is a critical issue that we cannot ignore.
Although the MEF is having substantial process problems, at least it is opening up
the opex issue for consideration.  Broad market depends on our keeping this item in
hand.
Richard Brand

Roy Bynum wrote:

> Ramu, Bob,
>
> Service providers control a MASSIVE market.  I use the word control,
> because they do control it through the already built infrastructure.  They
> dictate the systems that go on that infrastructure for them to implement
> service facilities sot that they can generate revenue from the services
> that are on those facilities.  They define the infrastructure and
> facilities requirements that are needed to be able to support the service
> level agreements that their customers are demanding.  This is not a democracy.
>
> The service providers are an existing customer base with existing
> requirements.  Many of these service providers already have non-standard
> Ethernet facilities that are providing revenue generating services.  Many
> of these services have limitations base on the current standards and
> paradigm of the technology.  It is the EFM TF that is trying to open up
> that customer base to an 802.3 standard for Ethernet facilities and
> services.  It is up to the EFM TF to change the paradigm of Ethernet. It is
> up to the EFM TF to resolve the facilities management and support issues
> with the current standards to be able to enter into that existing market.
>
> It is the operations support people that dictate the OAM requirements of
> the large service provider access subscription network infrastructure and
> facilities, not the marketing people, not the equipment vendors.  Anyone
> that has been through a service provider "certification" for basic access
> infrastructure will tell you how inflexible their requirements are.  They
> are the dictators of the market that the EFM TF is trying to open up.
>
> The real question is whether the EFM TF is serious about opening up that
> market, or are do the believe that this is a market that will bend to the
> will of the vendors the way that the enterprise market has?  The really big
> difference between the service provider market and the enterprise market is
> that the cost of operations support and the "cost" of "downtime" is not
> hidden in the service provider market like it is in the enterprise market.
>
> Thank you,
> Roy Bynum
>
> At 10:35 AM 2/16/2002 -0800, ramu wrote:
>
> >  Bob, just a general comment on the scope of your message:
> >
> >Lots of things would be "useful," it's avoiding the swiss-army-knife
> >syndrome that is in question.  When stating some feature would be useful
> >as part of a wish list, it would help if they also included clarity in
> >exactly how it would be used, how often, and what information it
> >needs/provides. Otherwise it's hard to reduce the wish to practice, and do
> >a cost/benefit analysis.
> >
> >If something is only useful for a small subset of problems that may or may
> >not be frequent on every network, or only useful for certain segments of a
> >particular provider's network, or only for certain claases of users, or
> >only provides golly-gee inactionable data, it probably won't pass
> >cost/benefit analysis.
> >
> >If the "customer" is a contractually-bound customer, with 100 million
> >units under contract, rather than a "potential customer," then we don't
> >bother with the cost benefit analysis. I don't recall any potential
> >customers openly endorsing EFM and its importance to their future; in fact
> >the open endorsements are for a competing standard. I also seem to recall
> >rather large recent cutbacks in broadband deployments by said providers.
> >
> >That said, I don't think any providers quite qualify for dictator status,
> >and they have to provide justification along with their wish, just like
> >any other "potential" customer. If it is really needed, providing the
> >cost/benefit justification ought to be a simple exercise. They would have
> >already done it to determine they need it in the first place.
> >Ramu
> >--
> >
> >On Sat, 16 Feb 2002 09:49:16
> >  Bob Barrett wrote:
> > >
> > >Emmmmm,
> > >
> > >So, OK members of the OAM track, here we have a service provider stating
> > >that loopback functionality is important to them. It may be a pian but it is
> > >still a requirement. We have been asking for their contributions and here is
> > >one from one of the big four. It would be very useful if the other three big
> > >US SPs, and the enumerable ROW SPs, could also make a contribution on this
> > >topic.
> > >
> > >The most useful place for loopback is on the customer side port of the
> > >demarc, as near to the customer cable connection as possible, so may be this
> > >is out of scope for EFM. However, I think the OAM protocol should specify
> > >loop back selection / time out parameters (as per my January presentation),
> > >even if the specification does not define where the loop back is to be
> > >implemented.
> > >
> > >My flight landed at 0700 GMT, and it is now four meetings and three meals
> > >later (0055 the next day). May be I really am a workaholic :-).
> > >
> > >Bob
> > >
> > >-----Original Message-----
> > >From: kmccammon@xxxxxxxxxxx [mailto:kmccammon@xxxxxxxxxxx]
> > >Sent: 16 February 2002 00:19
> > >To: mattsquire@xxxxxxx; bob.barrett@xxxxxxxxxxxxxxxxxx
> > >Cc: joey.chou@intel.com; stds-802-3-efm@ieee.org
> > >Subject: RE: [EFM] Performance monitoring, installation, trouble shoot
> > >ing.
> > >
> > >
> > >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.
> > >> >
> > >>
> > >
> > >
> > >
> >
> >
> >Is your boss reading your email? ....Probably
> >Keep your messages private by using Lycos Mail.
> >Sign up today at http://mail.lycos.com