| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Tom / all, While I appreciate everyone’s input – no one has suggested that the next speed of Ethernet is being pursued and being justified by the lower speed breakout rates. I noted clearly up front – this is a matter of defining the scope of the Study Group. It has already been a matter of discussion that some have expressed the desire to look at being able to support the breakout application. This creates the challenge for me to define the scope to allow that conversation to happen inside the anticipated study group. However, allowing something as part of the scope does not mean it is the focus of the project or the scope of the future PAR. These are decisions that the future study group would need to make. Jeff – Sorry but I need to give you a little bit of history lesson. 802.3ba was not built on the back of the next lane technology. Optically there was stuff happening at 40G, but electrically there was no effort inside of 802.3ba to define 25G electricals. And 802.3bs was not initially based on 50 Gb/s – that was a decision that happened once we got into TF. Rather much of the earlier conversation was looking at a x16 solution. As I am fond of saying – Good ? for study group! John From: Huber, Tom (Nokia - US/Naperville) <tom.huber@xxxxxxxxx> Hi John, I agree with what Steve and Jeff have stated. While having a higher rate may push companies to develop new pluggable form factors that system designers will then use in lower rate breakout applications in order to optimizes front panel real estate, as we’ve seen in the past (e.g., QSFP+ used to support 4x10G, QSFP28 used to support 4x25G), this is not a justification for defining the higher Ethernet rate. If there is a market for higher density 100G or 400G plugs, the industry will build them whether or not there is an 800G Ethernet rate. We need to be able to justify the higher speed Ethernet rate without appealing to alternative applications people will find the modules that support the higher rate. Tom From: Jeffery Maki <00000d5963b8071f-dmarc-request@xxxxxxxxxxxxxxxxx> John, It helps. Some call this “channelization” where higher speeds of Ethernet are formed by the physical layer bonding provided by the virtual lane markers of the PCS. I will avoid any highly loaded terms in the following. I will just use “lane.” As Steve noted, we tend to build the next big project based on the latest and greatest lane technology to define the next higher speed of Ethernet and then subsequently refresh lower speeds of Ethernet with the new lane technology. Now when there is doubt about the broad market potential of the next higher speed of Ethernet and any new lane technology is not ready for standardization, we look at bolstering the broad market potential for the new higher speed of Ethernet by pointing out that existing lane technology has broad market potential in supporting lower speeds of Ethernet. A new project could define 800G Ethernet based on lane technology from the existing 100G and 400G Ethernet standards. An example would be 800GBASE-DR8. The reality is that the implementation may only be used as 2 x 400GBASE-DR4 or 8 x 100GBASE-DR and does nothing to prove 800G Ethernet has broad market potential. This is the confusion we garner from module volume figures that analysts publish. We don’t know how the module is put into use to know what speed of Ethernet it proves is being adopted. Jeff From: jdambrosia@xxxxxxxxx <jdambrosia@xxxxxxxxx> [External Email. Be cautious of content] Jeff, Let me try a different tact – For all of these instances – the specifications that would exist on each different pair or optical fiber should be the same –
So the specification for each should be essentially the same – just varying the number of different pairs or fiber. In the case of F/L/E we are looking at different specifications for the different number of lanes, as the associated mux/demux loss would vary, based on the number of optical signals being muxed /demuxed together. Does this help ? John From: Jeffery Maki <jmaki@xxxxxxxxxxx> John, Let me ask a question first. I your case (a), do you mean the individual interfaces will support ingress signals on separate time domains within +/-100ppm or are you simply looking at the fact that there is exact alignment with the PMD definition of a lower speed of Ethernet where any time domain support is an implementation detail? Jeff From: jdambrosia@xxxxxxxxx <jdambrosia@xxxxxxxxx> [External Email. Be cautious of content] Suggestion? From: Jeffery Maki <jmaki@xxxxxxxxxxx> John, I chose my words carefully. As others have commented, they understand things in an operational sense from the implementations they see. Constricting the definition of “breakout” from its broader industry meaning does not seem like a good start. Perhaps use a different word that doesn’t come with so much “baggage.” Jeff From: jdambrosia@xxxxxxxxx <jdambrosia@xxxxxxxxx> [External Email. Be cautious of content] Jeff Please keep my perspective in mind right now – I am trying to draft the CFI and scope of a new standard effort in the IEEE 802. Not the scope of an implementation in an industry MSA. Different requirements for each. And I hope all recognize the challenge. John From: Jeffery Maki <jmaki@xxxxxxxxxxx> John, It is hard at this point to separate out conceptually the implementation from the abstract PHY. One can devise a superset module that supports a number of compliant PHY implementations with some being parallel fiber based and others being duplex fiber based. One’s choice of focus on your (a) or your (b) is their choice of favorite point of view. Both (a) and (b) are supported equally well by the module. Jeff From: John D'Ambrosia <jdambrosia@xxxxxxxxx> [External Email. Be cautious of content] All – conversation is good, and highlighting an issue that needs to be addressed. There appears to be a trend of
I can see a path to relating Item A to be within scope of Beyond 400 GbE effort. I am not seeing that same path for Item B. John From: Ted Sprague <tsprague@xxxxxxxxxxxx> I’m used to the second definition (independent PHYs grouped in the same MSA, common interface for management). In the first case, the module may support a unified mode or multiple individual modes – but only the second is referred to as ‘breakout’. Thanks Ted From: David Ofelt <00000d9f58951f93-dmarc-request@xxxxxxxxxxxxxxxxx> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. I think there are two different concepts that end up being colloquially referred to as breakout. The first is that case you detaiil below- a set of parallel media lanes that can be grouped in various ways- either as a single unified PHY or as a number of slower PHYs. The other case is a module that happens to hold a number of PHYs that are completely independent- like a QSFP-DD/OSFP module that has 4 x 100GBASE-LR optics. I’m Ok with declaring that “breakout” just covers the first case and your list is a good start at scoping the definition, but if we do that, I’d like us to figure out a name for the other case. I find that when I talk to people about modules- it is important to clearly address both cases, since many folks have only one of the cases in mind and conversations can get confusing.
-- DaveO From: John D'Ambrosia <jdambrosia@xxxxxxxxx> [External Email. Be cautious of content] All, As I explore the scope for the Beyond 400 GbE effort, I have been having a number of conversations related to “breakout” While we all discuss it – I have never seen some actual formal definition that is agreed upon within 802.3. So I would like to get some input. I am going to start with breakout actually does and solicit input before proposing some definition to potentially use. I see break out of the following –
FR / LR / ER optics – I don’t see as being part of breakout. Thoughts? John To unsubscribe from the STDS-802-3-NGECDC list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-NGECDC&A=1 To unsubscribe from the STDS-802-3-NGECDC list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-NGECDC&A=1 To unsubscribe from the STDS-802-3-NGECDC list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-NGECDC&A=1 To unsubscribe from the STDS-802-3-NGECDC list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-NGECDC&A=1 To unsubscribe from the STDS-802-3-NGECDC list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-NGECDC&A=1 To unsubscribe from the STDS-802-3-NGECDC list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-NGECDC&A=1 To unsubscribe from the STDS-802-3-NGECDC list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-NGECDC&A=1 |