| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Brad, What I meant was that by proposing rejection of your comment it forces further debate and justification. As there is a danger of ‘proposed accepts’ being rubber stamped by the ballot resolution committee without any further discussion I feel uncomfortable proposing acceptance of a comment which deletes a long-standing feature of the draft that I know has support;
Arthur
From: Brad
Booth [mailto:bbooth@xxxxxxxx]
One clarification here that is causing concern. While certain aspects of this draft may have been reviewed by the task force for quite some time, in my humble opinion, it is inappropriate to reject a comment because it “has been in the draft for a long time.” For many in the working group, this is their first opportunity to review the draft standard, and while their views and opinions may not be the same as those in the task force, rejecting their comment because it’s been in the draft for 6 months is not the message to be sent.
That being said, some response to the points below (and thanks to John for the clarification on Style-1 and Style-2). I did not state that 10GBASE-CX4 and 40GBASE-CR4 were not compatible at the MDI, only that they use different connectors. John’s clarification that Style-2 is the same connector as that use in CX4 now causes me greater concern. I was under the impression that after the connector wars in 802.3z days there was the unwritten rule that only one style of connector per port/medium type.
If the intention of the task force is to provide backwards compatibility between 40GBASE-CR4 and 10GBASE-CX4, then the Style-2 connector should be the only one required for 40GBASE-CR4 in the draft standard. This would support the reasoning behind having the indication of 10GBASE-CX4 parallel detect.
If the task force wants to use the Style-1 connector because it has preferred properties compared to the Style-2 connector, then which connector will be used by equipment vendors for 40GBASE-CR4? If the goal of all the equipment providers is to use Style-1 and enable lower speeds via 10G over a single lane (10GBASE-CR?), then the Style-2 connector and its backwards compatibility are not required.
Thanks, Brad
From: Arthur Marris [mailto:arthurm@xxxxxxxxxxx]
Brad, Hugh, I hope you do not mind me taking this discussion to the reflector but I think it would be useful to have some input from the wider group.
Brad, I sympathize with your view point but what you suggest is a significant change to what has been in the draft for a long time so I think it is appropriate for the proposed response to be ‘reject’ and then discuss this in the task force meeting.
To summarize I believe the two sides of the argument are:
Delete mention of 10GBASE-CX4 parallel detect because: 1) It is out of scope 2) 10GBASE-CX4 and 40GBASE-CR4 are not compatible at the MDI
Keep 10GBASE-CX4 parallel detect in 802.3ba because: 1) It is nice to have 2) If you ever did succeed in connecting 10GBASE-CX4 and 40GBASE-CR4 the AN block might indicate 10BASE-KX4 parallel detect if a Clause 48 PCS were present. The present text in D2.0 can handle this scenario.
Arthur.
Arthur Marris From: Brad
Booth [mailto:bbooth@xxxxxxxx]
In Clause 45 for the 7.48.2 bit description in the table.
Backplane is different than copper cabling. While there is viability at the PCS and PMA levels, the PMD and MDI also need to be considered. QSFP would be used for CR4, but a QSFP will not connect to a CX4 connector; therefore, adding support for legacy CX4 is unlikely to have broad market potential.
Cheers, Brad
From: Arthur Marris [mailto:arthurm@xxxxxxxxxxx]
Brad, Where is the underlining of CX4 missing, could you give me the line number and page number?
The issue as I see it is that parallel detection is already described for the Clause 48 PCS in Clause 73 and as 802.3ba extends Clause 73 beyond backplane to include copper wiring there is a case for now including CX4 in parallel detection.
Arthur.
From: Brad
Booth [mailto:bbooth@xxxxxxxx]
I do agree with you Hugh that it was a shame that AN was not made available for CX4.
What I don’t like is that this is a kludge. In reviewing this some more, I noticed that the underlining of CX4 in 7.48.2 is missing. And, the connector for CX4 is different than the QSFP being used for CR4; therefore, how likely is legacy support. These are the types of things create extra work for maintenance and interpretation.
I think this could be done correctly, but I believe that within the scope of this project it is not as simple as being portrayed; hence the recommendation to delete.
Thanks,
From: Hugh Barrass (hbarrass) [mailto:hbarrass@xxxxxxxxx]
Brad/Arthur,
Firstly, I didn't champion this function or the text supporting it, but I agree with the general idea.
I think that including parallel detection within an autonegotiation function to support legacy usage of the same media is the responsible thing to do. It was how we worked in BASE-T autoneg, where it was well appreciated. I'm also glad that we are ruling out parallel detection for the new PHY, so we avoid an equivalent to the 100M parallel detection problem.
Regarding Brad's specific point: the legacy PHY needs no knowledge of autoneg. That's the whole point of parallel detection for backward compatibility. Someone implementing a new 40G only PHY will not link up with a legacy 10G PHY; someone implementing a new 10G/40G interface will link with a legacy 10G PHY; someone implementing a new 10G PHY may (or may not) choose to add autoneg in order to detect a mis-connection with a 40G only system. Autoneg would have been convenient if it had been added to 10GBASE-CX4 from the beginning, but as is usually the case, the first users of a medium never seem to consider "future compatibility."
Bottom line, I think that you should reject #565
Hugh.
From: Brad Booth
[mailto:bbooth@xxxxxxxx] Arthur,
The legacy 10GBASE-CX4 port has no understanding of auto-negotiation. While adding AN support for 10GBASE-CX4 may be viable, just adding a couple of references to it in Clause 73 doesn’t enable it. For instance, someone making a 40GBASE-CR4 port would read the Clause 73 and could add support for 10GBASE-CX4 AN. But someone making a 10GBASE-CX4 port would have no reference to read Clause 73 or any reference in Clause 54 how it fits into the architecture of the system; therefore, they are unlikely to add AN support.
While I agree that it is possible and it would be nice to have a way to do it, there is no context for CX4 AN in Clause 54. If there is suggestion to open that clause to add this function, then this has definitely gone beyond the scope of the project.
Cheers, Brad
From: Arthur Marris [mailto:arthurm@xxxxxxxxxxx]
Brad, I was not really clear in my original email. I meant 40GBASE-CR4 is using Clause 73 AN which brings copper cabling into the 802.3ba scope.
At the moment my proposed response is:
PROPOSED REJECT.
But adding Clause 73 AN to copper cabling is in scope. There is now the possibility of an end point using 40GBASE-CR4 connecting to a legacy 10GBASE-CX4 end-point.
but I am willing to be persuaded otherwise.
Arthur.
From: Brad
Booth [mailto:bbooth@xxxxxxxx]
Arthur,
Just because the market is using Clause 73 auto-negotiation with copper cabling doesn’t mean that adding this is within the scope of the project.
When something like this is added and it’s not done within the full context of 10GBASE-CX4. There are no edits to Clause 54 to make mention of this function, so there is no context.
While adding things like this may appear to be helpful, experience has shown this is where things get broken.
Cheers, Brad
From: Arthur Marris [mailto:arthurm@xxxxxxxxxxx]
Brad, You have submitted a TR comment to remove mention of 10GBASE-CX4 parallel detect because –CX4 is out of 802.3ba’s scope.
The reason I think this is in scope is because Clause 73 auto-negotiation is now being used with copper cabling for the first time.
Hugh, Do you have any comment on this? I think you championed adding this text in the first place.
Arthur.
|