Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [HSSG] re LAGs just have an unfortunate statistical problem designed in...

Piers-

It is really pretty simple.
We completely punted on addressing the distribution load balancing problem when we developed LAG on the theory that: The proprietary mechanisms generally had to: Thus owners of VLANs were offended and encrypted traffic was resistant to the peeking.

And, lastly, with LAG your minimum granularity is a complete frame

I hope this helps.

Geoff

At 07:59 AM 8/24/2006 , DAWE,PIERS wrote:
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: Drew Perkins [mailto:dperkins@xxxxxxxxxxxx]
> 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
> _____________________________
> 
> Drew Perkins
> Chief Technology Officer
> Infinera Corporation
> 1322 Bordeaux Drive
> Sunnyvale, CA  94089
> 
> Phone:  408-572-5308
> Cell:       408-666-1686
> Fax:        408-904-4644
> Email:    dperkins@xxxxxxxxxxxx
> WWW :  http://www.infinera.com
> 
>
> _____________________________
> 
>
> -----Original Message-----
> From: Geoff Thompson [mailto:gthompso@xxxxxxxxxx]
> 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
> > > Columbus Advisors
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: "Drew Perkins" <dperkins@xxxxxxxxxxxx>
> > > 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
> > >
> > > _____________________________
> > >
> > >
> > >
> > > Drew Perkins
> > >
> > > Chief Technology Officer
> > >
> > > Infinera Corporation
> > >
> > > 1322 Bordeaux Drive
> > >
> > > Sunnyvale, CA  94089
> > >
> > >
> > >
> > > 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
> > >
> > > Columbus Advisors
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > -----Original Message-----
> > >
> > > From: "Geoff Thompson" <gthompso@xxxxxxxxxx>
> > >
> > > Date: Tue, 22 Aug 2006 16:09:11
> > >
> > > To:mabraham@xxxxxxxxxxxxxxxxxxxx
> > >
> > > 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, Geoff Thompson wrote:
> > >
> > >
> > >
> > >  > Roger-
> > >
> > >  >
> > >
> > >  > At 03:47 AM 8/22/2006 , Roger Merel wrote:
> > >
> > >  >
> > >
> > >  >       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: Drew Perkins [mailto:dperkins@xxxxxxxxxxxx:
> > > <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
> > >
> > >  >
> > >
> > >  >       _____________________________
> > >
> > >  >
> > >
> > >  >
> > >
> > >  >
> > >
> > >  >       Drew Perkins
> > >
> > >  >
> > >
> > >  >       Chief Technology Officer
> > >
> > >  >
> > >
> > >  >       Infinera Corporation
> > >
> > >  >
> > >
> > >  >       1322 Bordeaux Drive
> > >
> > >  >
> > >
> > >  >       Sunnyvale, CA  94089
> > >
> > >  >
> > >
> > >  >
> > >
> > >  >
> > >
> > >  >       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
> > >
> > >  >
> > >
> > >  >       Data Center --> 50m & 300m
> > >
> > >  >
> > >
> > >  >
> > >
> > >  >
> > >
> > >  >       Data Center Reach Segregation
> > >
> > >  >
> > >
> > >  >       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
> > >
> > >  >
> > >
> > >  >
> > >
> > >  >
> > >
> > >  >
> > >
> > >  >
> > >
> > >
>