Re: FW: I-D Action: draft-retana-rtgwg-eacp-01.txt

Russ White <russw@riw.us> Sat, 23 March 2013 17:44 UTC

Return-Path: <russw@riw.us>
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61E0E21F888B for <rtgwg@ietfa.amsl.com>; Sat, 23 Mar 2013 10:44:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HWSqBRx3B9Cq for <rtgwg@ietfa.amsl.com>; Sat, 23 Mar 2013 10:44:51 -0700 (PDT)
Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id B176A21F8867 for <rtgwg@ietf.org>; Sat, 23 Mar 2013 10:44:51 -0700 (PDT)
Received: from cpe-098-122-147-095.nc.res.rr.com ([98.122.147.95] helo=[192.168.100.75]) by da31.namelessnet.net with esmtpa (Exim 4.80) (envelope-from <russw@riw.us>) id 1UJSUs-0006Mp-S8; Sat, 23 Mar 2013 10:44:50 -0700
Message-ID: <514DEA1E.2090008@riw.us>
Date: Sat, 23 Mar 2013 13:45:02 -0400
From: Russ White <russw@riw.us>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: curtis@occnc.com
Subject: Re: FW: I-D Action: draft-retana-rtgwg-eacp-01.txt
References: <201303231623.r2NGNgpt046392@gateway1.orleans.occnc.com>
In-Reply-To: <201303231623.r2NGNgpt046392@gateway1.orleans.occnc.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Antivirus-Scanner: Seems clean. You should still use an Antivirus Scanner
Cc: rtgwg@ietf.org
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Area Working Group <rtgwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtgwg>
List-Post: <mailto:rtgwg@ietf.org>
List-Help: <mailto:rtgwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 23 Mar 2013 17:44:52 -0000

> Stretch and microsleeps are solution space and I'd argue that the best
> solutions for core may involve neither.  There is no highly credible
> evidence that either has an impact on core network energy usage and
> IMO stronger arguments that it would have no effect or infeasible
> (microsleeping finely tuned temperature compensated colored lasers?)
> than the the very weak arguments (mostly speculation) that there is
> benefits to these two approaches for core.

No, stretch and sleep states are not "in the solution space." If you're
going to save energy by using sleep states, then you need to deal with
state. These are bars any given design must overcome, not suggestions
for a design that would work.

> So the research happen where it belongs - elsewhere.  Then when there
> is credible research presented, it might be time to consider a
> taxonomy of the problem and solution space in an SDO.

So your basic argument is --"we should only consider this when it's
proven to be economically viable." My counter to that is simple:

There's more to this game than saving more than x$/year. There's also
the impact on the control plane to consider as a "cost."

This draft is an attempt to at least point those costs out in a
reasonable and understandable way. In other words, it's trying to get
all the requirements on the table, rather than focusing myopically on
the economic costs.

Again, it's answering a completely different question than you're asking.

Russ