RE: [EFM] Moving forward on extended temperature range optics
Piers,
An extended temperature option is a requirement. We said we would do it. We voted to do it. We need to do it.
It is absurd to suggest that all EFM equipment (even outside the North America) will be placed in environmentally controlled enclosures (including buildings). Were this true, DLCs would not require hardened DSLAMs. But, they do. And, this is the same infrastructure that a significant portion of the EFM solution will occupy.
Beyond that, see below.
jonathan
| -----Original Message-----
| From: piers_dawe@xxxxxxxxxxx [mailto:piers_dawe@xxxxxxxxxxx]
| Sent: Thursday, January 23, 2003 6:55 AM
| To: btolley@xxxxxxxxx; Richard.Michalowski@xxxxxxxxxxxxxxx;
| Brian.Ford@xxxxxxxxxxxxx
| Cc: stds-802-3-efm@ieee.org
| Subject: RE: [EFM] Moving forward on extended temperature range optics
|
|
|
| Bruce, Brian and Richard,
|
| I'd like to point out where this chain of thought goes wrong,
| especially as the logical disconnects have been repeated
| later in the thread. See below:
|
| > -----Original Message-----
| > From: Bruce Tolley [mailto:btolley@xxxxxxxxx]
| > Sent: 16 January 2003 19:59
| > To: piers_dawe@agilent.com; stds-802-3-efm@ieee.org
| > Subject: [EFM] Moving forward on extended temperature range optics
| >
| > Piers and all
| >
| > I gave my self the action to help move forward the
| outstanding issue
| > regarding extended temperature ranges for P2P and P2MP optics
| >
| > We have an objective to include in our specification of PHYs,
| > support for
| > extended temperature range optics
|
| Yes. Support, not mandatory requirement.
Yes. But, it is mandatory that the option be technically feasible; economically feasible; and interoperable. The option must be specified, just as all other 802.3 options are specified.
|
| > The task force has in the past passed motions to specify EFM
| > optics at -40
| > to +85 C
|
| To specify the optics, not the temperature. This is very
| clear from the January and March 2002 motions. See e.g. the
| March Joiner motion "The basis for the first draft of the
| 802.3ah 1000Base-LX extended temperature objective be met
| with text that uses 1000Base-LX 5 km single mode
| specification (clause 38) as the starting point with the
| following changes and additions:
| - Informative temperature range -40-+ 85 deg C
| etc
|
| and
|
| January Motion #11
| Motion: to create informative annex to address environmental
| considerations.
| Mover: Chris DiMinico
| Second: Alan Flatman
|
| > Network operators have on multiple occasions communicated the
| > requirement
| > for extended temperature solutions.
|
| This is where the logic really falls apart.
|
| First, is it not just a small subset of network operators (US
| ones) who aren't installing much FTTB. Other network
| operators may have different physical strategies, climates,
| and requirements.
|
Is your point that we should have an entire selection of extended temperature options because one size doesn't fit all? Fine. Let's do it. But, I, for one, do not require this.
| Second, network operators need many things; working capital,
| fire safety, an electricity supply... It does not follow
| that 802.3 is bound to provide any of them. Environmental
| requirements such as these are out of scope of this standard
| - that's why temperature is to be addressed in an informative annex.
|
And which of these directly and unavoidably impacts the optical specifications? Fire safety? No. Electrical supply? No. Temperature? Yes.
| Of course, customers will impose environmental requirements
| in their procurement specs - and Telcordia specs for example
| are effectively, procurement specs.
Absolutely, yes. These will include storage temperature, form factor, etc. Again, which of these will directly affect the optical performance?
|
| > As recently as the Vancouver meeting, several box vendors
| > (including me)b
| > communicated the requirement for extended temperature range
| > optics.
|
| Same lack of connected logic. Someone's need doesn't mean
| that 802.3 is bound to supply. Temperature specs are
| available in the market from other sources, who have more
| expertise in the matter.
|
Lack of connected logic? I think not.
When someone's need impacts broad market potential, it absolutely does mean 802.3 must take this into consideration. We have a process to deal with this. I wrote a TR. If everyone disagrees with it, then I am left a lone voice in the wilderness. But, if I am not alone....
The existing TR has nothing to do with the availability of temperature specifications. But, as I said in Vancouver, once we do what we said and voted to do, then it will be possible to write a TR regarding the technical feasibility of our specifications. But, this won't have anything to do with the availability of temperature specifications either. Who cares how many temperature specs there are and from where they come? The box vendor that I work for would like to be able to purchase compliant parts, not compliant specs.
Ultimately, what we care about is that PMDs meeting EFM optical specifications over the specified temperature range(s) are "technically and economically feasible" and can be sourced from "multiple vendors."
If this cannot be accomplished, then we must, simply, change the specifications so that it can.
That is the target. Lest we forget.
| Piers
|
| > We need
| > to agree on a path to move forward.
| >
| > So if interested parties want to forward to me their email
| > addresses, I
| > will host a conference call next week dedicated to this
| > issue. I think we
| > need to focus on a test specified in each PMD clause, to
| agree on the
| > ranges for OLT and ONU optics, to consider the possible
| > special case of
| > bidis that include 1550 nm DFBs, and to identify any PMD that
| > might only
| > need to be supported at standard, commercial temperatures.
| >
| > thanks
| >
| > Bruce Tolley
| > Cisco Systems
| >
| > At 04:11 PM 1/8/2003 +0100, piers_dawe@xxxxxxxxxxx wrote:
| >
| > >G.983.3 refers to ETS 300 019. This is a very readable series of
| > >documents from the European Telecommunications Standards
| > Institute, giving
| > >a classification of environmental conditions, e.g.
| weatherprotected
| > >locations, non-weatherprotected, underground. It uses four
| > classes of
| > >climatic conditions:
| > > "applies to most of Europe"
| > > extended
| > > extremely cold
| > > extremely warm dry
| > >
| > >And even better, up-to-date drafts are available on the
| web, e.g. at
| > >http://webapp.etsi.org/action%5COP/OP20030321/en_3000190104v0
| 20101o.pdf .
| >
| >It is not the business of 802 to pick between these classes
| but we can
| >refer the readers of our standard to this information.
| >
| >ITU-T and ANSI T1 do not have similar documents.
| >
| >Both G.983.3 and refer to IEC 60721, classification of environmental
| >conditions.
| >
| >IEC 60721-3-4 - Ed. 2.0 Classification of environmental
| conditions - Part
| >3: Classification of groups of environmental parameters and their
| >severities - Section 4: Stationary use at non-weatherprotected
| >locations 1995-01 is available for CHF99 at
| >https://domino.iec.ch/webstore/webstore.nsf/artnum/019208 .
| >
| >Piers
|
|
| Bruce Tolley
| Senior Manager, Emerging Technologies
| Gigabit Systems Business Unit
| Cisco Systems
| 170 West Tasman Drive
| MS SJ H2
| San Jose, CA 95134-1706
| internet: btolley@xxxxxxxxx
| ip phone: 408-526-4534
|
|