In message <CAHF4apMcWCY0oKo9PYWwP4iAp=rlh-7wbfdp2ubbmdbgdye...@mail.gmail.com> Balaji venkat Venkataswami writes: > Dear Curtis, > > Comments inline.... <balajivenkat> > > On Fri, Feb 8, 2013 at 3:27 AM, Curtis Villamizar <[email protected]> wrote: > > > > > In message < > > cahf4apogl40a3owkjznvoafn7u6cl06vt0ru8vruniwpuh9...@mail.gmail.com> > > Balaji venkat Venkataswami writes: > > > > > Dear Eric, > > > > > > Please take a look at the tcam-efficiency draft that we have published. > > > > > > The URL to the draft is > > > http://tools.ietf.org/html/draft-mjsraman-panet-tcam-power-efficiency-00 > > > > > > A follow up draft that defines TCAM efficiency in terms of a metric is > > > also outlined in... > > > > > > http://tools.ietf.org/html/draft-mjsraman-panet-tcam-power-ratio-02 > > > > > > With the help of the above schemes and additional work that is in > > > progress we intend to reduce the power footprint of a > > > device/router/switch/chassis such that important power guzzling > > > components of the router are optimized. > > > > > > In summary, the above 2 drafts coupled with the protocol schemes will > > > we feel result in better power saving than what we have today. So > > > essentially optimizing the power consumed within a device coupled with > > > using protocol schemes between devices will result in saving power. > > > > > > Hope this helps. > > > > > > thanks and regards, > > > balaji venkat > > > > > > balaji, > > > > This is in the realm of router design. > > > > <balajivenkat> Most modern commercial chipsets provide the capability > of switching off TCAM banks. TCAMs nowadays come in the form factor > of multiple banks that can be switched off and switched on with > register operations. I wouldnt say that this is uncommon. This > algorithm we suggest falls within the realm of software design where > the software is responsible for managing multiple TCAM banks of > suitable granularity. Its because such chips are available that these > algorithms are feasible today.
You seemed to have missed the point. TCAMs are power hungry. External TCAMs use power in the logic that runs in parallel, and in the SERDES to go off-chip on both sides. Getting rid of the external TCAM reduces SERDES power to zero. Using an alternate to TCAM eliminates that power hungry peice of logic. > > You are suggesting a TCAM in which banks can be shut off by reducing > > the number of destination addresses in the FIB. > > > > A better solution to reduce the power consumed by TCAM is don't use a > > TCAM. It is fast, but a radix trie based approach or other tree > > > > <balajivenkat> Most vendors and commercial chipsets manufactured use > TCAMs for the Longest prefix match lookup. Fast is good so TCAMs are > in widespread use. Quick fix, but power hungry. That is why some designs are now revisiting the idea of external TCAM. > Radix trees too could be used. But then again we could optimize the > SRAM they use by applying similar approaches to reducing the radix > tree to hold only routes that are in use. So it is the general > philosophy that is of importance and does not hinge on usage of TCAMs > in routers. The active power of a large SRAM is a small fraction of the active power of a large TCAM. For a large SRAM, the active power is so low that the leakage power becomes more significant. That leakage power is constant whether the SRAM is active or not. If the SRAM is being used for route lookup. the small active power comes into play. External TCAM was an easier solution back in the 130nm days and probably up to about the 65nm or 40nm days because, at least back in the 130 nm days, putting the forwarding lookup on chip was unthinkable. There has been a lot of work in higher radix lookups to reduce the number of pipeline stages, or the amount of parallelism needed, and these simply use a small number of low active power SRAM lookups rather than one power hungry TCAM lookup. If only IGP routes and MPLS LSP are present, then the small IGP lookup on a small subset of traffic (however it is done), and the MPLS ILM lookup (a single SRAM lookup) would yield lower power. Even keeping the power hungry external TCAM but providing a separate SRAM for ILM would be a means to lower the power needed for route lookup. > > approach consumes less power and pipelining makes such an approach > > feasible if the lookup memory can be kept on-chip. MPLS lookup can be > > easily done in on chip SRAM rather than TCAM consuming mush less power > > than an on-chip TCAM and a fraction of the power of off chip TCAM due > > to the SERDES power needed to go off chip. > > > > This pair of drafts in particular should be dropped. > > > > Hence we think this work is of importance in the current context. > This is currently work in progress. I disagree for reasons cited above. You are free to continue to design your routers with TCAM if you prefer. Even if this work had merit, which I do not think it does, IETF has never written standards covering ASIC design techniques and forwarding hardware design and there is currently no plans to do so. > thanks and regards, > balaji venkat Curtis > > Curtis > > > > > > > On Thu, Feb 7, 2013 at 9:38 PM, Eric Osborne (eosborne) > > > <[email protected]>wrote: > > > > > > > [size trimmed] > > > > > > > > OK, so you want to avoid nodes which draw more power. > > > > Are you assuming that minimizing the traffic across a node also > > minimizes > > > > the power that node draws? > > > > > > > > If yes: > > > > - please provide concrete examples of how this actually works. In my > > > > experience the power draw by a router or switch is pretty constant, > > more > > > > driven by the *existence* of links (because links -> linecards -> power > > > > draw) than by the *traffic* on those links. > > > > > > > > If not, what do you hope to accomplish by avoiding higher-power nodes? > > > > > > > > > > > > > > > > > > > > eric > > > > > > > > > -----Original Message----- > > > > > From: Balaji venkat Venkataswami [mailto:[email protected]] > > > > > Sent: Thursday, February 07, 2013 10:59 AM > > > > > To: Eric Osborne (eosborne) > > > > > Cc: Shankar Raman; [email protected]; [email protected] > > > > > Subject: Re: Power aware networks : Comments requested from routing > > > > > community > > > > > > > > > > Dear Eric, > > > > > > > > > > We seem to be discussing at cross purposes. > > > > > > > > > > The root of our position is not what you have stated. We do not say > > if > > > > you dont > > > > > use a link you consume less power. We are not for avoiding links but > > we > > > > are for > > > > > avoiding nodes/routers/switches which have a large power footprint. > > The > > > > > essence of using link metrics is to avoid nodes with larger power > > > > footprints. > > > > > That is how SPF or CSPF works. When it computes a low power path it > > > > avoids > > > > > nodes and also links that lead to that node which has a larger power > > > > footprint. > > > > > So the premise that we are just avoiding links is WRONG. > > > > > > > > > > For #1 question, we dont even talk about the power the link draws. We > > > > talk > > > > > about the power footprint of the node that it is connected to. > > > > > > > > > > For #2 question, again we state that your premise of avoiding links > > in > > > > your > > > > > example is a non-starter for us. > > > > > > > > > > thanks and regards, > > > > > balaji venkat _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
