Re: RESPONSE TO Re: SUPI<>XAUI
Pat,
Thanks for taking the time to put together your response. Please see my
comments below:
pat_thaler@xxxxxxxxxxx wrote:
>
> 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.
The motion was to create an ad hoc. The output of the ad hoc would be a
parallel draft. Specifically, it would be a modified version of Clause
48 which would support the 10GBASE-LW4 as well as the 10GBASE-LX4. My
opinion is that no motion should have been associated with the formation
of the ad hoc and that a future motion would apply to the parallel
draft. Can you honestly suggest a more expedient manner in which to
address this issue than a parallel Clause 48?
I will abide by the Tampa decisions regarding this issue. I do not agree
with the decisions. I'm sorry, I can't in all good conscience find a way
to do that.
> 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.
My proposals stand on their technical merit, not my opinions. I've
addressed your technical concerns below.
> 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.
Once again, the motion was not necessary (in my opinion). All that was
required was the creation of an ad hoc to further study the issue.
> 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.
The proposal in taborek_3_1100.pdf is, in my opinion, more complete than
is Clause 53. Please take a good look at Clause 53. We have now gone
through two drafts and there appears to be no more information in Clause
53 than there was in the baseline proposal from whence it came
(bottorff_1_0700.pdf). There are no state diagrams in Clause 53, no
state variables, etc. Clause 53 is very incomplete. Clause 48, in
conjunction with the proposal material in taborek_3_1100.pdf is
significantly more complete than is Clause 53. We need to step back and
take a look at the big picture before developing single and special
purpose interfaces with which we are going to have to live for a long,
long time.
Please note that we'll likely be making a few technical changes of
significantly greater magnitude than the one we're discussing here as we
go forward as the result of draft comments. Please don't confuse the
issue with a "parallel draft" defense. All I asked for is the ability to
further develop the proposal via the creation of an ad hoc.
> 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.
I could have had a complete PCS and PMA for 10GBASE-LW4 ready for D2.0
in the form of an IEEE P802.3ae clause by this coming Wednesday. Could
you possibly suggest a better way to provide a real and complete
solution for 10GBASE-LW4?
> 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.
Neither the XSBI nor any "gearbox" nor any other 16-bit interface is
relevant to any sublayers or interfaces between the WIS and SUPI. I am
not sure why you even mention the presence of the XSBI with respect to
the 10GBASE-LW4 PHY. There is no mention of XSBI in Clause 53. The XSBI
is a specific and optional physical instantiation of the Serial PMA for
use with Serial PHYs. SUPI stripes 16-bits of data on each lane. This
16-bit striping does not require the XSBI. Lets not mix architecture
with implementation.
SUPI is a physical and electrical interface much like XAUI. XAUI relies
on the PCS and PMA defined in Clause 48. Likewise, SUPI requires a PCS
and PMA which are to be defined in Clause 53. In the SUPI baseline
proposal in bottorff_1_0700.pdf, the SUPI PCS and PMA was referred to as
an "SS" sublayer. Among other things, the SS is responsible for data
striping across lanes, lane synchronization, lane-to-lane deskew, link
fault processes, etc. Slide 5 of taborek_3_1100.pdf comes directly from
slide 4 of the SUPI baseline proposal in bottorff_1_0700.pdf, I didn't
make it up.
> 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.
We all know that the XGXS acts as a PCS and PMA agent. That's how it was
initially proposed for use with 4-channel PMDs. You can simply redraw
slide 9 of taborek_3_1100.pdf with a PCS3 and PMA sublayer based on the
8b/10b PCS and its associated PMA instead of XAUI and its associated
PCS. For presentation purposes, I decided to show XAUI/XGXS as replacing
SUPI/SS. Bottom line is that the proposal in taborek_3_1100.pdf is
equivalent in the number of sublayers and interfaces as is Clause 53.
There are no additional "2 sublayers" and there is no requirement for
additional XGXS device identifiers.
Please note that there would be additional SS device identifiers in a
SUPI based implementation which is attached to the system side with an
XSBI.
> 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.
Lets compare apples to apples to figure out exactly what the clocking
requirements are. Apple #1 is SUPI/SS and Apple #2 is XGXS/XAUI. Any
comparison to the XGXS/XAUI associated with the XGMII is altogether
irrelevant. Let's consider four clocks, two in each direction and two on
each side of the SUPI/XAUI interfaces. Let's call the directions
outbound (towards the medium) and inbound (towards the system).
Furthermore, let's call the sides of the SUPI/XAUI interface Tx and Rx.
Now, for the four clocks:
1) Outbound Tx: This one comes from the local clock, probably the same
one used by the WIS. No problem here, right?
2) Outbound Rx: This clock must be recovered from the SUPI/XAUI data
stream. There is no possibility of performing clock rate compensation
because of the WIS/SONET framing, not because of SUPI or XAUI. True, I
can't use the ||R|| capability in XAUI. However, no such capability is
available in SUPI. We're still even, right?
3) Inbound TX: This clock must be recovered from the PMD data stream.
Once again, there is no possibility of performing clock rate
compensation because of the WIS/SONET framing. Still even, right?
4) Inbound RX: This clock must be recovered from the SUPI/XAUI data
stream. Again, there is no possibility of performing clock rate
compensation because of the WIS/SONET framing. Final result: clocking is
exactly the same for XAUI/SUPI. Since the clocking is the same, so is
the implication on jitter specs.
Please note that this example shows the advantage of LAN vs. WAN PHY in
terms of the ability to perform clock rate compensation.
> 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.
Since this issue is XAUI vs. SUPI and both are 4-lane 16-signal
interfaces with the same electrical specification (see Clause 47), I
don't see what relevance the XSBI or a transceiver module interface
supporting the XSBI has to do with this issue. Note also that XAUI, not
the XSBI, seems to be the leading interface for strategic Transceiver
Module MSA efforts for 10G WWDM, Serial and Parallel Optic applications.
This includes all 10GE LAN and WWDM WAN applications.
> 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.
Once again, the XSBI is a specific physical instantiation for the Serial
PMA. If you want to put XSBI interfaces on your WIS chips, more power to
you, but please don't introduce the XSBI as any kind of requirement for
the 10GBASE-LW4 PHY. However, if you want to talk implementation: I'm
just going to put the WIS into a version of my XGMII-to-XAUI chips, the
darn thing is empty anyway :-)
> 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.
A broken SUPI has no way to inject Link Fault messages at either end of
the SUPI link. XAUI does. I have clearly described the "need" in
taborek_2_1100.pdf
> 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.
I believe that your proposal is exactly the same as mine except that it
requires the XSBI. It should be clear that there is no architectural
requirement for the XSBI in a 10GBASE-LW4 PHY. I view the proposal in
taborek_3_1100.pdf as the required proper subset of your alternate
proposal.
> 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.
I'm sorry used "XGXS" in my proposal and understand some of the
confusion it caused. I made it clear to the Task Force during the
presentations that the changes required to support the 10GBASE-LW4 would
be limited to Clause 48.
> Regards,
> Pat
As I said in a previous note on this issue, I'm not interested in
pursuing this matter further since I see no business case for the
10GBASE-LW4 PHY. This includes the potential submission of a TR comment
(by me) against Clause 53 with a suggested remedy being a version of
Clause 48 which includes support for the 10GBASE-LW4 PMD. If anyone else
wants to take up this cause, I'd be happy to help out. Please contact me
directly if you're interested in leading the charge.
Best Regards,
Rich
--
> -----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
-------------------------------------------------------
Richard Taborek Sr. Phone: 408-845-6102
Chief Technology Officer Cell: 408-832-3957
nSerial Corporation Fax: 408-845-6114
2500-5 Augustine Dr. mailto:rtaborek@xxxxxxxxxxx
Santa Clara, CA 95054 http://www.nSerial.com