| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Brad, I initially had the same concerns myself, but
thanks to conversation with Mr. McSorely over a beverage, he pointed out that
these connectors really enable different application spaces. The QSFP
style connector will enable application spaces where an equipment provider can
use either an optical or copper based module. The CX4 style connector
will enable application spaces focused solely on copper based solutions. I
think this is a little different than the previous case you cited, where two
competing connectors for the same space were cited (and I believe a preference
indicated). This in my mind is a reasonable
justification for the choice the Task Force made. Regards, John 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: 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: 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: 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: 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. |