Subject: [irtf-discuss] Request for a side-bar meeting in the IETF Orlando on Power-Aware Networking drafts

From: Balaji venkat Venkataswami <[email-masked]>
Date: Wed, 6 Feb 2013 12:27:44 +0530

Dear Lars, all,

We would like a side-bar meeting (in an adjacent room) to discuss the
following Power-Aware-Networking proposals.
A detailed outline of the drafts submitted have been detailed below. We
would like a 20 minute slot with 10 minutes for Q&A if possible.
We would however concur with whatever time you give us on this matter.

We are a group of research and industry individuals tied together with a
common goal towards reducing the energy consumption in the core and edge
networks.

We present a metric-based hierarchical approach to reduce power consumption
in core and edge networks. The proposal considers both unicast and the
multicast cases. For unicast, the metric considered is *consumed-power to
available-bandwidth* and for multicast the metric is *consumed-power to
available-replication-capacity.*

 With unicast, the metric is used to determine a low-power path between
sources and destinations. With multicast, the metric serves the twin
purpose of finding low-power multicast paths as well as multicast
replication points.  We evolve multiple techniques at various hierarchical
levels. One at the Inter-AS level, Inter-Area level within the AS and
intra-Area within an AS. Additionally, the proposed method can also be used
to determine disjoint or redundant paths for load balancing or fault
tolerance. Additionally since TCAMs are one of the biggest power guzzlers
in all the components on a router/switch, we have presented a solution for
intra-AS purposes to use the TCAM according to the traffic matrix passing
through the system and shut down those TCAM banks that are unused. With
this in mind, we have also advocated taking into account a TCAM-POWER-Ratio
in order to compute the paths from source to destination based on this
metric. Once low-power paths, in either the unicast or the multicast cases,
are identified then currently available traffic engineering techniques
could be used to route the data packets. In the case of inter-AS BGP path
selection is also modified to arrive at paths which are low-power paths.

 Our main objective is as follows...

We now outline four important aspects that any approach for power reduction
should be capable of addressing.

 *Should cater for both unicast and multicast scenarios*

Multicast provides an important scenario for the Internet. Today, most
proposals consider mainly low-power path routing with unicast traffic.
Multicast traffic has received a lot of attention in wireless networks, but
not in the wired domain. Any new proposal should be able to address both
the unicast and the multicast traffic scenarios. Having different methods
for these two scenarios might lead to unnecessary processing burden in the
routers, which might hinder its scalability.

 *Should not rely on just switching off unused links*

Most approaches to optimize energy pursue the following approach: measure,
monitor and respond to the system energy usage by switching off unused or
under-utilized links. Such an approach could be effective for reducing
power locally. The effect on the network is not clearly understood.
Further, the power usage involved in turning on and rebooting/reconfiguring
the device is often not explicitly considered. We note that Service Level
Agreement (SLA) requirements may not even permit the links to be switched
off. Also services provided by ISPs like Virtual Private Networks (VPNs)
can be affected by such re-routing decisions.

 *Should follow an hierarchical and distributed approach*

For scalability, it is important that the algorithms proposed for inter-AS
should also be applicable to intra-AS situations. Networks do not work in
isolation, so any proposal should be both distributed and hierarchical. The
algorithms should be applicable at every level of the hierarchy.

 *Should  provide incentives for ISP for adoption*

The engineering proposals should be aligned with commercial incentives for
rapid and widespread adoption. Today, the device manufacturers and the ISPs
operate independently of each other, and there is no incentive for
manufacturers to work towards low-power and high bandwidth devices. An
ISP’s revenue model is based on the consumed bandwidth, which in turn lead
naturally to more power consumption. If the proposed method chooses routers
that consume low-power and increase the data flow through them, then this
indirectly provides encouragement for ISPs to purchase low-power and high
bandwidth devices.

We now present our metric-based proposals in the below mentioned drafts
which addresses the aforementioned design aspects.

We would like the routing community to provide feedback on these drafts. We
also intend to present this work in an abridged format in the upcoming IETF.

 The drafts are as follows....

   - mjsraman-panet-bgp-power-path<http://tools.ietf.org/html/draft-mjsraman-panet-bgp-power-path>
    (timeline)<http://www.arkko.com/tools/lifecycle/draft-mjsraman-panet-bgp-power-path-timing.html>
    Inter-AS-Proposal
   - mjsraman-panet-ecmp-redirect-power-repl-cap<http://tools.ietf.org/html/draft-mjsraman-panet-ecmp-redirect-power-repl-cap>
    (timeline)<http://www.arkko.com/tools/lifecycle/draft-mjsraman-panet-ecmp-redirect-power-repl-cap-timing.html>
    Multicast
   - mjsraman-panet-inter-as-power-source<http://tools.ietf.org/html/draft-mjsraman-panet-inter-as-power-source>
    (timeline)<http://www.arkko.com/tools/lifecycle/draft-mjsraman-panet-inter-as-power-source-timing.html>
Inter-AS
   Proposal
   - mjsraman-panet-inter-as-psp<http://tools.ietf.org/html/draft-mjsraman-panet-inter-as-psp>
    (timeline)<http://www.arkko.com/tools/lifecycle/draft-mjsraman-panet-inter-as-psp-timing.html>
Inter-AS
   Proposal
   - mjsraman-panet-inter-as-psp-protect<http://tools.ietf.org/html/draft-mjsraman-panet-inter-as-psp-protect>
    (timeline)<http://www.arkko.com/tools/lifecycle/draft-mjsraman-panet-inter-as-psp-protect-timing.html>
Inter-AS
   Proposal
   - mjsraman-panet-pce-power-mcast-replic<http://tools.ietf.org/html/draft-mjsraman-panet-pce-power-mcast-replic>
    (timeline)<http://www.arkko.com/tools/lifecycle/draft-mjsraman-panet-pce-power-mcast-replic-timing.html>
    Multicast
   - mjsraman-panet-pim-power<http://tools.ietf.org/html/draft-mjsraman-panet-pim-power>
    (timeline)<http://www.arkko.com/tools/lifecycle/draft-mjsraman-panet-pim-power-timing.html>
    Multicast
   - mjsraman-panet-tcam-power-efficiency<http://tools.ietf.org/html/draft-mjsraman-panet-tcam-power-efficiency>
    (timeline)<http://www.arkko.com/tools/lifecycle/draft-mjsraman-panet-tcam-power-efficiency-timing.html>
TCAM
   related
   - mjsraman-panet-tcam-power-ratio<http://tools.ietf.org/html/draft-mjsraman-panet-tcam-power-ratio>
    (timeline<http://www.arkko.com/tools/lifecycle/draft-mjsraman-panet-tcam-power-ratio-timing.html>)
   TCAM related
   - mjsraman-pce-power-replic<http://tools.ietf.org/html/draft-mjsraman-pce-power-replic>
    (timeline)<http://www.arkko.com/tools/lifecycle/draft-mjsraman-pce-power-replic-timing.html>
    Multicast
   - mjsraman-panet-intra-as-psp-te-leak<http://tools.ietf.org/html/draft-mjsraman-panet-intra-as-psp-te-leak>
    (timeline)<http://www.arkko.com/tools/lifecycle/draft-mjsraman-panet-intra-as-psp-te-leak-timing.html>
Inter-Area
   within an AS
   - mjsraman-panet-ospf-power-topo<http://tools.ietf.org/html/draft-mjsraman-panet-ospf-power-topo>
    (timeline)<http://www.arkko.com/tools/lifecycle/draft-mjsraman-panet-ospf-power-topo-timing.html>
Intra-Area
   within an AS

We understand it is a lot of matter to go through. We would much appreciate
if some of you could review the inter-AS proposals while others take up
multicast and Intra-AS unicast and multicast.

Thanks again for your time on this matter.

thanks and regards,
balaji venkat

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 6 Feb 2013 10:45:30 +0000

Hi Balaji,

Is the scope of the work that you propose different of EERG,  could it be part of EERG, or an extension?

Thanks and Regards,

Dan

From: [email-masked] [mailto:[email-masked]] On Behalf Of Balaji venkat Venkataswami
Sent: Wednesday, February 06, 2013 8:58 AM
To: [email-masked]; Lars Eggert; Susan Hares
Subject: [irtf-discuss] Request for a side-bar meeting in the IETF Orlando on Power-Aware Networking drafts

Dear Lars, all,

We would like a side-bar meeting (in an adjacent room) to discuss the following Power-Aware-Networking proposals.
A detailed outline of the drafts submitted have been detailed below. We would like a 20 minute slot with 10 minutes for Q&A if possible.
We would however concur with whatever time you give us on this matter.

We are a group of research and industry individuals tied together with a common goal towards reducing the energy consumption in the core and edge networks.

We present a metric-based hierarchical approach to reduce power consumption in core and edge networks. The proposal considers both unicast and the multicast cases. For unicast, the metric considered is consumed-power to available-bandwidth and for multicast the metric is consumed-power to available-replication-capacity.

 With unicast, the metric is used to determine a low-power path between sources and destinations. With multicast, the metric serves the twin purpose of finding low-power multicast paths as well as multicast replication points.  We evolve multiple techniques at various hierarchical levels. One at the Inter-AS level, Inter-Area level within the AS and intra-Area within an AS. Additionally, the proposed method can also be used to determine disjoint or redundant paths for load balancing or fault tolerance. Additionally since TCAMs are one of the biggest power guzzlers in all the components on a router/switch, we have presented a solution for intra-AS purposes to use the TCAM according to the traffic matrix passing through the system and shut down those TCAM banks that are unused. With this in mind, we have also advocated taking into account a TCAM-POWER-Ratio in order to compute the paths from source to destination based on this metric. Once low-power paths, in either the unicast or the multicast cases, are identified then currently available traffic engineering techniques could be used to route the data packets. In the case of inter-AS BGP path selection is also modified to arrive at paths which are low-power paths.

We now outline four important aspects that any approach for power reduction should be capable of addressing.

 Should cater for both unicast and multicast scenarios

Multicast provides an important scenario for the Internet. Today, most proposals consider mainly low-power path routing with unicast traffic. Multicast traffic has received a lot of attention in wireless networks, but not in the wired domain. Any new proposal should be able to address both the unicast and the multicast traffic scenarios. Having different methods for these two scenarios might lead to unnecessary processing burden in the routers, which might hinder its scalability.

 Should not rely on just switching off unused links

Most approaches to optimize energy pursue the following approach: measure, monitor and respond to the system energy usage by switching off unused or under-utilized links. Such an approach could be effective for reducing power locally. The effect on the network is not clearly understood. Further, the power usage involved in turning on and rebooting/reconfiguring the device is often not explicitly considered. We note that Service Level Agreement (SLA) requirements may not even permit the links to be switched off. Also services provided by ISPs like Virtual Private Networks (VPNs) can be affected by such re-routing decisions.

 Should follow an hierarchical and distributed approach

For scalability, it is important that the algorithms proposed for inter-AS should also be applicable to intra-AS situations. Networks do not work in isolation, so any proposal should be both distributed and hierarchical. The algorithms should be applicable at every level of the hierarchy.

 Should  provide incentives for ISP for adoption

The engineering proposals should be aligned with commercial incentives for rapid and widespread adoption. Today, the device manufacturers and the ISPs operate independently of each other, and there is no incentive for manufacturers to work towards low-power and high bandwidth devices. An ISP's revenue model is based on the consumed bandwidth, which in turn lead naturally to more power consumption. If the proposed method chooses routers that consume low-power and increase the data flow through them, then this indirectly provides encouragement for ISPs to purchase low-power and high bandwidth devices.

We now present our metric-based proposals in the below mentioned drafts which addresses the aforementioned design aspects.

We would like the routing community to provide feedback on these drafts. We also intend to present this work in an abridged format in the upcoming IETF.
 The drafts are as follows....

*         mjsraman-panet-bgp-power-path<http://tools.ietf.org/html/draft-mjsraman-panet-bgp-power-path> (timeline)<http://www.arkko.com/tools/lifecycle/draft-mjsraman-panet-bgp-power-path-timing.html> Inter-AS-Proposal
*         mjsraman-panet-ecmp-redirect-power-repl-cap<http://tools.ietf.org/html/draft-mjsraman-panet-ecmp-redirect-power-repl-cap> (timeline)<http://www.arkko.com/tools/lifecycle/draft-mjsraman-panet-ecmp-redirect-power-repl-cap-timing.html> Multicast
*         mjsraman-panet-inter-as-power-source<http://tools.ietf.org/html/draft-mjsraman-panet-inter-as-power-source> (timeline)<http://www.arkko.com/tools/lifecycle/draft-mjsraman-panet-inter-as-power-source-timing.html> Inter-AS Proposal
*         mjsraman-panet-inter-as-psp<http://tools.ietf.org/html/draft-mjsraman-panet-inter-as-psp> (timeline)<http://www.arkko.com/tools/lifecycle/draft-mjsraman-panet-inter-as-psp-timing.html> Inter-AS Proposal
*         mjsraman-panet-inter-as-psp-protect<http://tools.ietf.org/html/draft-mjsraman-panet-inter-as-psp-protect> (timeline)<http://www.arkko.com/tools/lifecycle/draft-mjsraman-panet-inter-as-psp-protect-timing.html> Inter-AS Proposal
*         mjsraman-panet-pce-power-mcast-replic<http://tools.ietf.org/html/draft-mjsraman-panet-pce-power-mcast-replic> (timeline)<http://www.arkko.com/tools/lifecycle/draft-mjsraman-panet-pce-power-mcast-replic-timing.html> Multicast
*         mjsraman-panet-pim-power<http://tools.ietf.org/html/draft-mjsraman-panet-pim-power> (timeline)<http://www.arkko.com/tools/lifecycle/draft-mjsraman-panet-pim-power-timing.html> Multicast
*         mjsraman-panet-tcam-power-efficiency<http://tools.ietf.org/html/draft-mjsraman-panet-tcam-power-efficiency> (timeline)<http://www.arkko.com/tools/lifecycle/draft-mjsraman-panet-tcam-power-efficiency-timing.html> TCAM related
*         mjsraman-panet-tcam-power-ratio<http://tools.ietf.org/html/draft-mjsraman-panet-tcam-power-ratio> (timeline<http://www.arkko.com/tools/lifecycle/draft-mjsraman-panet-tcam-power-ratio-timing.html>) TCAM related
*         mjsraman-pce-power-replic<http://tools.ietf.org/html/draft-mjsraman-pce-power-replic> (timeline)<http://www.arkko.com/tools/lifecycle/draft-mjsraman-pce-power-replic-timing.html> Multicast
*         mjsraman-panet-intra-as-psp-te-leak<http://tools.ietf.org/html/draft-mjsraman-panet-intra-as-psp-te-leak> (timeline)<http://www.arkko.com/tools/lifecycle/draft-mjsraman-panet-intra-as-psp-te-leak-timing.html> Inter-Area within an AS
*         mjsraman-panet-ospf-power-topo<http://tools.ietf.org/html/draft-mjsraman-panet-ospf-power-topo> (timeline)<http://www.arkko.com/tools/lifecycle/draft-mjsraman-panet-ospf-power-topo-timing.html> Intra-Area within an AS
We understand it is a lot of matter to go through. We would much appreciate if some of you could review the inter-AS proposals while others take up multicast and Intra-AS unicast and multicast.

thanks and regards,
balaji venkat

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 6 Feb 2013 10:47:47 +0000

(resending to a better address of Lars, although I am pretty sure that he reads irtf-discuss)

Hi Balaji,

Thanks and Regards,

Dan

Dear Lars, all,

thanks and regards,
balaji venkat

---

From: Balaji venkat Venkataswami <[email-masked]>
Date: Wed, 6 Feb 2013 16:43:07 +0530

Hi Dan,

It could be definitely part of EERG. That is our opinion.

thanks and regards,
balaji venkat

On Wed, Feb 6, 2013 at 4:15 PM, Romascanu, Dan (Dan) <[email-masked]>wrote:

>  Hi Balaji,****
>
> ** **
>
> Is the scope of the work that you propose different of EERG,  could it be
> part of EERG, or an extension? ****
>
> ** **
>
> Thanks and Regards,****
>
> ** **
>
> Dan****
>
> ** **
>
> ** **
>
> ** **
>
> *From:* [email-masked] [mailto:
> [email-masked]] *On Behalf Of *Balaji venkat Venkataswami
> *Sent:* Wednesday, February 06, 2013 8:58 AM
> *To:* [email-masked]; Lars Eggert; Susan Hares
> *Subject:* [irtf-discuss] Request for a side-bar meeting in the IETF
> Orlando on Power-Aware Networking drafts****
>
> ** **
>
> Dear Lars, all,****
>
> ** **
>
> following Power-Aware-Networking proposals.****
>
> would like a 20 minute slot with 10 minutes for Q&A if possible.****
>
> We would however concur with whatever time you give us on this matter.****
>
> networks.****
> We present a metric-based hierarchical approach to reduce power
> consumption in core and edge networks. The proposal considers both unicast
> and the multicast cases. For unicast, the metric considered is *consumed-power
> to available-bandwidth* and for multicast the metric is *consumed-power
> to available-replication-capacity.*****
>
> selection is also modified to arrive at paths which are low-power paths.**
> **
>
>  Our main objective is as follows...****
>
> We now outline four important aspects that any approach for power
> reduction should be capable of addressing.****
>
>  *Should cater for both unicast and multicast scenarios*****
>
> routers, which might hinder its scalability.        ****
>
>  *Should not rely on just switching off unused links*****
>
> can be affected by such re-routing decisions.****
>
>  *Should follow an hierarchical and distributed approach*****
>
> algorithms should be applicable at every level of the hierarchy.  ****
>
>  *Should  provide incentives for ISP for adoption*****
>
> bandwidth devices.                ****
>  ****
> which addresses the aforementioned design aspects.****
>
> We would like the routing community to provide feedback on these drafts.
> We also intend to present this work in an abridged format in the upcoming
> IETF.****
>
>  The drafts are as follows....****
>
> ** **
>
> ** **
>
> **·         **mjsraman-panet-bgp-power-path<http://tools.ietf.org/html/draft-mjsraman-panet-bgp-power-path>
>  Inter-AS-Proposal****
> **·         **mjsraman-panet-ecmp-redirect-power-repl-cap<http://tools.ietf.org/html/draft-mjsraman-panet-ecmp-redirect-power-repl-cap>
>  Multicast****
> **·         **mjsraman-panet-inter-as-power-source<http://tools.ietf.org/html/draft-mjsraman-panet-inter-as-power-source>
>  (timeline)<http://www.arkko.com/tools/lifecycle/draft-mjsraman-panet-inter-as-power-source-timing.html> Inter-AS
> Proposal****
>
> **·         **mjsraman-panet-inter-as-psp<http://tools.ietf.org/html/draft-mjsraman-panet-inter-as-psp>
>  (timeline)<http://www.arkko.com/tools/lifecycle/draft-mjsraman-panet-inter-as-psp-timing.html> Inter-AS
> Proposal****
>
> **·         **mjsraman-panet-inter-as-psp-protect<http://tools.ietf.org/html/draft-mjsraman-panet-inter-as-psp-protect>
>  (timeline)<http://www.arkko.com/tools/lifecycle/draft-mjsraman-panet-inter-as-psp-protect-timing.html> Inter-AS
> Proposal****
>
> **·         **mjsraman-panet-pce-power-mcast-replic<http://tools.ietf.org/html/draft-mjsraman-panet-pce-power-mcast-replic>
>  Multicast****
> **·         **mjsraman-panet-pim-power<http://tools.ietf.org/html/draft-mjsraman-panet-pim-power>
>  Multicast****
> **·         **mjsraman-panet-tcam-power-efficiency<http://tools.ietf.org/html/draft-mjsraman-panet-tcam-power-efficiency>
>  (timeline)<http://www.arkko.com/tools/lifecycle/draft-mjsraman-panet-tcam-power-efficiency-timing.html> TCAM
> related****
>
> **·         **mjsraman-panet-tcam-power-ratio<http://tools.ietf.org/html/draft-mjsraman-panet-tcam-power-ratio>
> TCAM related****
> **·         **mjsraman-pce-power-replic<http://tools.ietf.org/html/draft-mjsraman-pce-power-replic>
>  Multicast****
> **·         **mjsraman-panet-intra-as-psp-te-leak<http://tools.ietf.org/html/draft-mjsraman-panet-intra-as-psp-te-leak>
>  (timeline)<http://www.arkko.com/tools/lifecycle/draft-mjsraman-panet-intra-as-psp-te-leak-timing.html> Inter-Area
> within an AS****
>
> **·         **mjsraman-panet-ospf-power-topo<http://tools.ietf.org/html/draft-mjsraman-panet-ospf-power-topo>
>  (timeline)<http://www.arkko.com/tools/lifecycle/draft-mjsraman-panet-ospf-power-topo-timing.html> Intra-Area
> within an AS****
>
> We understand it is a lot of matter to go through. We would much
> appreciate if some of you could review the inter-AS proposals while others
> take up multicast and Intra-AS unicast and multicast.****
>
> ** **
>
> Thanks again for your time on this matter.****
>
> ** **
>
> thanks and regards,****
>
> balaji venkat****
>

---

From: Balaji venkat Venkataswami <[email-masked]>
Date: Wed, 6 Feb 2013 16:44:36 +0530

CCing the correct Lars Eggert email.

thanks and regards,
balaji venkat

On Wed, Feb 6, 2013 at 4:43 PM, Balaji venkat Venkataswami <
[email-masked]> wrote:

>> selection is also modified to arrive at paths which are low-power paths.*
>> ***
>>
>> Most approaches to optimize energy pursue the following approach:
>> measure, monitor and respond to the system energy usage by switching off
>> unused or under-utilized links. Such an approach could be effective for
>> reducing power locally. The effect on the network is not clearly
>> understood. Further, the power usage involved in turning on and
>> rebooting/reconfiguring the device is often not explicitly considered. We
>> note that Service Level Agreement (SLA) requirements may not even permit
>> the links to be switched off. Also services provided by ISPs like Virtual
>> Private Networks (VPNs) can be affected by such re-routing decisions.****
>>
>> For scalability, it is important that the algorithms proposed for
>> inter-AS should also be applicable to intra-AS situations. Networks do not
>> work in isolation, so any proposal should be both distributed and
>> hierarchical. The algorithms should be applicable at every level of the
>> hierarchy.  ****
>>
>> The engineering proposals should be aligned with commercial incentives
>> for rapid and widespread adoption. Today, the device manufacturers and the
>> ISPs operate independently of each other, and there is no incentive for

---

From: "Eggert, Lars" <[email-masked]>
Date: Wed, 6 Feb 2013 11:36:00 +0000

Hi,

> It could be definitely part of EERG. That is our opinion.

You should probably also bring this up in RRG, since there is a distinct focus on routing here?

Lars

---

From: Balaji Venkat <[email-masked]>
Date: Wed, 6 Feb 2013 17:38:30 +0530

Dear Lars

Tony li replied saying the RRG is in hibernation and that RRG will not meet in Orlando

Would be much obliged if you can us help in this regard

Thanks and regards 
Balaji

Sent from my iPhone

---

From: "Eggert, Lars" <[email-masked]>
Date: Wed, 6 Feb 2013 12:22:27 +0000

Hi,

> Tony li replied saying the RRG is in hibernation and that RRG will not meet in Orlando

it's in hibernation, but still looking for new topics, as far as I understand. So a pitch for looking into research related to energy savings in the routing system could lead to something that would bring the RRG out of hibernation. 

It probably won't do so for Orlando, but you are very late with a room request for the Orlando meeting anyway.

Lars

---

From: Tony Li <[email-masked]>
Date: Wed, 6 Feb 2013 08:56:15 -0800

> it's in hibernation, but still looking for new topics, as far as I understand. So a pitch for looking into research related to energy savings in the routing system could lead to something that woul…

Yes, it's true that the RRG could be revived, but before we bring the RRG out of hibernation, there needs to be a sufficient community to pick up and carry on the work.  So far, I'm unaware of that community.

Regards,
Tony