I too think this is a research area.  

I will comment on the metric though. Path computation on multiple metrics is 
hard so we usually minimize one metric subject to a set of constraints.  Is a 
power metric a primary minimization metric? I would bet if you asked providers 
the answer is no. So it would be compute a minimum path based on Bandwidth or 
delay subject to a set of equipment that qualifies as "green".  Or prefer green 
links if possible. 

How do you determine Green links?
The PWR metric proposed has two items: Power per XGIG and Available Utilization 
(draft-mjsraman-panet-ospf-power-topo-00)

I'd argue that Power per XGIG has to be measured and verified on an equal scale 
across vendors (so it is unlikely to be populated by vendors in any easily 
agreed manner ;-) ) and it is related to utilization (Higher utilization = more 
power/bit).
So if you divide by available utilization, the goal of the metric seems to be 
to produce an average power per XGIG. 
So the metric is roughly a constant per port.

Comparing all the link metrics in the network some set would qualify as green,  
others perhaps yellow or red. 

So an easy way to get 90% of the value of this is Measure your equipment. Color 
the best ports Green (using some threshold), and have a path computation that 
prefers green links all other things being equal. 

This puts the onus on Operators to measure power and color links 
(administrative group (color) exists) and requires a path computation that can 
prefer green. A requirement that is softer than must be green.

Just saying..
Don 


-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of 
Mingui Zhang
Sent: Friday, February 08, 2013 4:33 AM
To: Hannes Gredler
Cc: Shankar Raman M J; [email protected]
Subject: RE: Power aware networks : Comments requested from routing community

Hannes,

That's the dream of line-card hardware manufactures. If the hardware is 100% 
power proportional, then PANET will become useless.

However, the practice is that only 10%-15% power proportional is possible, 
which means a high 85%-90% of baseline power is being wasted when there is few 
traffic.

Thanks,
Mingui

>-----Original Message-----
>From: Hannes Gredler [mailto:[email protected]]
>Sent: Friday, February 08, 2013 5:17 PM
>To: Mingui Zhang
>Cc: Tony Li; Shankar Raman M J; [email protected]
>Subject: Re: Power aware networks : Comments requested from routing 
>community
>
>mingui,
>
>wouldn't designing the hardware architecture such that there is no high 
>baseline rather than a more demand based power draw curve be the better 
>alternative then ?
>
>only box local changes needed, immediate returns, no need to bother the 
>network with the fact that the local box cannot do the power 
>housekeeping well ?
>
>/hannes
>
>On Feb 8, 2013, at 9:53 AM, Mingui Zhang wrote:
>
>> Hi Hannes,
>>
>> "Optimization" tries to empty all links on one line-card with 
>> priority, then this
>line card can be shut off to save the high baseline power.
>>
>> Thanks,
>> Mingui Zhang
>> Huawei Technologies
>>
>>> -----Original Message-----
>>> From: [email protected] [mailto:[email protected]] On 
>>> Behalf
>Of
>>> Hannes Gredler
>>> Sent: Friday, February 08, 2013 4:25 PM
>>> To: Tony Li
>>> Cc: Shankar Raman M J; [email protected]
>>> Subject: Re: Power aware networks : Comments requested from routing 
>>> community
>>>
>>> tony,
>>>
>>> agree that saving power is a worthwhile goal;
>>>
>>> in fact existing hardware technology is making that happen today by 
>>> e.g. automatically shutting down unused lookup engines, CPU cores, 
>>> memory banks etc.
>>> when there is low processing demand.
>>>
>>> the part where i am not yet convinced is that additional off-peak
>"optimization"
>>> of
>>> infrastructure links by e.g. computing a routing mesh which only 
>>> uses 70% of the nominal links does actually give much power savings.
>>>
>>> note that line cards which are running at 70% have already throttled 
>>> down
>their
>>> power consumption - so what is the point emptying the link and 
>>> loading another ?
>>> appears to me a zero sum game.
>>>
>>> my concern about the core (and SP edge) is not about business or 
>>> technology
>-
>>> it is more about if we try to optimize an already optimized (and 
>>> solved)
>problem.
>>>
>>> /hannes
>>>
>>> On Feb 7, 2013, at 5:09 PM, Tony Li wrote:
>>>
>>>>
>>>> On Feb 7, 2013, at 5:07 AM, Hannes Gredler <[email protected]> wrote:
>>>>
>>>>> Do you think that optimizing a part of the network which gives 
>>>>> only limited overall savings is a worthwhile goal ?
>>>>
>>>>
>>>> Hannes,
>>>>
>>>> I'll just point out that this argument that you and Eric are 
>>>> espousing is
>skirting
>>> dangerously close to the quagmire of business.  And we know from 
>>> long experience that the IETF does not do business models.
>>>>
>>>> I'd like to strongly suggest that we simply restrict ourselves to 
>>>> the goal of
>>> saving power.  I think that we can agree, in general, that saving 
>>> power is a worthwhile goal.  As to whether or not it is significant 
>>> or makes economic sense is very much an issue that should be left to 
>>> the operator community to decide.  Limited overall savings may be 
>>> worthwhile in one context and
>pointless
>>> in another.
>>>>
>>>> I know of one country where they are purportedly mandating power
>reductions.
>>> In such situations, saving that last watt is the difference between 
>>> a fine and
>not.
>>> On the other hand, in a situation where power is very cheap, it's 
>>> obviously
>silly.
>>>>
>>>> Let's not argue about the marginal value of energy.  That's a 
>>>> business
>model
>>> issue.  Let's talk about how technology can actually save power.
>>>>
>>>> Regards,
>>>> Tony
>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> rtgwg mailing list
>>> [email protected]
>>> https://www.ietf.org/mailman/listinfo/rtgwg
>>
>

_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg

Reply via email to