Re: Long distance links
Good queston.
When I was in grad school years ago in the UK the pubs closed rather early on
Sundays. Not sure if the laws have changed.//Bruce
Bruce
Rich Taborek <rtaborek@xxxxxxxxxxxxxxxx> on 09/01/99 11:06:16 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
Bruce,
This is a well proven idea. It is the same highly successful methodology
employed by
the GbE PCS/AN sub-Task Force during the development of the 802.3z standard. I
can
personally recommend some highly trained professionals to participate in this
effort
and even GUARANTEE results!
BTW, what time do the pubs close in York? This is a parameter which must be
carefully considered.
Best Regards,
Rich
--
Bruce_Tolley@xxxxxxxx wrote:
> 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