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

Curtis Villamizar <curtis@occnc.com> Sat, 23 March 2013 16:24 UTC

Return-Path: <curtis@occnc.com>
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 4512D21F8867 for <rtgwg@ietfa.amsl.com>; Sat, 23 Mar 2013 09:24:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.445
X-Spam-Level:
X-Spam-Status: No, score=-0.445 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
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 ngTlDbTPJK6j for <rtgwg@ietfa.amsl.com>; Sat, 23 Mar 2013 09:24:58 -0700 (PDT)
Received: from gateway1.orleans.occnc.com (unknown [173.9.106.132]) by ietfa.amsl.com (Postfix) with ESMTP id AA53F21F884A for <rtgwg@ietf.org>; Sat, 23 Mar 2013 09:24:58 -0700 (PDT)
Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id r2NGNgpt046392; Sat, 23 Mar 2013 12:23:42 -0400 (EDT) (envelope-from curtis@occnc.com)
Message-Id: <201303231623.r2NGNgpt046392@gateway1.orleans.occnc.com>
To: Russ White <russw@riw.us>
From: Curtis Villamizar <curtis@occnc.com>
Subject: Re: FW: I-D Action: draft-retana-rtgwg-eacp-01.txt
In-reply-to: Your message of "Sat, 23 Mar 2013 10:37:23 EDT." <514DBE23.4040108@riw.us>
Date: Sat, 23 Mar 2013 12:23:42 -0400
Cc: rtgwg@ietf.org
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: curtis@occnc.com
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 16:24:59 -0000

In message <514DBE23.4040108@riw.us>
Russ White writes:
 
>  
> > So before anyone writes any more problem statements, requirements,
> > frameworks, or complete solutions for energy aware networks, we need
> > to have some research and some hard facts about where energy goes and
> > where there are opportunities to save energy.  We also should be
> > asking whether providers and high end network equipment vendors see a
> > need for any protocol work in this area.  So far the answer is a
> > resounding "no".
>  
> I actually disagree...
>  
> The point of this draft is to guide the research into what would make
> sense and what wouldn't, not to make a definitive statement. I
> understand the perspective that, "if it doesn't save x amount of power,
> it's not worth doing..."
>  
> But technology changes, after all, and in just a few short years the
> answer to that question might well change. So, if we come to the point
> where the answer changes, how have we defined the question?
>  
> This draft is about defining the questions that need to be asked, not
> about doing work in answering those questions.
>  
> Different topic, IMHO.
>  
> :-)
>  
> Russ


Russ,

If our starting point is total cluelessness, then defining a taxonomy
of the solution space would be very counterproductive.

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.

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.

Curtis