Re: Break Link and Remote Fault
[Date: 07/17/2000 From Seto]
Shawn,
I think using MAC frame means a big change to existing MAC, thus not a
good idea.
LSS is a very solid link signaling proposal. I think we should start
>from LSS. The issue is whether we should use IPG or not.
- 1000BASE-X uses Configuration order set (code set) to communicate Link
Failure, but not during IPG.
- 100BASE-FX uses special code sequence to communicate Remote Fault, but
not during IPG.
I'd like to take a straw poll how many would support LSS if it does not
mandate to use IPG. ;-)
Sincerely,
Seto
>
>
> Shawn,
>
> This is a possible replacement for the OAM&P features of
> LSS. How can we use packets to report break link and remote
> fault?
>
> Ben
>
> "Rogers, Shawn" wrote:
> >
> > I agree there was some FUD implying LSS was a form of AN, however the
> > main point I heard against LSS was it's use of Inter Packet Gap
> > (IPG). The 802.3 has resisted the use of IPG for anything, time and
> > time again. I do not see positive movement on supporting LSS as long
> > as it is done in the IPG.
> >
> > If there was a way to take LSS out of the IPG - define a special MAC
> > frame, say, it would likely gain favor.
> >
> > Shawn
> >
> > -----Original Message-----
> > From: Devendra Tripathi [mailto:tripathi@xxxxxxxxxxx]
> > Sent: Monday, July 17, 2000 11:42 AM
> > To: stds-802-3-hssg@xxxxxxxx
> > Subject: Re: Break Link and Remote Fault
> >
> > I agree with the comment. I think this is fairly simple. Moreover
this
> >
> > mechanism is so
> > easy to adopt for usage in dark fiber cases, if and when we want.
> >
> > Tripathi.
> >
> > At 11:34 PM 7/15/00 -0700, you wrote:
> >
> > >Ben,
> > >
> > >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
> > >exists..
> > >
> > >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,
> > >Rich
> > >
> > >--
> > >
> > >"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
> >
> > Best Regards,
> >
> > Devendra Tripathi
> > Vitesse Semiconductor Corporation
> > 3100 De La Cruz Boulevard
> > Santa Clara, CA 95054
> > Phone: (408) 986-4380 Ext 103
> > Fax: (408) 986-6050
> > ********************************************************************
> >
> > Web: http://www.vitesse.com
>
>
> --
> -----------------------------------------
> 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
> -----------------------------------------
>