RE: [EFM] EFM Requirements [really Oregon Trail Etherloop?]
Fletcher,
I have been trying to stay vendor neutral in this discussion.
Per your request, here is our experience in DSL deployment utilizing
Etherloop
as a copper broadband solution.
The following data is based upon the last two years of broadband
provisioning
for Oregon Trail Internet in the rural Pacific
Northwest. I have watched many of our competitors leave the DSL market
as ADSL/SDSL has been too difficult to provision.
The main advantage for us is:
* The ability of Etherloop to function on challenging loops with bridge taps
and gauge changes. This is not marketing; we have hit 100% of our circuits,
within 21Kft, at all of our DSLAMs with 3 different ILECs, without any line
conditioning (bridge tap removal, etc) other than load coil removal.
Depending
on tariffs, CLECs have limited options for conditioning of unloaded pairs.
* The ability of Etherloop to hit distance beyond ADSL and SDSL(even though
Elastic
states 21Kft, we have some customers over 23Kft).
* The simplicity of utilizing Ethernet over DSL, with native integration
from the DSLAM into
our traditional IP architecture without utilization of ATM.
The bottom line, to us, is that Etherloop is cost effective to deploy and
provides
ample margin to continue our broadband deployment into rural America.
For 802.3 EFM, here is a 'best-of-breed' solution that currently employs
802.3 over copper
to 21Kft, with near term futures of 100Mbs EFM according to the last 802.3
EFM meeting
in Portland.
Frank
> -----Original Message-----
> From: Fletcher E Kittredge [mailto:fkittred@xxxxxxx]
> Sent: Wednesday, August 15, 2001 11:43 AM
> To: Frank Miller
> Cc: 'Vladimir Oksman'; 'Hugh Barrass'; Lough, Andy; Sherman Ackley;
> Stds-802-3-Efm (E-mail)
> Subject: Re: [EFM] EFM Requirements [really Oregon Trail Etherloop?]
>
>
>
>
> My burning question for you all at Oregon Trail is: how has your work
> with Etherloop gone and why is it that Etherloop is not just the
> standard for copper 10/100mb/sec EFM? It has been around for a while,
> does it really work as specified?
>
> If does have problems, it would be nice to get the problems into the
> public knowledge base so that the standard could avoid them.
>
> thanks,
> fletcher
>