Rob –
I think your own language makes their point.
You talk about not fragmenting the market, but then you talk about making either “a PHY (or set of PHYs)”.
Realize that the two are quite different from a market standpoint.
Each member of the “set” has to stand on its own, and is a market fragment.
It may work with the others under some circumstances, but if the silicon volumes aren’t there, they won’t survive.
If none of the individuals of the set have sufficient volume, the whole market gets broken into non-sustainable pieces.
This scenario drives one to make a PHY with all the options in it, which then says you have to make ONE
phy, not a set, and give it capabilities to serve all the pieces of the market.
I listened with interest to today’s discussion, because I believe that we will crack this nut.
It also appears to be the same problem that BASE-T has been beating on for almost a decade now – how to make a PHY with 2 reach modes, not have all PHYs pay for full capability, yet still have viable market for both segments.
So far, the BASE-T folks haven’t knocked out a viable solution, other than suggesting they are two PHY types.
This segmentation gave legs to the direct attach PHYs in the first place – however, I can remind you that SFP+ interoperability took a while to work out on different lengths and cable vendors – we will need to do some work on normative channels..
George Zimmerman
Principal, CME Consulting
Experts in Advanced
PHYsical Communications Technology
george@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
310-920-3860
(PLEASE NOTE NEW EMAIL ADDRESS.
THE OTHER WILL STILL WORK, BUT PLEASE USE THIS FOR CME BUSINESS)
From:
Rob Stone [mailto:rob.stone@xxxxxxxxxxxx]
Sent: Wednesday, February 25, 2015 3:01 PM
To: STDS-802-3-25G@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-3-25G] Market Fragmentation
Hi Rick and Dan
I recognize that we need to make sure we are addressing BMP, but I don’t believe it is valid to equate creation of separate PHY types with market fragmentation.
There seems to be support within the group for implementing a PHY (or set of PHYs) which support CL108, 74 and no FEC). I think what we are discussing is how you AN these modes with minimal customer confusion and maximum flexibility. I see the perceived drawback
of creating three PHY types therefore somewhat artificial as it’s just another way of meeting those end goals.
Remember, we have received feedback that there is a desire from the end customers that they want maximum flexibility to not design in redundant modes for a
particular use case, as well as making the solution maximally plug and play interoperable. I would argue that the three PHY solution achieves both these goals. If you want maximum interoperability, implement all three PHYs. If you want to do a subset, then
that’s OK too, and if you do this it will be very clear what FEC modes and channels are and are not supported. I don’t believe this would be the case if we went for single PHY solution, especially if you want AN to resolve in a single pass.
Thanks
Rob
From: RABINOVICH, Rick (Rick)**
CTR ** [mailto:rick.rabinovich@xxxxxxxxxxxxxxxxxx]
Sent: Wednesday, February 25, 2015 11:17 AM
To: STDS-802-3-25G@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-3-25G] Market Fragmentation
Hi Dan,
I do concur with your comments.
As a switch manufacturer I believe that fragmenting the market into niche ports defeats the broad market potential. Directly or indirectly the feedback I always
get from end-users is to deliver plug-and-play solutions rather than pick and choose what you specifically need today even though it may become useless when different needs appear next year. Other system manufactures may get a different feedback and their
comments are welcome. I rather move in the direction of a coherent and comprehensive solution.
Thank you,
Rick Rabinovich
Principal Hardware Design Engineer
Distinguished Member of the Technical Staff
Alcatel-Lucent Enterprise
T: +1 818 878 4584
26801 West Agoura Road
Calabasas, CA 91301
rick.rabinovich@xxxxxxxxxxxxxxxxxx
www.alcatel-lucent.com/enterprise
From: Dan Dove [mailto:dan.dove@xxxxxxxxxxxxxxxxxx]
Sent: Wednesday, February 25, 2015 9:29 AM
To: STDS-802-3-25G@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-3-25G] Market Fragmentation
All,
As we discuss potential market fragmentation for 25GBASE-CR PHYs based upon reach (CR-S, CR-L, etc)...
We should also keep in mind that MMF optics will require RS-FEC.
So, if we choose to create a PHY type that does not support RS-FEC, we are not just dividing it from the relatively small 3-5m copper market. (I assume its small relative to 0-3m market) but we are also dividing it away from the larger body of 100G devices
that would break out into 4x25G devices, and dividing it away from 25G MMF devices which may have a reasonable market size.
There was a comment made in today's adhoc that plug-and-play leads to happy customers. I would take it one step further, plug-and-play leads to more rapid market adoption and conversely, lack of plug-and-play can lead to substantial market disruption.
Historically, standards that have had trouble getting off the ground due to interoperability problems, lagged and sometimes never gained market acceptance. In some cases, MSAs or other means were used to achieve the desired customer satisfaction. We could
literally "snake-bite" the standard in customer's eyes if we don't have plug-and-play, or at least clearly defined PHYs so that customers don't attempt to gain interoperability where it's not intended.
I believe we should take all of this into account when making our decision on which way to proceed and am willing to collaborate on a presentation to this effect if someone wishes to join me. I don't have a conclusion at this point, but am leaning toward
a single PHY with both FECs and the ability to disable FEC for low-latency applications. This leaning comes from the data presented by Jeff Slavik combined with comments that in a typical ASIC the overall impact of the PHY gate counts for RS-FEC will be relatively
small. I also agree with Eric's idea of remapping priority for low-latency vs cable-reach to ease Auto Negotiation, but would prefer to see it simply CR vs CR w/o FEC. I base this on the idea that only those who are engineering links would disable FEC.
--
Dan Dove
Chief Consultant
Dove Networking Solutions
530-906-3683 - Mobile