Re: [802.3_100GNGOPTX] SMF and MMF Ad Hoc meetings: MMF objective
Dan,
I was just commenting on the complains
by Brad and Jeff....
My statement was that if the group (I
mean 802.3) sees this as detrimental, it should restrict vendors claiming
compatibility with a standard standard "X".
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:
Daniel Dove <ddove@xxxxxxx>
To:
Petar Pepeljugoski/Watson/IBM@IBMUS
Cc:
STDS-802-3-100GNGOPTX@xxxxxxxxxxxxxxxxx
Date:
02/28/2012 02:09 PM
Subject:
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