| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
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. |