RE: [EFM] p2mp carrier requirements
Bob,
I would add that the ability to bill for services is based being able to
meter the services (turn it on or off) and the ability to measure it if it
is not already delivered on a "fixed" logical or physical
facility. Metering services is very simple for the more deterministic
delivery facilities. Being able to "measure" services, from a customer
viewpoint as well as a service provider viewpoint, is the issue that is
driving flat rate billing into becoming more popular for the
"commoditized" services.
I would also add another question into evaluation of "broad market
potential". What kind of services can be delivered over a deterministic
delivery facility versus a statistical gain based delivery
facility? Should this question be a new thread for discussion on the
reflector, or should it be a subject of a presentation at the next TF meeting?
There is also a component that is often not included in the "mix" when
evaluating potential "success" of a service and/or deployment technology,
"overall cost of ownership". The overall cost of ownership includes not
just the capital cost of the equipment, inside plant, outside plant, etc,
but also the operations service systems (OSS), other back office systems,
and the support labor costs that it takes to support the service such that
customers will be willing to pay for it. The OSS, back office, and
operations labor support costs are often "hidden" and difficult to
"quantify". I have seen the adage "I have never seen something made more
complicated and less expensive at the same time" apply to these hidden
costs of ownership. This adage would tend to also favor the "fixed"
facility model with deterministic delivery because it has less complicated
OSS, back office, and operational labor issues.
Thank you,
Roy Bynum
At 11:56 AM 1/23/2002 +0000, Bob Barrett wrote:
>Carlos
>
>I think the fundamental point that you are making is this:
>
>If vendors ask their customer's what they want before designing products
>then the greater the chances of business success. Ditto if standards bodies
>listen to the users .....
>
>However, we also have the issue of APON and FSAN where customer's specified
>the standard and yet business successes based on these technologies are few.
>
>I think the EFM p2mp specification should support a mechanism that can be
>used as a base by implememters to support deterministic delivery of frames.
>The alternative is to ignore this issue and force implementers to put on an
>overlay protocol which to me looks like inverting the reference model.
>
>What we have in the p2mp track is broad agreement on a compromise protocol
>based on existing technologies. Any one vendors would like to see their
>existing protocol as the standard, but this will not happen, so the group
>settles for a compromise.
>
>Personally I think there is a better p2mp protocol defintion out there that
>is not currently 'owned' by a vendor. However, it may look a bit too much
>like SONET / TDM to be accepable to the EFM group.
>
>The basic technical argument hinges on the issue of deterministic delivery
>versus statistical gain. The business case (economic feasibility / broad
>market acceptance) hinges on the relative / comparitive cost of the
>equipment and the relative / comparitive revenue that can be derived from
>services delivered over that equipment. (I didn't mention dollars there or
>the 'M' word.) In the LAN world statistical gain rules. In subscriber
>transport and services the amount that a service can be billed for is
>directly related to the customer's perception of the quality of that service
>(quality in the broadest sense).
>
>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
>carlosal@xxxxxxxxxxxxxxxxxx
>Sent: 21 January 2002 18:20
>To: 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 shooting.
>
>
>
>
>Geoff,
>
>Thanks for your comments. Just to make my point clear: I was not
>requesting, or even defending, that EFM should explicitly support QoS, or
>synchronous services, or anything similar. I was concerned about the way we
>are discussing requirements. In my opinion, we can't even start discussing
>specific technical requirements if we dont have a thorough understanding of
>the service requirements. I've been insisting on this position for a long
>time, for one very important reason: it's fundamental to understand the
>application before we start discussing technical details.
>
>I'm not the only carrier representative tracking these email reflectors.
>While as a group we diverge on a lot of things (for example: maximum loop
>lengths), we (mostly) agree on other things, namely in the fact that we
>expect EFM to provide a common framework for the access network, supporting
>not only data services, but also voice and video. There are many different
>ways to support these applications, ranging from explicit support to the
>assumption that the upper layers (read IP) will take care of this.
>
>The actual requirements for OAM depend on two questions, both still pending
>discussion:
>
>Q1. what are services directly supported by EFM;
>Q2. what is the typical business model for EFM deployment.
>
>The answers for these questions are by no means absolute: every SP will
>give you a different answer. Even then, it's possible to understand the
>main applications we (service providers) foresee for EFM, and then proceed
>with the technical requirements.
>
>Thanks again, and best regards.
>
>
>
>Carlos Ribeiro
>CTBC Telecom