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
|