| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Regarding the last part of Adee’s email: But we should surely define the “path startup function” of Annex 178B in a way that would not break down for physical layers that have these older
AUIs. And if changes to the older AUI annexes are requires, we can make them (but I believe we don’t need to). [JD>] This sounds like feature creep to me. And also the sound of a new project – as we would need to verify that the path startup function at these speeds actually works – which in essence is
not in scope for this project. [LB] Note that AUIs defined by IEEE 802.3 do not include the signal_detect required by the
start-up protocol for legacy interfaces. Best regards, Leon From: John D'Ambrosia <jdambrosia@xxxxxxxxx>
Adee See comments below. John From: Adee Ran (aran) <0000147b29386f6c-dmarc-request@xxxxxxxxxxxxxxxxx>
Correction below. </Adee> From: Adee Ran (aran) <0000147b29386f6c-dmarc-request@xxxxxxxxxxxxxxxxx>
HI John Thanks for providing this summary. Note that Annex 176B addresses PMA options and includes AUIs with 100G, 50G, and 25G per lane (e.g. Table 176B–1), and all PMD clauses include sublayer
tables which list these AUIs. So these are already covered. We should[[Adee]]
not assume that systems using these AUIs will not exist. [JD>] I think you are missing a key point – whether they exist or not is not the consideration of the scope of the PAR – 25 Gb/s and 50 Gb/s physical layer specifications were not used to define
800 Gb/s or 1.6 Tb/s physical layer specifications, so therefore we can’t apply them to 200 or 400 Gb/s. The fact that the scope includes “Using these new definitions for 800 Gb/s and 1.6 Tb/s, define physical layer specifications
and management parameters for the transfer of Ethernet format frames at 200 Gb/s and 400 Gb/s” allowed us to make substantive changes to existing sublayers of
these physical layers; for example, we are changing the PCS subclauses (119 and 172) and adding some optional features, and changing clause 120 to limit the ppm of the PMAs and AUIs. [JD>] Thanks – now I have something else to go review and worry about. We could theoretically make change the <200G per lane AUI annexes to include a training protocol, limited to their use in a new PHY defined in this
project (although I’m sure nobody wants to go there). [JD>] The scope talks about “defining” not modifying. 2x100G, 4x100G, and 8x100G have already been defined – so you are in essence saying we could modify. And I disagree with your assertion
here, as I noted in my analysis. But we should surely define the “path startup function” of Annex 178B in a way that would not break down for physical layers that have these older
AUIs. And if changes to the older AUI annexes are requires, we can make them (but I believe we don’t need to). [JD>] This sounds like feature creep to me. And also the sound of a new project – as we would need to verify that the path startup function at these speeds actually works – which in essence is
not in scope for this project. </Adee> From: John D'Ambrosia <jdambrosia@xxxxxxxxx>
All, Given the WG Recirculation Ballot currently underway, I have spent time pondering the presentation & discussion in the Annex 178B ad hoc this week. One of the observations noted in the presentation was: · AUI components is made up of xAUI-n’s (constrained by xAUI-n definition) & PMDs (no constraints) In combination with an output of the ad hoc discussion: · x-AUI-n needs clarification to be more inclusive of other AUIs (i.e. other than those defined in 802.3dj) The group essentially noted it wanted to define this annex to be generic in terms of PMDs and AUIs. As I noted at the end of the presentation – · Solution needs to be considered for project scope.
Per the PAR (https://www.ieee802.org/3/dj/projdoc/P802d3dj_PAR.pdf)
5.2.b Scope of the project: Define Ethernet MAC parameters for 1.6 Tb/s. Define physical layer specifications, and management parameters for the transfer of Ethernet format frames at 800 Gb/s and 1.6 Tb/s over copper and single-mode fiber
physical medium dependent (PMD) sublayers based on 200 Gb/ s or greater per lane signaling technologies.
Using these new definitions for 800 Gb/s and 1.6 Tb/s, define physical layer specifications and management parameters for the transfer of Ethernet format frames at 200 Gb/s and 400 Gb/s, when applicable. The first paragraph clearly limits the PMDs that can be addressed to those PMD sublayers based on 200 Gb/s or greater per lane signaling technologies. So it would seem to me that this annex needs to be constrained to PMDs that utilize >= 200 Gb/s signaling: For 200GbE: 200GBASE-CR1, 200GBASE-KR1, 200GBASE-DR1;200GBASE-DR-1-2;
For 400GbE: 400GBASE-CR2, 400GBASE-KR2, 400GBASE-DR2;400GBASE-DR-2-2 For 800GbE: 800GBASE-CR4;800GBASE-KR4; 800GBASE-DR4;800GBASE-DR4-2; 800GBASE-FR4; 800GBASE-FR4-500;800GBASE-LR4;800GBASE-LR1;800GBASE-ER1;800GBASE-ER1-20 For 1.6TbE: 1.6TBASE-CR8; 1.6TBASE-KR8;1.6TBASE-DR8;1.6TBASE-DR8-2 Additionally, this part of the scope statement needs to be considered: Define physical layer specifications, and management parameters for the transfer of Ethernet format frames at 800 Gb/s and 1.6 Tb/s over Physical layer specifications defined in this project have focused on 200 Gb/s signaling for the AUIs for 200GbE, 400GbE, 800GbE, and 1.6 TbE and 100 Gb/s signaling for 1.6 TbE. Therefore 25 Gb/s and 50 Gb/s based AUIs (which was not
used to define physical layer specifications for 800GbE or 1.6 TbE) for 200 GbE and 400 GbE do not appear to be in scope. Additionally, while we defined 100 Gb/s signaling for 1.6TbE, the 100Gb/s based AUIs for 200GbE, 400GbE, and 800GbE are already defined, and the scope does not state “modify existing physical layer specifications.” Furthermore, the objective
for 100 Gb/s based 1.6 TbE AUI was adopted to support test equipment, which IMO doesn’t seem to need “ILT.” Do we really need to devote our limited resources to it? I am struggling to believe this should be a priority.
Furthermore, if we include other PMDs and AUIs, the TF, to do its job properly, needs to consider them, otherwise how can we be assured they actually work – and this raises an issue for me as Chair, hearing presentations that are clearly
out of scope. This is a discussion that needs to be had with the WG Chair, David Law. David – if you are reading this email, it would be appreciated if you can reply to this email. So, IMO, Annex 178B should address: PMDs that utilize >= 200 Gb/s signaling: For 200GbE: 200GBASE-CR1, 200GBASE-KR1, 200GBASE-DR1;200GBASE-DR-1-2;
For 400GbE: 400GBASE-CR2, 400GBASE-KR2, 400GBASE-DR2;400GBASE-DR-2-2 For 800GbE: 800GBASE-CR4;800GBASE-KR4; 800GBASE-DR4;800GBASE-DR4-2; 800GBASE-FR4; 800GBASE-FR4-500;800GBASE-LR4;800GBASE-LR1;800GBASE-ER1;800GBASE-ER1-20 For 1.6TbE: 1.6TBASE-CR8; 1.6TBASE-KR8;1.6TBASE-DR8;1.6TBASE-DR8-2 C2C and C2M AUIs based on 200 Gb/s 200GAUI-1, 400GAUI-2, 800GAUI-4, 1.6TAUI-8. Full disclosure – I will be submitting comments based on this thought process. Regards, John D’Ambrosia Chair, Annex 178B Ad hoc Chair, IEEE P802.3dj Task Force To unsubscribe from the STDS-802-3-B400G-178B list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-B400G-178B&A=1
To unsubscribe from the STDS-802-3-B400G-178B list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-B400G-178B&A=1
To unsubscribe from the STDS-802-3-B400G-178B list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-B400G-178B&A=1
To unsubscribe from the STDS-802-3-B400G-178B list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-B400G-178B&A=1
To unsubscribe from the STDS-802-3-B400G-178B list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-B400G-178B&A=1 |