[EFM] Re: [EFM-Copper] Long Reach Copper Presentations in Vancouver
John,
I have to jump in here.
We could think of Ethernet as a service. We could think of Ethernet as a banana
(see other thread).
The fact of the matter is that it is neither. Please take the time to read the
802.3 document. Ethernet defines a MAC (just one!) and a limited set of physical
layer interfaces. If you have any other perception of Ethernet then I suggest
that you are reading the wrong document.
You may consider this a way to cut through the knot. I think that most of the
authors of the Ethernet standard would consider it cutting through the heart of
their creation.
All that has an MII is not Ethernet (and, of course, vice-versa).
Hugh.
John Farnbach wrote:
> Steve, and all,
>
> Steve makes some good points below. It seems to me that the most compelling
> point is that the Ethernet standards have always specified the physical
> layer. 22 years ago when Ethernet was first being developed, it was necessary
> to specify it all the way down to the physical layer. Otherwise, how could
> you connect one ethernet port to another?
>
> Only consider this: What if we think about Ethernet as a service, rather than
> a physical network? Service providers today are very good at physical layer
> connectivity, they do it all the time over a variety of links, including HDSL,
> ADSL, and SHDSL. There would be less, not more, confusion by defining EFM
> above the byte pipe layer. Steve asks, which version of EoCu would a carrier
> install... They would install the byte pipe of their choice and layer
> Ethernet on top of that. Only one version of Metro Ethernet, not many. There
> is not any confusion in saying that EFM operates over any byte pipe--They
> already know how to make byte pipes work.
>
> And what about the carriers who have a kind of byte pipe installed tht may not
> be the one chosen for EFM? It would be much easier for them to provide
> Ethernet service over any byte pipe than to have to change out all their
> physical links to the one that might be chosen.
>
> Just seems to me that there is a simpler way to cut through the knot.
>
> John
>
> Steve Jackson wrote:
>
>> Threaded response:
>>
>> -----Original Message-----
>> From: John Farnbach [mailto:john.farnbach@xxxxxxxxx]
>> Sent: Thursday, December 19, 2002 2:37 PM
>> To: Steve Jackson
>> Subject: Re: [EFM-Copper] Long Reach Copper Presentations in
>> Vancouver
>> Steve, thanks for the info. You're welcome.I may be wrong, but it
>> seems to me that it is technically and logically possible to
>> define the MAC and the 'gamma" interface for an EoDSL layer and
>> leave the lower layers open. It is technically and logically
>> possible, of course.Seems like that would be very effective and
>> would guarantee interoperability, provided that the two ends of a
>> link interoperated at the PMD layer. Um, no. Doing so would
>> create massive market confusion. Tell me, how many versions of
>> EoCu would show up on the market? Six? Eleven? Which one does
>> BellSouth use? Verizon? France Telecom?See what I mean?Are you
>> saying that the original PAR requires that 802.3ah must define the
>> physical layers as well?
>>
>> Yes. The 5 requirements include "broad market acceptance" and
>> "technical feasibility" among other definitive statements.
>>
>> That seems counter-effective.
>>
>> Hmmm. 100BASE-T specifies a PHY (actually, several) for example.
>> Most implementations have an embedded MII. Are you saying that we
>> should have just said "oh, use whatever you like, the MII is
>> spec'd out" and let vendors ensure PMD interoperability?
>>
>> No, you couldn't mean that. ;-) What did you mean?
>>
>> As demonstrated by the ADSL/SHDSL debate, over defining the
>> standard just gives more room for debate. Is it possible to go
>> back and modify the PAR?
>>
>> The ADSL / SHDSL debate is caused by the semiconductor vendors who
>> have megabucks invested in DMT and QAM development. It's not a
>> real argument in and of itself. If SHDSL is approved, it's seen
>> as a huge advantage to the VDSL SCM vendors, and vice-versa.
>>
>> Realistically, we're too far down the road to even re-write the
>> objectives, much less rewrite a PAR and start over. More likely,
>> we'd just drop the whole standards effort first.
>>
>> /steve
>>
> --
> John Farnbach, Managing Partner
> Farnbach Associates
> <john.farnbach@xxxxxxxxx>
> tel/fax: 303-448-9852
> 4022 Old Westbury Court, Suite 202, Boulder CO 80301
>