Dear Curtis, As already stated to you in a private email, "We" are a group of people with 40 years of collective industry experience in the networking industry. We dont need to be patronized by anybody since we have independent minds that have the capability to digest information not based on somebody else's interpretation of how future networks need to be built and how power reduction needs to play a part in it.
As you might recall one such research paper on GreenTE by Beichuan Zhang rang a lot of bells in the IETF by collecting the ANRP prize. So please dont misstate facts as you might know them and shove your ideas of how networks are built down our throats. We think the IETF is a free and fair body that accepts opinions and ideas from all sides. We want to keep this a free and fair organization. So incumbent people like you ought to encourage us and have a fair argument when we present such work to you. Dont follow the policy of exclusion to the nth degree. It is but fair to say that you seem to be in a minority on this matter. Nobody else responded with unkind misstatements of facts and mis-understanding of our technical antecedents. Suffice to say that if we get an opportunity to present this (since IETF is OUR organization too) you need not sit through it. If you want to give us a fair hearing please follow a policy of kind inclusion and not create a ruckus about us research folks trying to make an earnest attempt at some practical research that could well save the planet. Yours sincerely, Thanks and regards, balaji venkat and shankar raman On Thu, Feb 7, 2013 at 12:11 AM, Curtis Villamizar <[email protected]> wrote: > > Balaji, > > "We" in the context of your first paragraph seems to be a > misrepresentation. The authors of all of these drafts seem to be from > the same university in India. From prior attempts on your part to get > a draft of this sort into IDR and a brief reading of a few of the > drafts that you have just submitted, you don't seem to have a good > understanding of how networks are built and how network equipment is > built from which to begin to attack the problem of reducing the power > consumption of these networks. > > If you want to try to advance a research paper with your theories on > power reduction, please choose an appropriate venue such as a refereed > technical journal. > > Curtis > > > In message < > cahf4apo9bekpk7qwa9fgjq9bnunhnv+ofon_9_4oij61e11...@mail.gmail.com> > Balaji venkat Venkataswami writes: > > > Dear all, > > > > 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=92s revenue model is based on the consumed bandwidth, which in turn > lea= > > d > > 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-mjsrama= > > n-panet-bgp-power-path> > > (timeline)< > http://www.arkko.com/tools/lifecycle/draft-mjsraman-panet-bg= > > p-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-ec= > > mp-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-in= > > ter-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-in= > > ter-as-psp-timing.html> > > Inter-AS > > Proposal > > - mjsraman-panet-inter-as-psp-protect< > http://tools.ietf.org/html/draft-m= > > jsraman-panet-inter-as-psp-protect> > > (timeline)< > http://www.arkko.com/tools/lifecycle/draft-mjsraman-panet-in= > > ter-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-pc= > > e-power-mcast-replic-timing.html> > > Multicast > > - mjsraman-panet-pim-power< > http://tools.ietf.org/html/draft-mjsraman-pan= > > et-pim-power> > > (timeline)< > http://www.arkko.com/tools/lifecycle/draft-mjsraman-panet-pi= > > m-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-tc= > > am-power-efficiency-timing.html> > > TCAM > > related > > - mjsraman-panet-tcam-power-ratio< > http://tools.ietf.org/html/draft-mjsra= > > man-panet-tcam-power-ratio> > > (timeline< > http://www.arkko.com/tools/lifecycle/draft-mjsraman-panet-tca= > > m-power-ratio-timing.html>) > > TCAM related > > - mjsraman-pce-power-replic< > http://tools.ietf.org/html/draft-mjsraman-pc= > > e-power-replic> > > (timeline)< > http://www.arkko.com/tools/lifecycle/draft-mjsraman-pce-powe= > > r-replic-timing.html> > > Multicast > > - mjsraman-panet-intra-as-psp-te-leak< > http://tools.ietf.org/html/draft-m= > > jsraman-panet-intra-as-psp-te-leak> > > (timeline)< > http://www.arkko.com/tools/lifecycle/draft-mjsraman-panet-in= > > tra-as-psp-te-leak-timing.html> > > Inter-Area > > within an AS > > - mjsraman-panet-ospf-power-topo< > http://tools.ietf.org/html/draft-mjsram= > > an-panet-ospf-power-topo> > > (timeline)< > http://www.arkko.com/tools/lifecycle/draft-mjsraman-panet-os= > > pf-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 >
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
