| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
I'm sure most people are aware of this, but I felt it
should be reiterated.
Within the draft specification, the required compliance
point is the MDI. All other interfaces behind the MDI are optional
instantiations of service interfaces. Implementation flexibility is where
two interoperable devices comply with the specification at the MDI, but use
unique methods behind the MDI to comply with the
specification.
If a longer reach annex changes the specification at
the MDI, then this should be consider a new PMD which at this point in time
would be considered beyond the scope of the standard.
Thanks,
Brad From: Ryan Latchman [mailto:Ryan.Latchman@xxxxxxxxxx] Sent: Thursday, August 28, 2008 9:54 AM To: STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx Subject: Re: [802.3BA] 802.3ba XR ad hoc next step concern Hi
John, I agree with your
conclusion. The flexibility available with either a PPI or a XLAUI / CAUI
interface enables a variety of implementations which can include the XR reach
objectives. I think an annex which outlines how to achieve longer reach
using the tools available in the standard will provide significant
implementation flexibility. Best
Regards, Ryan From: John DAmbrosia
[mailto:jdambrosia@xxxxxxxxxxxxxxx] Brad, Thank you for bringing up these
points. During the course of this project, I have emphasized that we are
developing an architecture that should enable as many implementations as
possible, and not writing an implementation specification. You have hit
the nail on the head with your points. The base proposal for the BASE-SR
physical layer specifications is based on the jitter associated with a
non-retimed interface to achieve 100m. There has been general discussion
that adding retimers to a BASE-SR module would then extend reach. Per
http://www.ieee802.org/3/ba/public/AdHoc/MMF-Reach/Comparisons_xr_01_0722.xls,
and column D (latchman_xr_01_0508), CDR’s on one side would extend the reach to
168m and CDRs on both sides would be 208m (both #’s are based on OM3
fiber). So if we review the adopted
architecture proposal, and consider implementations for different reaches, what
do we find? The thing is that we approved an
architecture with the XLAUI / CAUI optional interface. This is a retimed
interface. So it seems to me that we have developed an architecture where
either implementation using the same PMD sublayer could be developed, i.e. a PPI
(non-retimed interface) to a module or a XLAUI / CAUI (retimed interface) to a
module. Thinking about how to implement in
the spec - The minimum guaranteed interoperability would be 100m, which is in
the current specification. An informative annex could then go into
engineered links for 150 and 200m, based on the use of modules with either the
PPI or the XLAUI / CAUI interfaces. Pardon the choice of words, but I
think this would be rather informative anyway, as the spec already enables both
types of implementations. Based on this, it would seem that
the TF has been successful in developing an architecture where implementations
could be developed to support either reach. Regards, John From: Brad Booth
[mailto:bbooth@xxxxxxxx] Dave, I agree. A 5%
cost adder seems reasonable for a 17% increase in broad market
potential. I do wonder if part of
the problem is the compliance points TP0, TP1, TP1a, TP4, TP4a and
TP5. In past efforts such as 802.3z and 802.3ae, these compliance points
have been left up to MSAs and only TP2 and TP3 were of concern. Now the
task force is dealing with such issues as modules and the cost impact of various
implementations. IMHO, IEEE 802.3 was trying to avoid writing
implementation specifications and was focused on compliance
specifications. Could it be that these compliance points are causing the
task force some heartache because it results in an implementation
specification? Just food for
thought... Thanks, Brad
From: Chalupsky, David
[mailto:david.chalupsky@xxxxxxxxx] The 20% cost premium
applies to only one of our proposed XR
alternatives. According to the
alternatives spreadsheet (Comparisons_xr_01_0708.xls) the CDR option adds only
5% module cost premium over the base proposal and provides reach of 168m to 251m
(across the OM3/4, one-sided/two-sided matrix). I’m struggling to keep
up with the conversation here – but I believe that the 5% alternative addresses
the same problem as the 20% alternative, right? On that assumption I
will rephrase Dan’s non-rhetorical question to address a 5% cost adder for 17%
increase in coverage: If I have the choice
between: A) carry two product
SKUs: 100m and 150m, with 5% Bill of Material cost delta on the 150m product;
or B) carry only the 150m
product I would accept option B
& use only the 150m module even though I know that most of my customers will
use it at <100m. By considering only the
bill of material of the module we are missing two aspects of the big picture on
cost. 1) Carrying multiple
product SKUs through design, validation, manufacture, customer qualification,
customer confusion, etc. adds cost. Regardless of whether
802.3ba adds a second objective, if the module supplier base develops two
different module solutions for 100 & 150m, then the 100m solution will carry
an intangible cost burden and the desired 0% cost adder for 100m will not be
achieved anyway. 2) The module is not
the whole solution. The CDR module solution does not add cost to the host.
Thus a 5% increase in module cost is less than 5% increase in the total
cost of the switch plus modules. I appreciate that the
task force is learning from the history of 10GBASE-SR: that over-specifying the
solution had a long term cost impact. However, we should take
away another lesson from 10Gbit: that providing too many options confuses
the customers & slows adoption. I strongly urge the
task force to provide a single solution for parallel MMF. I believe that
it’s worth a 5% cost adder to the module to achieve
that. I really have no
personal (or commercial) reason to prefer the CDR option. I’m just looking
at the 5% figure in the spreadsheet & wondering why this isn’t a
no-brainer. Thanks for your
time, Dave
Chalupsky From: Hi
Mike,
Assuming we make the
decision that we want to stick with the "standard" model at 100m to keep those
customers we would lose by adding cost, does the IEEE standardize a 150m
solution or do we let the market solve that problem on its
own? This is not a
rhetorical question, although it might appear to be. Can someone provide any
insight on the sensitivity of the market to an additional cost of 20% for every
100m link to satisfy the additional reach? If the market is
insensitive to cost (on this scale) then perhaps the additional reach is
justified. If the market is going to be sensitive to that differential cost,
then the question falls back to whether the IEEE wants to do a 150m spec or
leave it to a market-defned solution. Dan From: Mike Dudek
[mailto:Mike.Dudek@xxxxxxxx] Hi
Dan Of course if we don’t
increase the cost of the basic Grade A model and have a Grade B version of the
same part for extra reach with the Grade B version being loaded with any
additional costs of handling two product codes and any additional testing, then
we shouldn’t lose any customers. Regards Mike Dudek PMTS Standards &
Technology JDS Uniphase CO 80027 Tel 303 530 3189
x7533. mike.dudek@xxxxxxxx From: Let me re-state
one word of that message. From: Hi
Steve, Yes that helped a lot.
I hope the others on the list are not irritated by my request for repetition of
the data. Given the data, it
truly is a challenging issue. I see a 20% premium for a 17% increase in
coverage. This means the
confidence in the numbers is exceptionally important and assuming they are
accurate, a judgement call by the committee on whether or not a 17% increase in
port coverage justifies the 20% increase in cost. This is important
because if you increase the *COST* of a solution by 20%,
you may decrease the number of customers who are willing to buy it by more than
20%. Thus, in the overall mix, it might turn out to satisfy less customers
overall. Its a pretty
challenging judgement call IMHO. Thanks for providing
the data. Dan |