-----Original Message-----
From: Drew Perkins
[mailto:dperkins@xxxxxxxxxxxx]
Sent: Saturday, September 02, 2006
9:47 PM
To:
STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx
Subject: Re: [HSSG] Reach
Objectives
Guys,
Rather than arguing about a horse that
left he barn years ago, I believe the more interesting debate is to what degree
a higher speed Ethernet should be able to leverage existing 10 GbE technology.
My belief is that it should to the highest degree possible and for the longest
period of time that it remains the most economical solution. To be specific, I
believe that an Nx10G technology will be the best solution for some number of
years. Not to say that an Nx20G, Nx40G or even Nx100G will not become practical
and more economical in the future. At the point it provides compelling
economically to implement we should revise the standard to support that. If you
agree with this, then I further submit, again, that we should support all the
existing 10G PHYs, including LAN-PHY and WAN-PHY versions. This will allow us
to leverage the work that’s already gone into making these transportable
across the WAN without making the problem for WAN vendors any worse than it is
today. Given that essentially everyone is already providing solutions to the
rate mismatch problem, it is unnecessary to fix what’s already been
fixed.
Drew
_____________________________
Drew Perkins
Chief Technology Officer
Infinera Corporation
1322 Bordeaux Drive
Sunnyvale, CA 94089
Phone: 408-572-5308
Cell:
408-666-1686
Fax:
408-904-4644
Email: dperkins@xxxxxxxxxxxx
WWW : http://www.infinera.com
_____________________________
From: Trowbridge,
Stephen J (Steve) [mailto:sjtrowbridge@xxxxxxxxxx]
Sent: Saturday, September 02, 2006
8:30 PM
To:
STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx
Subject: Re: [HSSG] Reach
Objectives
Geoff,
I fully agree with you. This should never
have been a problem because bit transparency of the full physical layer is
considerably more than what should be needed for transport of something called
Ethernet. What should be important is transparency of the packet payload,
characteristic information, traffic units, or whatever you want to call the
stuff that is carried over an Ethernet network.
But what we learn from experience is that
there isn't a lot of way to avoid that someone uses something in a way
that was never intended.
We have discovered at least one router vendor
who carries proprietary stuff (I assume OAM) in the preamble and insists that
the preamble be carried transparently so as to not break this proprietary use.
I understand that there exists a mapping of 10 Gigabit fibre channel into
Ethernet that encodes something in the IPG.
I agree that this should never have
happened, but we now see a lot of market pressure, resulting in some network
operators and equipment vendors caving into the pressure to offer
carriage of a 10G Ethernet signal in a fully bit transparent
manner - every one of the 10.3125 Gbit/s being carried intact including
the 64B/66B coding!
In reaction to a proposal that we now need
to change the OTN bitrates in ITU-T to carry the full 10G BASE-R signal with
64B/66B coding over an ODU2-like structure with a higher bitrate, one of the
participants quipped that it sounded like someone wants us to change the
standard so that we can carry something that isn't Ethernet over something that
isn't OTN.
What I am arguing for is that, for the
next higher rate, we avoid defining different interfaces with slight
difference in data carrying capacity. Doing this leaves open a crack
that might be used improperly (or at least WHEN it is used
improperly, it breaks something or introduces some unexpected constraint
in the network).
Regards,
Steve
From: Geoff
Thompson [mailto:gthompso@xxxxxxxxxx]
Sent: Saturday, September 02, 2006
6:57 PM
To: Trowbridge, Stephen J (Steve)
Cc:
STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx
Subject: Re: [HSSG] Reach
Objectives
Steve-
There is something that you are talking about here that I don't understand.
At 11:40 AM 9/2/2006 , Trowbridge, Stephen J (Steve) wrote:
David, One of the "mistakes of 10G" was having effectively
defined MACs of two slightly different rates - one for LAN PHY and the other
for WAN PHY.
While one might assume that one would select the correct interface for the
correct purpose, experience has shown that this is not the case. We have way
too many examples of cases where someone builds something around a 10G LAN PHY
and then expects it to be transported with absolute bit transparency across a
wide-area network (e.g., a secure government application where they insist that
the service provider not touch the payload).
Here is the part I don't understand. We (Ethernet) provide a packet service,
not a SONET service. We should be able, even with speed changes, to be able to
provide absolute bit transparency of the data portion of frames for anything
going across a network (as long as the preamble, SA, DA and type are not
encoded) and absolute bit transparency of the entire data frame if it is going
across a point-to-point connection ( i.e. bit-for-bit replication of IPGs and
preambles are not guaranteed, everything else should be).
If the customer wants to do encryption across multiple Ethernet packets*, then
what they want is not Ethernet. If all they want is integrity of the payload
then there shouldn't be a problem.
Preambles are not payload
Interpacket gaps are not payload.
Why are we failing to communicate?
Best regards,
Geoff
* with encryption algorithms that, for example, encrypt or even count the
"bits" (they aren't really bits) between packets.
While some vendors have provided proprietary solutions (e.g., an OTU2
like frame structure at a higher clock rate), there is no standard way to do
this. There are a comple of different proprietary mappings that do not
interwork with each other. None of them work in other than a point-to-point
configuration. Since the operate at a higher bitrate, they don't have the
spectral characteristics of G.959.1 interfaces. They don't have the clock
accuracy required in G.709 or follow the jitter/wander characteristics of
G.8251. And they can't be multiplexed up to standard OTU3 40 Gbit/s interfaces.
I think that it is extremely important to avoid this debacle at the next rate.
We can certainly use a variety of different physical interfaces, but to have a
variety of slightly different payload bitrates is a disaster.
Regards,
Steve