RE: what's next ?
Jim,
See below
>-----Original Message-----
>From: JTatum@xxxxxxxxxxxxxxxxxxx [mailto:JTatum@xxxxxxxxxxxxxxxxxxx]
>Sent: Tuesday, July 18, 2000 5:51 AM
>To: Jonathan.Thatcher@xxxxxxxxxxxxxxxxxxxx; dan_dove@xxxxxx;
>stds-802-3-hssg@xxxxxxxx
>Subject: RE: what's next ?
>
>
>
>Jonathan,
>
>I would assume that 802.3ae would do the same as 802.3z, and
>NOT specify conectors.
I moved this to a different thread...
>The models that we work from are
>sufficient to determine the optical tables, since most of
>that work was done in 802.3z, and I would not anticipate new
>optical test procedures, though there might be some
>associated with launch condition. That work is nearing
>completion.
OK, I'll admit that I am still "DMD shy (that was not a fun part of my
life)."
At this same point in 802.3z, we had not anticipated any new test procedures
than those adopted and referenced in FC. I would guess that if we had been
asked, we would have claimed the probability to be unlikely.
I expect that as we focus on the details (especially in implementations
outside the committee), we will find places where product can be made more
cost effective if we relax/change the way we specify/test/measure. The fact
that it hasn't happened yet leads me to speculate that the industry hasn't
yet gotten to the phase that will expose these issues (yet).
If this doesn't happen, great.
>As far as the jitter goes, that one may require
>some additional work, but I think it any MMF solution (I
>assume that this is a must have for 802.3ae... as dictated
>by the PAR) would require some amount of work.
Agreed. So, how do we pose the questions/issues/actions and manage this
activity? This might also be done best in another thread....
We have set ourselves up with a couple of advantages with respect to jitter.
In the overall architecture, we have an assumption that there will be no
exposed interface such as TP1 and TP4 in 802.3z. This means that we only
need to specify TP2 and TP3 (which I would recommend we call TPT and TPR or
TPA and TPB for 802.3ae to eliminate potential confusion).
>
> -Jim
>
>__________________________Honeywell
>
>Jim Tatum
>(972) 470-4572
>http://www.honeywell.com/sensing/vcsel
>
> -----Original Message-----
>From: Jonathan Thatcher
>Sent: Monday, July 17, 2000 7:13 PM
>To: 'DOVE,DANIEL J HP-Roseville,ex1; stds-802-3-hssg
>Subject: RE: what's next ?
>
>
>Dan,
>
>If we are successful in adding the necessary PMD(s) to the
>baseline proposal
>during the September Interim Meeting, I see no reason why this
>detour should
>cause any modification in the overall schedule.
>
>Structurally, adding a Serial PMD will end up as a "column
>addition" to the
>Serial PMD clause (yes, I know, like with clause 38, we might
>actually have
>new tables). This level of change should be pretty
>transparent. Especially
>since we already know the specifications for the tables. Right?
>
>For non-serial, PMD proposals, it would certainly help if any September
>presentation came equipped with a "Draft 1.0 equivalent."
>
>I am more concerned with a few details that we haven't gotten to yet:
>1. What is the connector on the media going to be? SC/LC/MT/Other?
>2. What new optical test methods are required?
>3. Can we lock down the jitter specifications and measurement
>(XAUI, SUPI,
>TP2/TP3)?
>etc.
>
>jonathan
>>-----Original Message-----
>>From: DOVE,DANIEL J (HP-Roseville,ex1) [mailto:dan_dove@xxxxxx]
>>Sent: Monday, July 17, 2000 3:21 PM
>>To: 'Jonathan Thatcher'; stds-802-3-hssg@xxxxxxxx
>>Subject: RE: what's next ?
>>
>>
>>Hi Jonathan,
>>
>>I would appreciate it if you would clarify something for me.
>>
>>Since only the 1550 and 1300nm serial PMDs made it forward
>>at this last meeting, does that imply that a multimode or
>>WDM PMD will by necessity be forced to assume a later schedule?
>>
>>Can we expect to have a low-cost/short-haul PMD solution on
>>the original time frame?
>>
>>If so, I may have mis-interpreted the situation in La Jolla and
>>will be glad that my comments did not result in a negative vote
>>for moving the two PMDs forward.
>>
>>Regards,
>>
>>Dan Dove
>>HP ProCurve Networks
>>
>