Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: Break Link and Remote Fault


Thanks for taking this direction, I believe it's the right one. The LSS proposal
did very well at the La Jolla meeting in spite of the FUD (Fear, Uncertainty and
Doubt) use to confuse as significant number of members of the P802.3ae
committee. This is clearly evident in the voting results on the LSS proposal:
Yes: 55, No: 32, Abstain: 43. The voting results show that 63.2% of 802.3 voters
are in favor of the proposal and 33% of all voters abstaining. Also noteworthy
is that the highest abstention percentage for any other Logic track motion was
on the SUPI vote, for which 21.2% of all voters abstained.

Among the FUD that targeted the LSS proposal was the comparison to
Auto-Negotiation. This can't be farther from the truth. Auto-Negotiation is a
handshake protocol including timeouts, acknowledgments, and multiple possible
responses to any request. LSS employs no handshakes whatsoever and employs
simple and continuous side A to side B signaling while a particular condition

Another FUD element was the argument stating that there is no P802.3ae objective
for either Remote Fault or Break Link. I'd like to point out that there is
little correspondence between objectives and actual functions and features. For
example, there is no objective to perform link initialization, but clearly this
is a necessary function. I assume that there is a desire to include Break Link
and Remote Fault functionality in P802.3ae, objective or not.

LSS employs simple word oriented signaling at the Physical layer and may be
transported by all LAN interfaces. In addition to Break Link and Remote Fault,
LSS possesses the flexibility to be used to transport LAN OAM&P information. It
just doesn't get much simpler than this. I strongly encourage any
simplifications to LSS protocol.

Best Regards,

"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