Re: Kick-off: Jonathan

[Rich Taborek <rtaborek@xxxxxxxxxxxxxxxx>]

Jonathan,

What was the original motion? Are minutes of the Coeur d'Alene meeting available
yet?

Other comments interspersed below.

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.

I don't believe we need this one. Instead we'd have to make a motion to withdraw
support for the LAN. In addition, by not proposing such a motion, I believe that
we implicitly endorse CX-copper jumper distances along with all other
traditional 1000BASE-X and  T distances.

> 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.

The 1000BASE-LX part isn't required for the same reason, the distances LX
supports are legacy (500 to several km) per 1000BASE-X. I agree with the "beyond
the campus and into the MAN environment". However, it is very weak since I can
interpret "beyond the campus" and "into the MAN" as "slightly farther than LX".
One can in turn interpret the distance objective buried therein to be "no more
than 5 km". I believe that wording is too vague. I'm guessing that your
intention with (2) is an "EX-style" distance in the neighborhood of 10-15 km.

> 3. Direct attachment to the WAN infrastructure.

This one is clearer since it's shorter, but I believe that it's fully covered by
legacy objectives and the addition of the EX distance objective per my comment
above. However, "attachment to the WAN" can simply denote short links which
allow the attachment of 10 GbE to the existing WAN infrastructure. I believe
that (CX, SX, LX and EX (and possibly T) would cover all cases of "direct
attachment to the WAN infrastructure".

The objectives that are still missing, and will be brought up by more than one
individual are:

- Support of the MAN infrastructure; and
- Support of the WAN infrastructure

The sooner we address these two non-legacy objectives, and if accepted, figure
out how to handle their specifications (e.g. separate project, etc.) the quicker
we'll be done with this issue.

>
> ---------------------- 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

Your interpretation of your proposed words are quite different than my
interpretation. However, the objectives and how they are handled are the same.
Therefore, for clarity and expediency, I propose the following motions instead:

Move that... add support for:
1) The MAN infrastructure
2) The WAN infrastructure

--

Best Regards,
Rich

-------------------------------------------------------------
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