RE: RESPONSE TO Re: SUPI<>XAUI
Rich,
First off, a motion to create an ad hoc to study something may be
procedural, but a motion authorizing creation of a draft is technical. Since
the motion in question was to create a parallel draft, Geoff was entirely
correct to consider it a technical motion.
Secondly, I want to give my view of what happened between the task force
vote on Wednesday and the 802.3 vote on Thursday. You characterized it
negatively as "politicking." I do not feel that is accurate and it certainly
is not a view that will move us toward resolving concerns about your
proposal.
The task force saw your proposal on Wednesday afternoon and, with the press
of many other matters to deal with, had very limited time to debate and vote
on the related motion. Certainly, the prospect of a change that makes PMD
operation virtually the same for 10GBASE-LX4 and 10GBASE-LW4 is attractive
to many of us. In our enthusiasm, many of us voted to go ahead with creating
a parallel draft despite some concerns about the proposal.
After sleeping on it, I had a number of concerns about what we had approved.
1) Completeness of proposal - The presentation really left a lot off details
to work out. It is significantly less complete than any of the proposals we
adopted in July. In New Orleans we voted hastily on some much more minor
matters without enough details worked out. Even the Link Fault proposal has
created some difficulty and it was significantly more complete. We need to
exercise the self-discipline of having complete proposals before we agree to
change drafts or create parallel drafts.
2) Timing and impact on the draft - The editors have a week and a half to
put the updates from Tampa into the draft so it can go out to task force
review. The discussion of the parallel draft said that it was to go out with
the draft for review. A number of the people who would be involved in
developing the parallel draft are also clause editors. I felt that trying to
create the parallel draft in the same time period would adversely affect the
quality of 2.0.
3) Approach of the proposal - While I'm supportive of the goal of making LX4
and LW4 look the same to the PMD, there are aspects of the particular
proposal that will make it very difficult to integrate into the draft and
into implementations. I believe there is another approach that would
accomplish the goal more effectively. Here are the problems:
a) Too many sublayers. The drawings on slides 5 through 8 of your
presentation make it look like your proposals have the same or fewer
sublayers than 10GBASE-LW4. However, they misrepresent the LW4 architecture.
"SUPI" is a misnomer. There is no SUPI interface and there are no "SS"
sublayers. The 10GBASE-LW4 PMA does the conversion between XSBI and the WWDM
PMA that was originally presented as SUPI. The correct representation of the
status quo for page 5 would show the XSBI going directly into a 10GBASE-LW4
PMA.
The proposal presented adds 2 sublayers to the existing 802.3ae 7-sublayer
physical layer stack. A seven sublayer phy is enough. For instance, we would
have to add additional XGXS device identifiers to MDIO.
b) While the proposal calls the new sublayers XGXS, they are different from
XGXS in a number of ways. To differentiate, I will call the new sublayers
XGXS'. XGXS can use a local clock to transmit the received data. Since these
XGXS' cannot add or delete idles, they must use the recovered clock to send
the received data. The upper XGXS' attaches to the 16 bit service interface
of the WIS while a normal XGXS attaches to XGMII. On transmit, the upper
XGXS' has to look for A1/A2 sequences to get frame lock and replace them
with AKR. The existing XGXS doesn't do such a task. By the time we are done,
we have just moved the problem of having two sublayers defined in one clause
that may require separate implementations from the PMD to the XGXS. The
change in clocking requirements is non-trivial for implementation and for
jitter specs.
c) A likely implementation of a 10GBASE-W interface is a board with an XSBI
interface to a transceiver module. With the current spec such an
implementation can support both serial PMA/PMD and LW4 PMA/PMD modules. With
your proposal, the interface is likely to be XAUI for LW4 while it remains
XSBI for serial. Thus it becomes difficult to support both with one
interface plus a plug-in module.
d) To support implementation, we will either need to have WIS chips with
XAUI interfaces in addition to WIS chips with XSBI interfaces or we will
need to have XGXS chips with XSBI interfaces in place of XGMII interfaces.
Once again, we are moving the problem of having extra components from the
one place to another but not solving it.
d) We already have adequate means of fault signaling for WIS frames and in
the WIS frame payload. There is no need to add yet another mode of fault
signalling for an 8B/10B encoded WIS.
The alternate proposal:
Define an LW4 PMA with an upper service interface of XSBI and a lower
service interface that attaches to the WWDM PMD. Like the current LW4 PMA,
on transmit this PMA would look for A1/A2 sequences to get frame lock.
Unlike the current PMA, it would replace those sequences with AKR and would
send the rest of the frame as 8B/10B coded data. On receive, it would use
the K's and A's to get alignment and deskew the lanes. It would replace the
AKR with A1/A2.
This proposal is a much more modest change to the spec. It would mean one
sublayer, the PMA, was unique to 10GBASE-LW4 which is the minimum. In the
existing spec the PMA and PMD are unique to LW4. In your proposal, The upper
and lower XGXS' sublayers are unique to LW4 and are different from each
other. It keeps a consistant interface between WIS and PMAs.
Regards,
Pat
-----Original Message-----
From: Grow, Bob [mailto:bob.grow@xxxxxxxxx]
Rich:
... stuff deleted ...
"TECHNICAL MOTION:
Move that IEEE 802.3 affirm the motion approved by P802.3ae Task Force
regarding parallel Clause 53 replacement.
M: Mr. Brown
S: Mr. Booth
Y: 56, N: 36, A: 45,
"The motion "Move that the P802.3ae Task Fore authorize an ad hoc to develop
a parallel draft targeted to replace SUPI/SS with an 8b/10b based signaling
method as proposed in taborek_3_1100.pdf. Final decision to be made at the
March Plenary." was displayed for discussion. The objection was that there
was no notice of this coming up at the meeting, and that it hadn't received
sufficient consideration. Mr. Thatcher expressed the opinion that the
presentation had been made in conformance with his rules and that others
could have created alternate proposals had they thought of it. Concern was
expressed by the process planned for this (specifically distributing the
proposed changes with the draft). The indication of a date for final
decision was also questioned."
-----Original Message-----
From: Geoff Thompson [mailto:gthompso@xxxxxxxxxxxxxxxxxx]
Rich-
Please see my comments mixed in and at the end of only the front portion of
your previous message.
At 11:58 AM 11/12/00 -0800, Rich Taborek wrote:
>Ladies and Gentlemen,
>
>Time to vent a little frustration over the events surrounding this issue
>at the Tampa meeting. ...
I understand your frustration, however, we live in country full of people
who are frustrated at the moment.
I think you mis-state the case as I will detail below.
>1) Perogative taken by the 802.3 chair to deem a motion to affirm a
>motion by the P802.3ae Task Force to form an ad hoc to further develop
>the proposal a technical, rather than procedural issue, thereby
>requiring approval of 75% of 802.3 voters. The resultant vote did not
>acquire the 75% needed to form the ad hoc. It should be noted that the
>P802.3ae Task Force approved a motion to form the ad hoc by more than
>75%. I fully understand that the reason given by the chair to decide
>that the motion was technical was that the further development of the
>proposal involved technical changes in a parallel clause. However, since
>no technical change was implied or imminent in the motion in question, I
>strongly disagree with the decision to call the motion technical instead
>of procedural.
This does not match my recollection. My objection was not to forming an Ad
Hoc. I am highly open to forming Ad Hocs as long as they have business that
supports the project. The objection was, rather, that the output of the Ad
Hoc was to be included with the draft for consideration as an alternative
proposal. Inclusion of material in a draft is and always has been a
technical decision.
>It now appears that the 75% criteria applies to most
>procedural 802.3 motions as well as technical ones.
>
>2) Reviewing the process of Task Force ad hoc formation, it appears that
>it is the chair's perogative to form an ad hoc and that approval by
>802.3 voters of 75% or even 50% is not required. It appears that an ad
>hoc with significantly greater technical implications to P802.3ae, the
>Equalization ad hoc, was approved in New Orleans with no motion in the
>Task Force or elsewhere as far as I can tell from my recollection and
>formal minutes of that meeting.
I was consulted on the formation of the Equalization Ad Hoc. I said that it
could live only as long as its output could be construed as being useful to
802.3ae. There was nothing in its formation that indicated that the group's
output would be anything other than material reported to the Task Force in
session. I understood that there was a distinct possibility that their
output would be too late to catch the draft. I told Jonathan that, at that
point, they would have to justify their existence to 802.3 as a standalone
group.
The 802.3ae group has a major task to narrow in on the final text. They
have a process for doing so. If there is need to repair a defect then it is
appropriate to open the draft back up. If there is not a defect then the
process should be one of ongoing convergence. Opening the process and the
draft up to large amounts of new text from alternate proposals is not
conducive to this process.
Sincerely,
Geoff