Re: Kick-off: Jonathan

[pbottorf@xxxxxxxxxxxxxxxxxx (Paul Bottorff)]

All:

Certainly I believe we should support the traditional Ethernet LAN space
with the exception of desktop connections. We do not have a significant
deployment of 1 GigE to the desktop. It is too early to build 10 GigE
desktop solutions. The traditional Ethernet LAN links which seem to make
sense are: server connections(100m), riser links(300-550m), and campus
backbone links(3-5Km). 

I also believe we should extend the scope of work to cover statement 2 and 3.

Statement 2 seems to cover both MAN Access and moderate distance MAN links.
For MAN access the link may connect to: 1)a SONET ring, 2)an Optical DWDM
network, 3)an Ether-switched MAN. The access links are probably not very
long, perhaps 5 Km (though I don't have installed base numbers) would cover
most of this application space. Moderate distance MAN links would be used
to build metro scale switched networks. In this environment efficient
encoding is particularly important since the system cost of the MAN will be
determined by the data rates required. Providing systems which match the
SONET transmission rates allow metro Ethernet networks to be built using a
mix of all three technologies.

Statement 3 seems to cover WAN Access. Today's WANs are long haul SONET
networks using DWDM and transmitting each wavelength at OC-192 rates, while
tomorrows long haul networks are  OC-768 per wavelenght. If the data rate
of 10 GigE matches the SONET rate then 10 GigE can be carried over todays
long haul networks allowing people to build huge Ethernet clouds. If the
data rate was matched it would be possible to use the long haul facilities
even if 8b/10b encode were used by re-encoding the data stream on entry to
the long haul facility. If the data rate is not matched then the long haul
facility will be unable to carry 10 GigE. Instead, a buffered switch will
be need to convert 10 GigE into a different data link protocol (like PoS)
before carring it over the WAN. 

Paul

At 08:35 AM 6/16/99 -0600, Jonathan Thatcher wrote:
>
>Welcome all and thank you Del for your willingness to lead this activity.
>
>During the course of the last few days, it has become obvious to me that
>there might have been a better way to handle the motion on the distance
>objective that was put forth, discussed, motioned for ammendment, discussed,
>and voted down, thereby returning us to a tabled, orginial motion. In
>retrospect, I believe that the amended motion should not have been
>considered an amendment at all, but an additional objective. Even though
>similar in word structure, each would have had a distinct, positive
>application within the standardization process.
>
>I am therefore going to recommend that this ad-hoc consider bringing forward
>an amended version of both of these motions. The later would be accepted by
>the chair for reconsideration. I believe that it will be benificial for the
>ad-hoc to consider this first and I therefore include some wording for your
>consideration as a starting point.
>
>Move that... support:
>1. The traditional Ethernet LAN space.
>2. The extended Ethernet space as both defined by 1000BASE-LX and as
>implemented in common practice, reaching  beyond the campus and into the MAN
>environment.
>3. Direct attachment to the WAN infrastructure.
>
>---------------------- comments on the above
>"motion" -------------------------------------------------------
>
>Number 1 should be a slam dunk.
>
>Number 2 is intentionally vague. In my mind, it certainly includes at least
>up to 10 km (which is the interoperable, standard PHY sold in the industry
>for LX), and might include that space which is currently being served
>non-interoperable solutions reaching to around 100 km. In any case, is
>represents single jumps of fiber (typcially dark) without any amplification,
>clock recovery, an/or regeneration.
>
>Number 3 will, I believe, be worthy of some discussion. It seems that there
>are three ways to handle the WAN.
>a. Not to handle it at all.
>b. Define attachment to the existing infrastructure (OC-48 and/or OC-192)
>c. Create an Ethernet WAN implementation (using or not using the existing
>infrastructure)
>
>I believe is that if 3c is to happen, it would be best done as a follow-on
>standards activity. The principal arguement against this is that the
>necessary hooks might not be placed in the new "10 Gig" specification to
>allow "c." to be implemented in a simple, cost effective way.
>
>jonathan
>
>
>
Paul A. Bottorff, Director Switching Architecture
Bay Architecture Laboratory
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