| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Piers, Thank you for pointing out that I left this aspect out of my response.
The motion forming the SG was: "Move the IEEE 802.3 Working Group requests
formation of a “Higher Speed Study Group” to evaluate definition of
greater than 10 Gb/s MAC data rate and related PHY capability to IEEE Std
802.3. The Study Group may recommend one or more PARs." Please note that there is no mention of doing anything with LAG. As
I noted in my previous response, we noted some of the issues with LAG, but did
not indicate anything that implied we would be looking at fixing LAG. This
is similar to a previous reflector conversation regarding the group looking at
jumbo frames. I think the way Geoff responded on that issue is appropriate
for this issue as well - "A decision to support an project that mandates
support of jumbo frames would, in my opinion, take the study group into a
quagmire. This would be an effort towards a goal that was not even mentioned in
the Call For Interest nor mentioned in the discussion leading up to the vote on
forming the Study Group. To go here would, I believe, be a betrayal of the
trust laid on the group by 802.3." I apologize for any confusion this omission may have
caused, and will strive to be precise in my communications. John -----Original Message----- John, You say: > CFI. I need to point out that was presented at the CFI was a
> single MAC > with aggregation at the physical layer. There was no mention
of > multiple MACs or fixing LAG, therefore any such objective would be
out > of scope. I disagree with your reasoning. The CFI slides shown on the
Tuesday are either your personal opinion or the personal opinion of the
presenter of the particular slides. They do not define not the scope of
the study group, which is defined by the actual motion taken by 802.3 on the
Thursday (and by 802.3's rules, and the division of territory between 802.3 and
802.1). Piers > -----Original Message----- > From: John DAmbrosia [mailto:jdambrosia@xxxxxxxxxxxxxxxxxxx] > Sent: 24 August 2006 20:47 > To: DAWE,PIERS > Cc: STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx; > Subject: RE: re LAGs just have an unfortunate statistical problem > designed in... > > > Piers, > I agree that information regarding LAG would be useful, as it
would be > helpful in the creation of an alternate aggregation scheme, > such as the > physical layer aggregation scheme. > > There has been a lot of talk regarding aggregation as a possible > solution. During discussions, people have been intermixing
Link > Aggregation, as specified in 802.3ad, with the aggregation at the > physical layer, i.e. below the single MAC, that was discussed in
the > CFI. I need to point out that was presented at the CFI was a
> single MAC > with aggregation at the physical layer. There was no mention
of > multiple MACs or fixing LAG, therefore any such objective would be
out > of scope. > > John > > > > > > -----Original Message----- > From: DAWE,PIERS [mailto:piers.dawe@xxxxxxxxxxxxx] > Sent: Thursday, August 24, 2006 11:00 AM > To: John DAmbrosia > Cc: STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx; > Subject: re LAGs just have an unfortunate statistical problem
designed > in... > > John, > > I hope you have someone lined up to give the study group a
teach-in on > what this problem is, what kinds of traffic it afflicts, what > alternatives are out there and how the 802.3 Cl.43 LAG with its > statistical problem might be fixed/avoided/substituted for. > > Thank you! > > Piers > > > -----Original Message----- > > From: > > Sent: 23 August 2006 23:58 > > To: STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx > > Subject: Re: [HSSG] Reliability or relative reliability
objective? > > > > > > Just to add my $.02, do people see 802.3ad LAGs as adding
additional > > "configurations" or creating interoperability
problems? I see it as > > adding nice scaling capabilities that in fact increase > > volumes and hence > > economies of scale. LAGs just have an unfortunate > statistical problem > > designed in... > > > > Drew > > _____________________________ > > > > > > Chief Technology Officer > > Infinera Corporation > > 1322 > > > > > > Phone: 408-572-5308 > > Cell: 408-666-1686 > > Fax: 408-904-4644 > > Email: dperkins@xxxxxxxxxxxx > > WWW : http://www.infinera.com > > > > > > _____________________________ > > > > > > -----Original Message----- > > From: > > Sent: Wednesday, August 23, 2006 2:57 PM > > To: STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx > > Subject: Re: [HSSG] Reliability or relative reliability
objective? > > > > Not to disagree too strongly with Piers... > > > > But... > > The more configurations we have, the less economy of scale
and > > guaranteed > > interoperability we have. > > > > Geoff > > > > > > At 12:17 PM 8/23/2006 , DAWE,PIERS wrote: > > >Also it allows a graceful growth plan, which gives the > whole project > > some > > >relevance. > > > > > >If you bought a new HSSG-compliant box with a big MAC,
you > could buy > > just > > >one XFP to let it talk to your old box with its 10G
ports. > > Later, you > > can > > >buy a wavelength mux and a second and third XFP...
Just > like the way > > DWDM > > >networks grow their capacity. You can buy the
second new > box before > > the > > >second XFP (use the new smarter lane bonding) or after
(use > > 802.3 Cl.43 > > > > >link aggregation or a proprietary alternative until you
buy > > the second > > box). > > > > > >Now if you knew you had most of 80 Gb/s of traffic on a > route today, > > you > > >could find someone who would sell you 8 lasers in a
box. It > > might not > > be > > >cheaper, but it would be more compact, which could make
it > > >worthwhile. (Or relatively worthwhile if the big
MAC were > expensive > > and > > >you would never have bought it without buying the second
box and at > > least > > >several lasers at each end.) > > > > > >I expect that over a portfolio of various sized routes,
the > > >pay-as-you-grow approach would be more cost-effective,
for most > > networks. > > > > > >This is not to say that purchasing lasers in groups, like
> 6-packs of > > beer, > > >is bad. But I think it's a mechanical partitioning
choice, not > > something > > >for 802.3 to require. > > > > > >I do not believe a proposed standard that REQUIRES the
big > > MAC and the > > >6-pack of lasers could have Broad Market Potential (which
I > > define as a > > > > >balance of market size to NRE so that the market would > > support several > > >vendors and several customers, up and down the food
chain). But a > > >proposed standard that allows the really untypical
"power users" to > > deploy > > >the big MAC and the 6-pack of lasers, but also offers > > something to the > > >wider market, may. > > > > > >Piers > > > > > > > -----Original Message----- > > > > From: Menachem Abraham
[mailto:mabraham@xxxxxxxxxxxxxxxxxxxx] > > > > Sent: 23 August 2006 19:10 > > > > To: STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx > > > > Subject: Re: [HSSG] Reliability or relative
reliability > objective? > > > > > > > > Jugnu, > > > > > > > > I agree that it has value in this context. > > > > > > > > Thanks, > > > > Menachem > > > > > > > > -----Original Message----- > > > > From: OJHA,JUGNU [mailto:jugnu.ojha@xxxxxxxxxxxxx] > > > > Sent: Wednesday, August 23, 2006 2:04 PM > > > > To: mabraham@xxxxxxxxxxxxxxxxxxxx; > > STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx > > > > Subject: RE: [HSSG] Reliability or relative
reliability > objective? > > > > > > > > Menachem, > > > > > > > > I think this is a very good reason to have a
graceful > > > > degradation mechanism > > > > - i.e., if one channel fails, continue to operate
over the > > > > others at reduced > > > > bit rate. This would come for free in a
scalable solution. > > > > > > > > Jugnu > > > > > > > > -----Original Message----- > > > > From: Menachem Abraham
[mailto:mabraham@xxxxxxxxxxxxxxxxxxxx] > > > > Sent: Tuesday, August 22, 2006 5:00 PM > > > > To: STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx > > > > Subject: [HSSG] Reliability or relative reliability
objective? > > > > > > > > All, > > > > > > > > Has IEEE 802 set reliability (MTBF) objectives in
any of the > > > > past projects? > > > > > > > > The multi-lane approach assumed in HSSG raises some
questions > > > > in this regard > > > > when compared to our tradition. > > > > > > > > When we went from 1G to 10G optical interfaces we
still had > > > > one laser, one > > > > PIN diode, one transimpedance receiver preamplifier
etc > etc. These > > > > components moved up in their cutoff frequencies but
the > > > > number of components > > > > was in the same order of magnitude and therefore
the MTBF and > > > > reliability > > > > was expected to be similar. > > > > > > > > In contrast, going from 10G to 100G by using 10 x
10G > > lanes implies > > a > > > > reduction in reliability by a factor of 10. > > > > > > > > This consideration combined with the cost concern
related to > > > > 10 x 10G lane > > > > approach (10 lasers, 10 PIN diodes etc) causes me
to > think that it > > is > > > > important to keep an open mind regarding the number
of lanes > > > > and the speed > > > > of each one of these lanes. > > > > > > > > Thanks, > > > > Menachem > > > > Menachem Abraham > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: " > > > > Date: Wed, 23 Aug 2006 00:01:45 > > > > To:<mabraham@xxxxxxxxxxxxxxxxxxxx>, > > > > <STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx> > > > > Subject: RE: [HSSG] Reach Objectives > > > > > > > > Menachem, > > > > > > > > > > > > > > > > I think we need to differentiate between what PMDs
we specify > > > > and what other > > > > PMDs we enable. For instance, I don't think it is
the > IEEE's place > > to > > > > specify an ULH PMD in terms of the optical
specifications. > > > > However, this > > > > could be one of the more important applications of
a HS > > > > Ethernet. So I think > > > > it would be worthwhile for us to enable vendors to > develop it in a > > > > straightforward fashion. Thus I think we should get
into some > > > > of the details > > > > that you mention including: > > > > > > > > 1. PHY layer - what degree of
compatibility with > > LAN-PHY, WAN-PHY > > > > (SONET/SDH), and/or G.709 is desired? > > > > > > > > 2. What amount of differential
delay (skew) will be > > > > allowed? What will be > > > > mandated for all conformant implementation? > > > > > > > > > > > > > > > > It is clearly desirable to maintain compatibility
with > > today's DWDM > > > > transponders. This is a specific goal of some
carriers that are > > > > participating in this process. Carriers would love
to have a > > > > PMD option that > > > > leverages the 10G LAN-PHY or WAN-PHY. Of course
this will > > > > depend on the > > > > answers to these questions and other decisions we
make. > > > > > > > > > > > > > > > > Many (I believe most) DWDM systems on the market
now support > > > > the LAN-PHY > > > > natively by simply speeding up the G.709 OUT to run
at > > > > ~11Gb/s instead of > > > > 10.7Gb/s rather than by doing some sort of overhead
> > compression into > > > > SONET/SDH or the G.709 digital wrapper. > > > > > > > > > > > > > > > > Drew > > > > > > > > _____________________________ > > > > > > > > > > > > > > > > > > > > > > > > Chief Technology Officer > > > > > > > > Infinera Corporation > > > > > > > > 1322 > > > > > > > > > > > > > > > > > > > > > > > > Phone: 408-572-5308 > > > > > > > > Cell: 408-666-1686 > > > > > > > > Fax:
408-904-4644 > > > > > > > > Email: dperkins@xxxxxxxxxxxx > > > > > > > > WWW : http://www.infinera.com > > > > > > > > > > > > > > > > > > > > > > > > _____________________________ > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Menachem Abraham
[mailto:mabraham@xxxxxxxxxxxxxxxxxxxx] > > > > Sent: Tuesday, August 22, 2006 5:00 PM > > > > To: STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx > > > > Subject: Re: [HSSG] Reach Objectives > > > > > > > > > > > > > > > > Geoff, > > > > > > > > > > > > > > > > Thanks for your comments. > > > > > > > > > > > > > > > > I also believe that our efforts should focus on
distances no > > > > higher than > > > > 10's of Km (up to and including metro). > > > > > > > > > > > > > > > > If we decide as a group that it is an objective to
make it > > > > easy to hook into > > > > LH and ULH transport systems in the installed base,
we will > > > > have to study a > > > > number of issues such as: > > > > > > > > > > > > > > > > (A) should we pick a data rate that is matching
SONET rates? > > > > > > > > (B) should we design our 802.3 std so that it
tolerates a much > > larger > > > > inter-lane differential delay than what would be
expected > > in a metro > > > > application of the standard? > > > > > > > > (C) should we assume we never go through existing
LH > > > > transponders and just > > > > have to COEXIST on the same fiber, optical
amplifiers, > dispersion > > > > compensators located in the huts, optical mux demux
at both ends > > etc. > > > > > > > > Etc. In this case we would assume a new type of LH
tranponder > > > > purpose built > > > > for HSSG applications. > > > > > > > > If this is the case, SONET rate compatibility would
not be > > important. > > > > > > > > > > > > > > > > > > > > > > > > Today's 10G LH and ULH system run mostly at OC-192
rates plus > > > > FEC overhead. > > > > Chip vendors were creative and managed to find ways
to build > > > > devices that > > > > pack into these solutions the full 10G LAN data
rate even > > > > though OC-192 is > > > > less than 10G. > > > > > > > > I think (but I may be wrong) that they use
available > bandwidth in > > the > > > > management bits available in Digital Wrapper or
something > > like that. > > > > > > > > Not clean but seems to work... > > > > > > > > > > > > > > > > Cheers, > > > > > > > > Menachem > > > > > > > > Menachem Abraham > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: " > > > > > > > > Date: Tue, 22 Aug 2006 16:09:11 > > > > > > > > To: > > > > > > > > Cc:STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx > > > > > > > > Subject: Re: [HSSG] Reach Objectives > > > > > > > > > > > > > > > > Menachem- > > > > > > > > > > > > > > > > Thanks for your much more specific answer to
the question. > > > > I'm afraid that > > > > my earlier answer was handicapped by my ignorance
of the > > > > specifics of that > > > > market. > > > > > > > > > > > > > > > > Based on what you said, I believe the
questions for us to > > > > consider or not > > > > are: > > > > > > > > > > > > > > > > a) Will we consider long haul solutions. > > > > > > > > OR > > > > > > > > b) Will we limit ourselves to metro solutions and
"transport > > > > end" (i.e. > > > > stuff that hooks into the transport infrastructure)
solutions. > > > > > > > > Back in the old days of 10Gig we spent an awful lot
of time > > > > discussing the > > > > need for the WAN PHY to address case
"b)". I think most of us > > > > didn't get it > > > > then. I would hope that with a different cast of
characters > > > > involved in the > > > > discussions that we (or at least I, for one) could
come out > > > > with a clear > > > > rationale for what we choose. > > > > > > > > > > > > > > > > (Just FYI, I believe the crux of the issue
came down to > > > > whether or not one > > > > could have a 2 port bridge, as opposed to an > > > > Optical-Electrical-Optical > > > > repeater in a Transport Chassis.) > > > > > > > > > > > > > > > > None the less, I believe that my proposed
answer stands. We > > > > don't need to > > > > tackle this issue in the first set of objectives
and projects. > > > > > > > > > > > > > > > > I do remain interested (old repeater hack
that I am) in > > > > looking into an > > > > O-E-O repeater that does not necessarily come all
the way > > > > back up to the > > > > level of reassembling the full packet. > > > > > > > > > > > > > > > > Geoff > > > > > > > > > > > > > > > > At 01:30 PM 8/22/2006 , Menachem Abraham
wrote: > > > > > > > > All, > > > > > > > > > > > > > > > > If we decide to include in our reach
objectives Long Haul > > > > (e.g. 1000 km > > > > with > > > > > > > > optical amps placed at 80 Km spacing) and
Ultra Long Haul > > > > (e.g. 3000 Km > > > > with > > > > > > > > optical amps at 80 Km spacing, without > Optical-Electrical-Optical > > > > > > > > regeneration), we need to keep in mind that > > > > modulation/encoding/FEC choices > > > > > > > > play an important role in how far we can go
on an optical > > > > amplifier based > > > > > > > > line system. Such PMD designs may be too
costly for our < 80Km > > > > > > > > applications/objectives so we may end up with
more PMDs. > > > > > > > > > > > > > > > > While there are some examples of Routers /
Switches which > > > > have LH or ULH > > > > > > > > optical interfaces built in, most systems use
Routers > / Switches > > with > > > > > > > > shorter reach interfaces connected to
separate Transport > > > > Chassis that house > > > > > > > > proprietary LH or ULH solutions. As far as I
know the LH and > > > > ULH world does > > > > > > > > not have interoperable standard solutions
today in terms of > > > > the signaling > > > > on > > > > > > > > the fiber. > > > > > > > > > > > > > > > > My input for our activities in HSSG is to
optimize for cost > > > > and not require > > > > > > > > that one of our PMDs be directly useable as
part of a LH or > > > > ULH line system > > > > > > > > (unless that is doable without incremental
cost). > > > > > > > > > > > > > > > > Having said that, I believe we should debate
the need to > > > > address "ease of > > > > > > > > HSSG data transport" on top of existing
and emerging LH and > > > > ULH transport > > > > > > > > systems. If this debate already happened as
part of the 10G > > > > 802.3 standard > > > > > > > > development and the conclusions apply here,
perhaps somebody > > > > can educate > > > > > > > > those of us who were not involved at that
time. > > > > > > > > > > > > > > > > Thanks, > > > > > > > > Menachem > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Aaron Dudek [mailto:adudek@xxxxxxxxxx: > > > > <mailto:adudek@xxxxxxxxxx> ] > > > > > > > > Sent: Tuesday, August 22, 2006 12:50 PM > > > > > > > > To: STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx > > > > > > > > Subject: Re: [HSSG] Reach Objectives > > > > > > > > > > > > > > > > Geoff, > > > > > > > > Shouldn't the migration to ULH systems have
any impact on > > > > the spacing > > > > > > > > and hence be taken into consideration? Or is
that beyond the > > > > scope for > > > > > > > > now? > > > > > > > > > > > > > > > > Aaron Dudek > > > > > > > > (703) 689-6879 > > > > > > > > Sprintlink Engineering > > > > > > > > adudek@xxxxxxxxxx > > > > > > > > > > > > > > > > > > > > > > > > On Tue, 22 Aug 2006, > > > > > > > > > > > > > > > > > Roger- > > > > > > > > > > > > > > > > > > At 03:47 AM 8/22/2006 , > > > > > > > > > > > > > > > > > >
Agree with Drew. Have a few additional comments on > > > > other reachs: > > > > > > > > > > > > > > > > > > For
reach objectives, we should start with customer > > > > based needs > > > > (for > > > > > > > > broad market potential) and only amend if an > > > > > > > > >
obvious technical limitation with compelling > > economics can > > t > > > > readily > > > > > > > > meet the broad customer need. > > > > > > > > > > > > > > > > > >
Specifically: > > > > > > > > > > > > > > > > > > -
Long Reach probably should be set at 80km rather > > > > than 100km (as > > > > > > > > this is the common hut-to-hut amplifier
spacing > > > > > > > > > in
telecom) > > > > > > > > > > > > > > > > > > -
While 50m does serve a useful portion of the > > > > market (smaller > > > > > > > > datacenters and/or the size of a large
computer > > > > > > > > >
cluster), it is somewhat constraining as I ve > > been lead to > > > > > > > > understand that the reach needed in larger
datacenters > > > > > > > > > is
continuing to out-grow the 100m meter definition > > > > but the 100m > > > > > > > > definition at least serves the customer well. > > > > > > > > >
Certainly 10G-BaseT worked awfully hard to get > > to 100m (for > > > > > > > > Datacenter interconnect). > > > > > > > > > > > > > > > > > > > > > > > > > > > I wouldn't attach a lot of creedence to
the > 10GBASE-T goal for > > 100 > > > > meters. > > > > > > > > It was, I believe, mainly driven by the > > > > > > > > > traditional distance in horizontal (i.e.
wiring closet to > > desktop) > > > > > > > > distances rather than any thorough
examination of data > > > > > > > > > center requirements. > > > > > > > > > > > > > > > > > > Geoff > > > > > > > > > > > > > > > > > > > > > > > > > > > -
For both in-building reaches (50m & 300m; or 100m > > > > & 300m), the > > > > > > > > bigger issue which affects the PMD is the
loss > > > > > > > > >
budget arising from the number of patch panels. The > > > > shorter / > > > > > > > > datacenter reach should include a budget for
1 > > > > > > > > >
patch panel. The longer / enterprise reach should > > > > include a budget > > > > > > > > for 2 patch panels (one in the datacenter and > > > > > > > > > 1 in
the remote switch closet). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
From: > > > > <mailto:dperkins@xxxxxxxxxxxx> ] > > > > > > > > >
Sent: Tuesday, August 22, 2006 1:24 AM > > > > > > > > > To:
STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx > > > > > > > > >
Subject: Re: [HSSG] Reach Objectives > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
John, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I
suggest dividing Metro into Metro Short > Reach at 10 km > > > > (equivalent > > > > > > > > application to 10GBASE-LR) and Metro > > > > > > > > >
Intermediate Reach at 40 km (equivalent application > > > > to 10GBASE-ER). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Drew > > > > > > > > > > > > > > > > > >
_____________________________ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
Chief Technology Officer > > > > > > > > > > > > > > > > > >
Infinera Corporation > > > > > > > > > > > > > > > > > > 1322
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
Phone: 408-572-5308 > > > > > > > > > > > > > > > > > >
Cell: 408-666-1686 > > > > > > > > > > > > > > > > > > Fax:
408-904-4644 > > > > > > > > > > > > > > > > > >
Email: dperkins@xxxxxxxxxxxx > > > > > > > > > > > > > > > > > > WWW
: http://www.infinera.com: > > <http://www.infinera.com/> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
_____________________________ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
______________________________________________________________ > > > > _____________ > > > > _ > > > > > > > >
________________________________________________________ > > > > > > > > >
From: John DAmbrosia > > [mailto:jdambrosia@xxxxxxxxxxxxxxxxxxx: > > > > <mailto:jdambrosia@xxxxxxxxxxxxxxxxxxx> ] > > > > > > > > >
Sent: Monday, August 21, 2006 9:38 PM > > > > > > > > > To:
STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx > > > > > > > > >
Subject: [HSSG] Reach Objectives > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > All, > > > > > > > > > > > > > > > > > > We
have had some conversation on the reflector > > > > regarding reach > > > > > > > > objectives. Summarizing what has been
discussed > > > > > > > > > on
the reflector I see the following > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
Reach Objectives > > > > > > > > > > > > > > > > > >
Long-Haul --> 100+ km > > > > > > > > > > > > > > > > > >
Metro --> 10+ km > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
Intra-rack > > > > > > > > > > > > > > > > > >
Inter-rack > > > > > > > > > > > > > > > > > >
Horizontal runs > > > > > > > > > > > > > > > > > >
Vertical risers > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Use
this data to identify a single low-cost solution > > > > that would > > > > > > > > address a couple of the reach objectives > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
Other Areas > > > > > > > > > > > > > > > > > >
During the course of the CFI there were individuals > > > > who wanted > > > > > > > > Backplane Applications kept in for
consideration, > > > > > > > > > but
I have not heard any further input in this area. > > > > Are there > > > > > > > > still individuals who wish to propose
Backplane > > > > > > > > > as
an objective? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > John > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > |