Hello all, the way I look at this, there should not be any interoperability issues. Along with that, there should not be a requirement that vendors must implement
all ‘options’.
First, I would agree that labeling a device as ‘25GCR’ compliant is insufficient, unless a device supports all requirements for all use cases for that label.
Since I don’t think that is acceptable, we need labels to differentiate the capabilities devices support.
Let’s also say that devices are not required to support all combinations. If we can make it work, we would enable vendors (and providers) to differentiate
or innovate by any means they see fit, without restrictions.
Therefore, the first thing we are looking for are ‘label’s which define the required and guaranteed to work by IEEE combination of { PORT , FEC, CHANNEL } that
customers’ can understand. The second thing we are looking for is a way to advertise the capabilities necessary to meet the requirements of the label(s). The last thing we are looking for is a way to advertise other combinations. In effect, to create user
defined labels.
We can call those combinations a PHY type, or not, and I don’t think it matters.
What matters is that there is a definition (aka, a label) that defines what must be present in a design that is consistent with (meets all of the requirements)
of that label.
To me, what that means is that devices should be marketed indicating those labels they support. If a cable is plugged in that is inconsistent with the label(s)
supported by the device, or if AN indicates a LP is not able to operate with the labels supported by the device, a warning should be issued by the SW. There is no interoperability ‘problem’. The devices are not consistent. That is a perfectly acceptable
outcome.
Let’s presume we use the label’s CR-S and CR-L. Devices are marketed as supporting CR-S and/or CR-L (or neither). How that information is carried via AN is
not really critical, as long as it does not interfere with the last requirement of allowing other ‘labels’ to be advertised. To make sure other labels are possible, when an FEC might not be required, we need the ability to advertise NO FEC, CL74 FEC, and/or
CL108 FEC.
I think evaluating the power/area costs of various FECs to decide whether a vendor must implement all label’s as defined by IEEE is not really appropriate.
Nothing is free. Everything has a cost. Some of the multiples for how many instances of a device exist in a Data Center are pretty large (as indicated by Data Center providers). We really cannot determine the value for any end user of the area/power of
an FEC.
Customers require the ability to make those tradeoffs. We should not prohibit that tradeoff, especially if any uncertainty about interoperability can be resolved.
If we can resolve any interoperability issues by having a couple of labels which define what a device supports, then I would content we have solved that issue.
In the end, any device that supports advertising what is necessary to indicate the whether IEEE labels are supported, and which also has the flexibility to
support other modes, should meet all of the requirements. At least that’s my view.
Thanks
Eric
From: Brad Booth [mailto:bbooth@xxxxxxxx]
Sent: Thursday, February 19, 2015 2:43 PM
To: STDS-802-3-25G@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-3-25G] Thoughts from today's ad hoc
George,
Exactly.
I think part of the reason for the difference of opinion is whether or not you see FEC as being an enhanced operating mode of the PHY.
Personally, I'd rather see it as an operating mode. Why? Because it would permit me to buy a PHY with only RS-FEC supported and a PHY with only Clause 74 FEC supported, put them on a 1 meter link and have them negotiate to not use FEC (highest
common denominator). With the CR-L and CR-S variants being pushed today, I believe it would result in a non-compatible mode; there would be no highest common denominator.
While the task force does have two reach objectives, I believe the market would be much happier to see one PMD with multiple modes of operation rather than multiple, inoperable PMDs.
Thanks,
Brad
On Thu, Feb 19, 2015 at 10:54 AM, George Zimmerman <george@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
Brad – two devices labeled the same thing should support a common autoneg PHY type. That is why we label them so users know them from each other. If not, then they are not the same PHY type and should be labeled differently. For example, a port labeled “1000BASE-T” is a different thing from a port labeled “1000/10GBASE-T”. The 1000/10GBASE-T port indicates a second PHY type in addition to the enhanced capability (10GBASE-T), and the two will interoperate at the 1000BASE-T PHY type. BUT, if someone were to make a PHY that was just 10GBASE-T, the 1000BASE-T and a ‘just 10GBASE-T’ wouldn’t interoperate. (I know you know this, but some people don’t, it’s amazing how many people think the standard requires lower speed support on BASE-T PHYs, because the market demands that lowest common denominator be supported)
In contrast, an OPTION, might be like optional EEE capability, where both PHYs are labeled the same and interoperate and pass data without the function enabled. You still get data passing without it.
The concept of OPTION becomes problematic to apply when you go to a shorter media type – even when the option is for the extended reach capability – because the media isn’t part of the port where the labeling sits – hence, you might have 2 PHY types, or one type and a mandatory capability.
The question you are asking is not about autoneg – it is about whether we have 2 PHY types.
George Zimmerman
Principal, CME Consulting
Experts in Advanced PHYsical Communications Technology
george@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
(PLEASE NOTE NEW EMAIL ADDRESS. THE OTHER WILL STILL WORK, BUT PLEASE USE THIS FOR CME BUSINESS)
From: Brad Booth [mailto:bbooth@xxxxxxxx]
Sent: Thursday, February 19, 2015 10:39 AM
To: STDS-802-3-25G@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-3-25G] Thoughts from today's ad hoc
That is the crux of the issue.
One aspect that does seem to concern folks is that if two devices are labeled CR that they may not interoperate even though the port names are the same. That is why autoneg is used. It determines if there is a possible mode of operation. If there is a mode of operation that is compatible for both devices, that is the mode they come up in and the standard better be written in a manner that permits them to interoperate.
As for interoperability in the market, there is no guarantee for that. If there was a guarantee, there would be no need for qualification labs, test equipment or UNH-IOL.
Thanks,
Brad
On Thu, Feb 19, 2015 at 7:18 AM, Gary Nicholl (gnicholl) <gnicholl@xxxxxxxxx> wrote:
Dan,
Thanks for your email. I think you hit the nail on the head. The issue is really with the definition of ‘option’ or ‘optional’ . There is obviously a very big difference between “option to include in the implementation” and “option to use in a given application”.
This is something that has always confused me when people use the word ‘option’ in standards. If people mean “option to include in the implementation" then I don’t see how that can ever result in an interoperable standard, and your example below clearly spells that out .. and no amount of auto-neg will help the situation. However if option means “option to use in a given application, but required in all implementations” then this does provide an interoperable standard, with the benefit of the being able to use something like auto-neg to turn the feature off if not required in a given application/configuration.
Gary
From: Dan Dove <dan.dove@xxxxxxxxxxxxxxxxxx>
Organization: Dove Networking Solutions
Reply-To: Dan Dove <dan.dove@xxxxxxxxxxxxxxxxxx>
Date: Wednesday, February 18, 2015 at 5:44 PM
To: "STDS-802-3-25G@xxxxxxxxxxxxxxxxx" <STDS-802-3-25G@xxxxxxxxxxxxxxxxx>
Subject: Re: [STDS-802-3-25G] Thoughts from today's ad hoc
Hi Brad,
I think the counter argument goes like this...
If you have only a single instance in the market called "25GBASE-CR", and it allows someone to build a product that supports only 3m cables (does not advertise 5m capability), a customer will purchase a bunch of switches, 5m cables, 3m cables, and servers, all from different suppliers, plug them all together..double checking to make sure they are all "25GBASE-CR", then discover that some combinations of products don't talk to each other.
They scratch their heads, look for details on what the common modes of failure are, then come to a conclusion that only supplier X switches, and supplier Z NICs, and 5m cables are problematic. supplier Y's stuff is working with all cables. They go to supplier X and supplier Z, explain their problem, and those suppliers say "We are compliant to the standard, but don't support 5m cables".
What!?!?
"Oh ya, the RS-FEC required to support 5m cables was optional, and because it added X% to the die, our chip supplier left it out of the design to save cost and power...but we are still compliant!"
Clearly that doesn't work out well.
I see the challenge as this;
If there is no significant cost/power/die/etc impact of supporting 5m over 3m, then we should have a single "25GBASE-CR" standard and mandate support for all cable lengths. Deciding not to support RS-FEC would be an option for applications with shorter cables to reduce latency, but only an option to use, not an option to include in the implementation.
If there IS a significant cost/power/die/etc impact of supporting 5m over 3m, we have to consider whether that additional cost/power/die/etc will burden markets that want optimum cost/power/die/etc and don't need 5m. If yes, then we should have two specs (CR-L and CR-S) to allow market optimization. If not, then we force the market to accept one-size-fits-all.
To be frank, I have no preference in where we end up, but do wish to see the key questions answered with sufficient data to make the right decision.Dan Dove
Chief Consultant
Dove Networking Solutions
530-906-3683 - MobileOn 2/18/15 2:05 PM, Brad Booth wrote:
I want to say thanks to Jeff for listing some of the options the task force can consider for auto-negotiation. All the options presented by Jeff and Eric could be specified in the draft standard.
I'd like to provide some clarification on my opposition to using -L and -S options. The primary concern I have is reflected in statements some people have made in justifying the -L and -S options. In my humble opinion, the -L and -S options push the draft standard towards being an implementation specification and permitting folks to market their devices as either -L or -S compliant. This could create a potential bifurcation of the market; hence my request for those supporting a -L and -S option to provide information on the broad market potential.
As an example of auto-negotiation not used in as an implementation specification, let's look at 1G. There is a load of information that is exchanged during auto-negotiation. In 1000BASE-X, AN exchanges pause and duplex information. In 1000BASE-T, even more information is exchanged like master-slave, etc. What is important to understand in the operation of these devices, a management entity assists with the establishment of the link. If a 1000BASE-SX local device only indicates half duplex and its 1000BASE-SX link partner only indicates full duplex, then AN will signal to the management entity that the link cannot be established. The half duplex device is not labeled a 1000BASE-SX-H device and the other is not labeled a 1000BASE-SX-F device; those labels would be an implementation option. The management entity could decide that either these devices can never talk, or that auto-negotiation needs to be restarted with a different exchange of capabilities.
That's what worries me about using -L and -S in AN and tying it to the port type or maximum cable assembly length. That's an implementation. And honestly, -L and -S starts to sound like marketing terms and not technically justified terms. Permitting AN to exchange capabilities and preferred modes of operation (no -L or -S option) really does provide the greatest flexibility for implementations in the market.
Thanks,
Brad
