Re: [802.3BA] WAN PHY and DWDM interaction (was Re: [802.3BA] Longer OM3 Reach Objective)
Steve,
With regarding to the straw poll of PFP, my recollection is there are large
percentages of abstaining votes, an indication that more information will be
needed for them to make their determination. Even those who have voted
against may very well change how they vote when better informed of the
needs. A very recent example is the 40G over 10km SMF. The vote count was
very different only 3 months ago.
As for the per-lane based PHY OAM, you are correct that it is independent of
the architecture choice, although it seems more clear-cut with the PBL. In
the case of MLD, it will be per VL. The application and the need has been
very well established by KDDI in takahashi_01_0308.
Regards,
Wenbin
-----Original Message-----
From: Trowbridge, Stephen J (Steve) [mailto:sjtrowbridge@alcatel-lucent.com]
Sent: Wednesday, March 26, 2008 5:33 AM
To: STDS-802-3-HSSG@LISTSERV.IEEE.ORG
Subject: Re: [802.3BA] WAN PHY and DWDM interaction (was Re: [802.3BA]
Longer OM3 Reach Objective)
All,
No doubt 10G Base-W was a better solution than it ever got credit for,
but surely it didn't reach its potential and there are aspects of it we
should not try to replicate.
One thing not to replicate is to have a difference in throughput
depending on whether you are going over a WAN. While in a packet
environment, a small difference in throughput should not be so
important, I think this is one of the aspects that resulted in 10G
Base-W not being the success that many had hoped. While we have several
proposals in front of us, not having made any baseline choices, we still
have a blank sheet of paper in front of us and have the ability to
select solutions that do not have this attribute.
Another attribute not to replicate is to try to copy transport network
framing and operations aspects into the LAN standard. The 10G Base-W
copied the STM-64/OC-192 frame that was used to carry it - almost. Not
quite all of the overhead is filled in. The clock is 20ppm instead of
4.6 ppm. You will find an appendix to ITU-T Recommendation G.707 that
indicates some "improvements" that can be made to 10G Base-W that will
enable it to be carried over an SDH network as STM-64. Trying to specify
the transport framing into the LAN standard resulted in a situation
where there was a bit of negotiation needed outside of that standard in
order to actually get it to work for its intended application. So by
"appropriate support" for OTN, we should ensure that the signals can be
mapped (full rate) into the OTN frame, but we should not write the OTN
wrapper itself into the 802.3 standard as was done for the SONET/SDH
frame in the case of 10G Base-W.
Finally as to remote fault signaling - I don't think anyone believes we
will not provide the equivalent the LFI/RFI sequence ordered sets that
are provided in 802.3ae. As far as the Huawei proposal for remote fault
signaling, what this seems to add to the 802.3ae fault signaling is to
do it on a per-lane basis. A few remarks on the merits of that:
- Assuming we go with the MLD architecture (which seems most likely if I
just count supporters), the host board doesn't even know how many lanes
there are, let alone have any individual lane monitoring capability.
Perhaps one could try to monitor virtual lanes, and a failure of one
lane of an n-lane LAN interface might interrupt 20/n virtual lanes, but
I wouldn't want to see a complication that prevents the optical modules
from being very simple. What would the customer do with the information
that a certain set of virtual lanes had failed (other than what they
would do with the information that the interface had failed?)
- There was a rather convincing straw poll in Portland that indicated
this group was not interested in the idea of partial fault protection.
- Before going into any per lane fault detection, I would want to
understand:
* What percentage of the FITs in the interface over all (including cable
FITs) affect only one lane?
* Is there any fault affecting one lane that can be repaired without
replacement of a host board, module or cable whose replacement will
affect the entire interface?
Regards,
Steve
-----Original Message-----
From: Mikael Abrahamsson [mailto:swmike@SWM.PP.SE]
Sent: Tuesday, March 25, 2008 11:50 PM
To: STDS-802-3-HSSG@LISTSERV.IEEE.ORG
Subject: [802.3BA] WAN PHY and DWDM interaction (was Re: [802.3BA]
Longer OM3 Reach Objective)
On Tue, 25 Mar 2008, Paul Kolesar wrote:
> 10GBASE- we have the original four, some multiplied by two for LAN (R)
> and WAN (W): S, L, E, LX4. The WAN interfaces have not found much of
> a market and are probably dying or dead.
I have to object here. WAN PHY lives on in equipment that have framers
that do both modes. It's extremely useful in a DWDM environment and I
know numerous people that will happily take the higher CAPEX of
linecards that support this, plus the slightly lower bit speed, to get
the AIS/RAI signalling from the DWDM system, because it saves on OPEX.
WAN PHY was killed by lack of framers in the beginning, plus the fact
that I believe that numerous vendors saw WAN PHY as competition for
their POS interfaces and therefore chose to price it very high (hope
this is an ok place to mention price).
The fact that most people thought WAN PHY was an optic variant doesn't
help either. The naming confusion lives on in the fact that the same XFP
today (10 km SM) will have two names depending on if you use it in a
OC192/STM64 POS role or 10GBASE-LR/LW role (SR and LR/LW respectively).
Very confusing. Let's not make that mistake again.
I still til this day think that WANPHY was a great idea and would have
been adopted much more in the ISP environment if vendors would have
dared to make the investment needed to get it out the door. Instead if
was hindered by the aftermath of the bubble, right in the middle of a
recession where investment was low and a lot of companies were in pure
survival mode.
I have to chime in with the guys from Huawei that we need to have basic
remote fault signalling in 100GE at the hardware layer, otherwise it
won't take off in the WAN. Make it optional if you want to, then we as
customers can put it into our RFQs when we want to buy equipment.
--
Mikael Abrahamsson email: swmike@swm.pp.se