You asked for feedback. It is up to you to pick and choose what you shall do with the feedback. Use as you wish.
I think we are speaking past each other. I’m not trying to disagree with you. I think you misunderstood me earlier.
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
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
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
[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 –
- Backplane
- Twin-ax cabling based on multiple different pairs
- SR optics based on parallel MMF
- DR optics based on parallel SMF
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
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
[External Email. Be cautious of content]
Suggestion?
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
[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
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
[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
- Breaking out a standards based PHY into the individual channels of the PHY into independent links
- An industry or vendor defined implementation that gangs a number of independent links together.
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
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
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.
I am also Ok with defining “breakout” to cover both cases, but then we can make that explicit in the definition.
--
DaveO
[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 –
- Backplane
- Twin-ax cabling based on multiple different pairs
- SR optics based on parallel MMF
- DR optics based on parallel SMF
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