Re: Long distance links
Bruce,
I absolutely have to object to this scurrilous tactic which is clearly
intended to leave many of us beer drinking ... I mean, highly trained
professionals thoroughly disenfranchised. Some of us are NOT going to York
you know and if we were, we would have have much to imbibe on the subject.
Brian
-----Original Message-----
From: Bruce_Tolley@xxxxxxxx <Bruce_Tolley@xxxxxxxx>
To: rtaborek@xxxxxxxxxxxxxxxx <rtaborek@xxxxxxxxxxxxxxxx>
Cc: HSSG <stds-802-3-hssg@xxxxxxxx>
Date: Wednesday, September 01, 1999 12:01 PM
Subject: Re: Long distance links
>
>
>
>Rich:
>
>How about this, we appoint David Law to select a pub and on Sunday night,
the
>speed ad hoc convenes in the pub and cannot leave until it reaches 100%
>consensus on a proposal to present to the HSSG.
>
>Bruce
>
>
>
>
>Rich Taborek <rtaborek@xxxxxxxxxxxxxxxx> on 08/31/99 03:36:04 PM
>
>Please respond to rtaborek@xxxxxxxxxxxxxxxx
>
>Sent by: Rich Taborek <rtaborek@xxxxxxxxxxxxxxxx>
>
>
>To: HSSG <stds-802-3-hssg@xxxxxxxx>
>cc: (Bruce Tolley/HQ/3Com)
>Subject: Re: Long distance links
>
>
>
>
>
>Bruce,
>
>I can't possibly agree with your last statement (about the beer consumption
:-),
>but
>I agree with everything else you say.
>
>I'm perfectly happy to consider any HSSG objectives which have Ethernet
moving
>into
>the WAN. I'm also perfectly happy to be educated about WAN requirements and
>exactly
>how WAN access methods like SONET/SDH meet these requirements.
>
>I'm in vehement opposition of any HSSG objectives which has to do with
mapping
>Ethernet to SONET. Such an effort does not belong in 802.
>
>Note that I don't have any problem whatsoever with the coexistence of
Ethernet
>and
>SONET equipment, even in the same box (e.g. router). However, there is no
need
>for
>any 802.3 activity to define such coexistence at 10 GbE Ethernet rates.
Once the
>10
>GbE standard is set, many efficient implementations which route 10 GbE to
SONET
>will
>spring up.
>
>I've interspersed a few more comments below.
>
>Best Regards,
>Rich
>
>--
>
>Bruce_Tolley@xxxxxxxx wrote:
>
>> Rich:
>>
>> I must both agree and disagree with you.
>>
>> My own personal leaning is towards the traditional Ethernet approach but
the
>> HSSG has not really finished defining its goals and no goal decided upon
to
>> date excludes Paul's proposal.
>
>Paul's proposal specifically excludes most 10 GbE PHY proposals by
requiring
>specific encoding and delimiter usage to the point of requiring that the
>Ethernet
>PHY = SONET OC-192 PHY. I don't believe that this is in the best interest
of
>802.3.
>
>If the objectives are as loose as you interpret them, then why the heck did
we
>waste
>20 hours of committee time nit picking the HSSG distance objectives???
>
>> >From the very first call for interest there has been discussion of
taking
>> Ethernet into the WAN.
>>
>> What has been lacking in the debate is a short concise definition of the
>> requirements for Ethernet into the WAN. We might well decide to exclude
>support
>> for SONET for a host of good reasons, but no such decision has yet been
made.
>>
>> We might set for ourselves the goal that not one pint of Yorkshire beer
will
>be
>> consumed by any member HSSG until we settle the speed issue!! :-))
>>
>> Bruce Tolley
>> Manager, Business Development
>> 3Com Corporation
>>
>> Rich Taborek <rtaborek@xxxxxxxxxxxxxxxx> on 08/31/99 11:04:39 AM
>>
>> Please respond to rtaborek@xxxxxxxxxxxxxxxx
>>
>> Sent by: Rich Taborek <rtaborek@xxxxxxxxxxxxxxxx>
>>
>> To: HSSG <stds-802-3-hssg@xxxxxxxx>
>> cc: (Bruce Tolley/HQ/3Com)
>> Subject: Re: Long distance links
>>
>> Jonathan,
>>
>> I agree that Paul's statement is concise, but please bear in mind that it
has
>> NOTHING to do with HSSG work as far as I can tell. I'm not sure if this
was
>> Paul's intention in his note containing this original text. There are no
HSSG
>> objectives that even remotely address the issue of "carrying Ethernet
frames
>on
>> a SONET system". The closest one is an objective to choose one of two
MAC/PLS
>> data rates: 10 or 9.584640 Gbps.
>>
>> I would strongly encourage all proponents of Ethernet over SONET to
either
>> propose new HSSG objectives addressing these issues, put forth a Call for
>> Interest on this issue, or find another forum.
>>
>> Personally, I don't see any benefit to Ethernet by meeting ANY of Paul's
>> requirements and I DO see clear disadvantages with meeting ANY of them.
SONET
>> transports Ethernet frames just fine today. SONET will be able to
transport 10
>> GbE frames just fine in the future. Forcing SONET/WAN architectures upon
>> Ethernet is not cost effective for either the WAN or LAN environment.
>>
>> Best Regards,
>> Rich
>>
>> --
>>
>> Jonathan Thatcher wrote:
>>
>> > Paul. Thank you!
>> >
>> > Your words (copied from below) represent the simplest, most concise
(perhaps
>> > the ONLY concise) set of requirements I remember seeing to date
regarding
>> > this topic.
>> >
>> > I would strongly encourage all proponents of Ethernet over SONET to set
>> > aside the diatribe and modify, expand upon, or otherwise improve upon
this
>> > list.
>> >
>> > -------------- from Paul --------------------------
>> > To carry Ethernet frames on a SONET system:
>> >
>> > 1)Ethernet must match the payload rate of 9.584640 Gbps
>> > 2)Ethernet frames must be encoded with NRZ efficiency
>> > 3)Ethernet frame delimiting must operate without special symbols
>> > ------------ end from Paul ------------------------
>> >
>> > jonathan
>> >
>> > > -----Original Message-----
>> > > From: pbottorf@xxxxxxxxxxxxxxxxxx
[mailto:pbottorf@xxxxxxxxxxxxxxxxxx]
>> > > Sent: Monday, August 30, 1999 4:36 PM
>> > > To: Rohit Mittal; rtaborek@xxxxxxxxxxxxxxxx
>> > > Cc: HSSG
>> > > Subject: Re: Long distance links
>> > >
>> > >
>> > >
>> > > Rohit:
>> > >
>> > > At 01:17 PM 8/30/99 -0700, Rohit Mittal wrote:
>> > > >
>> > > >Rich et al,
>> > > >
>> > > >One of the things you need to consider is that SONET has
>> > > extensive error
>> > > monitoring
>> > > >"built-in" the overhead to allow speedy detection of
>> > > failures before they
>> > > degrade
>> > > >to serious levels. SONET provides rapid fault isolation.
>> > > >
>> > > >Now, if you use TCP/IP for the same tasks, you are going to
>> > > add latency etc.
>> > > >because the frame/data will have to pass through many layers
>> > > before any
>> > > fault is
>> > > >detected. That is the problem in moving up the protocol stack.
>> > > >
>> > > >For instance, SONET allows less than 50ms time for signal
>> > > restoration (due
>> > > to cut
>> > > >fiber etc.). I do not see anything in Ethernet which can provide
>> > > equivalent support
>> > > >- maybe Far end fault detector but doesn't that takes a long
>> > > time to detect?
>> > > >
>> > > >IMO, the best solution is just to encapsulate ethernet
>> > > frames as data bits
>> > > in a
>> > > >SONET frame. That way SONET can provide the management features for
>> > > preventing
>> > > >expensive mantainence and Ethernet can travel as is. Am I
overlooking
>> > > something?
>> > >
>> > > To carry Ethernet frames on a SONET system:
>> > >
>> > > 1)Ethernet must match the payload rate of 9.584640 Gbps
>> > > 2)Ethernet frames must be encoded with NRZ efficiency
>> > > 3)Ethernet frame delimiting must operate without special symbols
>> > >
>> > > >
>> > > >Rohit Mittal
>> > > >Engineering, Microlinear Corp.
>> > > >
>> > > >> Mark,
>> > > >>
>> > > >> I believe you're on the right track insofar as digging to
>> > > the root of the
>> > > >> management issue. The fact of the matter is that Ethernet
>> > > does it one
>> > > way, and
>> > > >> SONET does it another. My sense is the same as yours:
>> > > "...instead of
>> > > >> transporting management info on dedicated
>> > > >> circuits, use TCP/IP and packets. It's the histroric
>> > > trend, moving up the
>> > > >> protocol stack."
>> > > >>
>> > > >> I have asked numerous questions over this reflector trying
>> > > to get at the
>> > > core of
>> > > >> requirements for WAN management. I've seen no responses to those
>> > > questions. BTW,
>> > > >> I'm sill very much interested in hearing the responses to
>> > > these questions.
>> > > >>
>> > > >> Without knowing the requirements for SONET WAN management,
>> > > I have to
>> > > believe
>> > > >> that Ethernet Management, ULP (e.g. Ping, SNMP, Browser)
management
>> > > mechanisms,
>> > > >> Etherenet PHY capabilities for determining things like the
>> > > BER of each
>> > > link,
>> > > >> represent sufficient architecture to implement WAN
>> > > management equivalent or
>> > > >> superior to that of SONET.
>> > > >>
>> > > >> Best Regards,
>> > > >> Rich
>> > > >>
>> > > >> --
>> > > >>
>> > > >> "Gerhold, Mark" wrote:
>> > > >>
>> > > >> > All,
>> > > >> >
>> > > >> > It sounds as if one of the biggest issues here is with
>> > > the optical
>> > > >> > repeaters. If I understand correctly, Sonet repeaters are
>> > > instrumented so
>> > > >> > that the administrator can isolate problems without
>> > > sending out a truck.
>> > > >> >
>> > > >> > Consider using a 2-port "LAN" switch instead of a
>> > > repeater. Switches
>> > > today
>> > > >> > provide lots of remote maintenance features, including
>> > > >> >
>> > > >> > o Ping (for I'm alive)
>> > > >> > o SNMP (for tons of performance statistics, and alarms)
>> > > >> > o Browser management (for ease of use)
>> > > >> >
>> > > >> > With a switch, instead of transporting management info
>> > > on dedicated
>> > > >> > circuits, use TCP/IP and packets. It's the histroric
>> > > trend, moving up
>> > > the
>> > > >> > protocol stack.
>> > > >> >
>> > > >> > Here's a question on a similar vein. Are WDM amplifiers
>> > > instrumented to
>> > > >> > isolate BER problems? I thought they did optical amplification.
>> > > Capturing
>> > > >> > BER info sounds tough.
>> > > >> >
>> > > >> > Thanks,(signing off)
>> > > >> >
>> > > >> > Mark Gerhold
>> > > >> > Unisys
>> > > >> >
>> > > >> >
>> > > >
>> > > >
>> > > >
>> > > Paul A. Bottorff, Director Switching Architecture
>> > > Enterprise Solutions Technology Center
>> > > Nortel Networks, Inc.
>> > > 4401 Great America Parkway
>> > > Santa Clara, CA 95052-8185
>> > > Tel: 408 495 3365 Fax: 408 495 1299 ESN: 265 3365
>> > > email: pbottorf@xxxxxxxxxxxxxxxxxx
>>
>> -------------------------------------------------------------
>> Richard Taborek Sr. Tel: 650 210 8800 x101 or 408 370 9233
>> Principal Architect Fax: 650 940 1898 or 408 374 3645
>> Transcendata, Inc. Email: rtaborek@xxxxxxxxxxxxxxxx
>> 1029 Corporation Way http://www.transcendata.com
>> Palo Alto, CA 94303-4305 Alt email: rtaborek@xxxxxxxxxxxxx
>
>-------------------------------------------------------------
>Richard Taborek Sr. Tel: 650 210 8800 x101 or 408 370 9233
>Principal Architect Fax: 650 940 1898 or 408 374 3645
>Transcendata, Inc. Email: rtaborek@xxxxxxxxxxxxxxxx
>1029 Corporation Way http://www.transcendata.com
>Palo Alto, CA 94303-4305 Alt email: rtaborek@xxxxxxxxxxxxx
>
>
>
>
>
>
>