Kick-off: Jonathan
- To: "Stds-802-3-Hssg-Distance (E-mail)" <stds-802-3-hssg-distance@xxxxxxxx>
- Subject: Kick-off: Jonathan
- From: "Jonathan Thatcher" <jonathan@xxxxxxxxxxxxx>
- Date: Wed, 16 Jun 1999 08:35:59 -0600
- Importance: Normal
- Sender: owner-stds-802-3-hssg-distance@xxxxxxxxxxxxxxxxxx
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