Re: [HSSG] Reach Objectives
Drew-
The problems that Stephen was referring to had nothing to do with rate
mismatch. They were a result of a proprietary feature that was encoded in
such a way that any were the packet to actually pass through compliant
equipment the proprietary data would be deleted.
Geoff
At 09:47 PM 9/2/2006 , Drew Perkins wrote:
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