RE: [EFM] p2mp carrier requirements
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