Re: dog fight
Roy,
As you might expect, I just love a good dog fight :-)
Break Link and Remote Fault are bastions of Ethernet link management and
generally all that is needed to manage an Ethernet LAN link. OAM&P is associated
with SONET/SDH, provides Break Link and Remote Fault support along with a myriad
of functions and features, most of which are not applicable to Ethernet.
Besides, LSS is capable of supporting both Break Link and Remote Fault for LAN
PHY links used in LAN environments as well as OAM&P for LAN PHY links used in
MAN/WAN environments.
Please see my additional comments below:
Roy Bynum wrote:
>
> Ben,
>
> I may start a dog fight with this comment but here goes.
>
> I question why there needs to be so much effort to insert "break link and
> remote fault" when OAM&P functionality was the primary purpose behind the
> WAN compatible PHY. There was a lot of argument about how to best go about
> providing that OAM&P. There was a MAJOR compromise to split the PAR into
> two distinct PHY logics, one with OAM&P and one without.
There was never any PAR split. The HSSG merely added a WAN PHY objective to
provide direct mapping from 10 GbE to OC-192c/SDH VC-4-64c
> Now I am seeing an attempt to put OAM&P functionality into the PHY logic
> that originally specifically excluded OAM&P. I voted against LSS because
> the additional complexity in a LAN is not needed. If an implementation
> architecture requires OAM&P, the WAN compatible PHY is available.
The WAN PHY is deemed by some to be far more complex and costly than required to
connect Ethernet LANs together without going through SONET equipment. Granted,
these are greenfield applications. However, there are customers for Ethernet LAN
PHY links beyond the LAN. The WAN PHY is neither intended as an Ethernet LAN
link nor a SONET replacement. Its sole purpose is to facilitate the attachment
of 10 Gbps Ethernet equipment directly to SONET.
> There should not be any optical distinctions between the LAN PHY without
> OAM&P and the WAN compatible PHY with OAM&P.
I'm not sure what this statement implies. If it implies what I think it implies,
the optics will be similar if not the same. Optical specs are likely to be
different due to significant differences in coding schemes and data rates.
> Given the major transfer bandwidth hit that was forced on the WAN
> compatible PHY by a block coding PCS, OAM&P functionality is one of the
> distinctions that provides customers with a clear decision point.
The first order bandwidth hit to the WAN PHY is the fault of SONET framing. The
second order hit is due to the block coding PCS. However, it is the block coding
PCS that allows the direct mapping of Ethernet to SONET at the physical layer.
The current "cell tax" of ATM is a much worse bandwidth hit than 64B/66B for
Packet over SONET.
Note that the LAN PHY doesn't seem to have any problem with the same PCS, and is
capable of supporting a full 10 Gbps data rate, transporting greater than 7%
more data than SONET. This provides customers interested in connecting their
LANs over typical MAN/WAN distances with a cost effective, straightforward and
significantly higher bandwidth transport... and a clear decision point.
> I would recommend that the group take the failure of the group to
> provide 75% support as an indication that this should be dropped and energy
> spent on other things.
To me this sounds like more of the same kind of FUD which resulted in an
abstention vote 34% higher than the opposition vote in light of a more than 63%
yes vote. Using the same logic, do you also recommend the Task Force abandon
multimode fiber cable plants?
> Thank you,
> Roy Bynum
> A customer
Best Regards,
Rich
SPCA
> At 11:20 PM 7/14/00 -0400, Brown, Ben [BAY:NHBED:DS48] wrote:
>
> >Hi,
> >
> >The LSS proposal was not initially accepted to be part
> >of draft D1.0. The opponents of this proposal felt that
> >this was too complicated a method for reporting Break
> >Link and Remote Fault. Since I've heard many times on
> >this reflector and in the meetings that, if a proposal
> >is going to be shot down a substitute should be made to
> >take its place, I'd like to request just such a substitute.
> >
> >Another thing to remember. According to Jonathan's
> >schedule, this was the "last new proposals" meeting.
> >I'll be interested to hear proposals for break link
> >and remote fault reporting that do not include major
> >new ideas.
> >
> >Thanks,
> >Ben Brown
> >P802.3ae Logic Track Chair
> >
> >--
> >-----------------------------------------
> >Benjamin Brown
> >Router Products Division
> >Nortel Networks
> >1 Bedford Farms,
> >Kilton Road
> >Bedford, NH 03110
> >603-629-3027 - Work
> >603-624-4382 - Fax
> >603-798-4115 - Home
> >bebrown@xxxxxxxxxxxxxxxxxx
> >-----------------------------------------
-------------------------------------------------------
Richard Taborek Sr. Phone: 408-845-6102
Chief Technology Officer Cell: 408-832-3957
nSerial Corporation Fax: 408-845-6114
2500-5 Augustine Dr. mailto:rtaborek@xxxxxxxxxxx
Santa Clara, CA 95054 http://www.nSerial.com