Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [802.3_100GNGOPTX] SMF and MMF Ad Hoc meetings: MMF objective



Hi Petar,

The functional behavior of modules is outside the scope of the IEEE and discussion of how to restrict specific behavior is probably best avoided on this reflector.

One must keep in mind that any MDI, defined by the IEEE, is only defined while operable.

For example, there is no requirement for performance while powered off. Therefore, if a module is powered off, its MDI performance is undefined beyond the point that it must not send out signals that disrupt the network. If a manufacturer chooses to power down or disable modules based on proprietary criteria, that is outside of our scope.

Rather, we (individuals) should recognize that such aspects of networking equipment exist and if we feel it to be detrimental to the industry, seek a solution within the purview of the MSA consortia or other industry groups that can influence the specification of MSAs.

Regards,

Dan

On 2/28/12 10:36 AM, Petar Pepeljugoski wrote:
Jeff,

Probably a way around it would be to have interoperability objective and precluding the vendor from claiming standard compliance (if they use lock codes). Not sure that this will solve the problem though. But it will have some impact if a component is labeled "X" standard non-compliant - I don't know if customers would then buy non-compliant parts.

Regards,

Peter

Petar Pepeljugoski
IBM Research
P.O.Box 218 (mail)
1101 Kitchawan Road, Rte. 134 (shipping)
Yorktown Heights, NY 10598

e-mail: petarp@xxxxxxxxxx
phone: (914)-945-3761
fax:        (914)-945-4134




From:        Jeffery Maki <jmaki@xxxxxxxxxxx>
To:        STDS-802-3-100GNGOPTX@xxxxxxxxxxxxxxxxx
Date:        02/28/2012 01:01 PM
Subject:        Re: [802.3_100GNGOPTX] SMF and MMF Ad Hoc meetings: MMF objective




All,
 
Lock out codes can be employed with even pluggable transceivers.  So, we would be defining a standard that would actually enable continued behavior that the end customer finds to be a “bitter” experience.  They would have to buy and stock two different system specific modules, a different one for each end.  It sounds to me like the real industry solution is to be found elsewhere.
 
Jeff
 
 
From: Kolesar, Paul [mailto:PKOLESAR@xxxxxxxxxxxxx]
Sent:
Tuesday, February 28, 2012 6:20 AM
To:
STDS-802-3-100GNGOPTX@xxxxxxxxxxxxxxxxx
Subject:
Re: [802.3_100GNGOPTX] SMF and MMF Ad Hoc meetings: MMF objective

 
Stephen,
Your points are well taken.  It’s not expected that an interoperable very short reach PMD standard would produce a solution as cheap as AOCs.  
 
But such a standard provides a potentially lower cost alternative to an SR4 with longer reach, depending on the technology boosts that are used, while solving a very real problem.  The trouble with AOCs is that if port-lock-out policies are in force, both ends of the channel must plug into the same brand of switch or server.  That is an unattractive constraint customers face with surprise at first followed by bitterness.  They fault IEEE for not doing its job to ensure interoperability.  A very short reach solution would remedy that by providing an interoperable alternative to AOCs.  The customer gets the best of both world:  AOCs when the brand is common at both ends, and a lower cost interoperable solution when they are not.
 
Regards,
Paul
 



From: Trowbridge, Stephen J (Steve) [mailto:steve.trowbridge@xxxxxxxxxxxxxxxxxx]
Sent:
Tuesday, February 28, 2012 7:51 AM
To:
STDS-802-3-100GNGOPTX@xxxxxxxxxxxxxxxxx
Subject:
Re: [802.3_100GNGOPTX] SMF and MMF Ad Hoc meetings: MMF objective

 
Hi Brad,
 
> If there is market potential for an AOC to provide a short reach solution, then there is probably market potential for the study group to consider a short reach objective.

I’m not sure that necessarily follows. The bar is far lower to come up with an AOC, since the AOC vendor just needs to meet the CAUI spec at each end and what they do in the middle is their business (and may rely on whatever tricks and techniques that particular vendor is good at). Whether all vendors pick the same methods inside of the AOC is irrelevant.

The bar is much higher for a short reach objective: you would need to have confidence that you can make the same thing work based on a “least common denominator” of what the various suppliers can do and that you can write an interoperable spec around that that allows the two ends to come from different vendors, and that you have confidence you can get 75% to agree to do it the same way with an acceptable amount of debate to get there. It is not clear that you could ever make this solution as cheap as one where the same vendor has control of the entire link and can optimize the solution based on their own capabilities.
Regards,
Steve