Hi Curtis, One clarification: when I said the "other drafts", I actually meant the following drafts.
Power-Aware Networks (PANET): Problem Statement, https://datatracker.ietf.org/doc/draft-zhang-panet-problem-statement/ Use Cases for Power-Aware Networks, https://datatracker.ietf.org/doc/draft-zhang-panet-use-cases/ Requirements for Power Aware Network, https://datatracker.ietf.org/doc/draft-dong-panet-requirement Thanks, Mingui ________________________________________ From: Curtis Villamizar [[email protected]] Sent: Tuesday, February 12, 2013 0:18 To: Mingui Zhang Cc: [email protected]; Tony Li; [email protected]; Susan Hares Subject: Re: PANET side-meeting In message <4552f0907735844e9204a62bbdd325e732aff...@nkgeml508-mbx.china.huawei.com> Mingui Zhang writes: > I mentioned earlier on the prior thread that I had just quickly read > draft-retana-rtgwg-eacp-00 and did not think this work was worth the > IETF (or IRTF, if I can speak up in advance) in its current form. The > topic might be worth considering, but the work seems to take a naive > approach. Whether treating interfaces and links as a black box and > using routing provides any appreciable gain in real networks remains > to be proven. > > [zmg] I'd like to hear your _specific_ feedbacks on other drafts. I have better things to do with my time than provide detailed review of drafts that are ill conceived and so do most of the people on the mailing list. Below is the list of drafts with comments on whether they are relevant. draft-mjsraman-panet-bgp-power-path draft-mjsraman-panet-ecmp-redirect-power-repl-cap draft-mjsraman-panet-inter-as-power-source draft-mjsraman-panet-inter-as-psp draft-mjsraman-panet-inter-as-psp-protect draft-mjsraman-panet-pce-power-mcast-replic draft-mjsraman-panet-pim-power draft-mjsraman-pce-power-replic draft-mjsraman-panet-intra-as-psp-te-leak draft-mjsraman-panet-ospf-power-topo These are all founded on the premise that there are significant gains that can result from routing that is aware of power disipation differences in hardware related to the traffic load placed on the hardware. The topic of the relevance of these drafts to RTGWG has just been discussed and the concensus seems to me to be that these are not relevant to RTGWG. The discussion so far has been to move all of this work to IRTF if IRTF wants to pursue this topic. draft-mjsraman-panet-tcam-power-efficiency draft-mjsraman-panet-tcam-power-ratio Alreadty discussed on list. Theee TCAM drafts are ill conceived and technically flawed. They should be dropped completely. There may be merit to doing work in this area but you are going about it entirely the wrong way. IMO you need to start with a BOF proposal with a brief problem statement and a charter to address the problem. No solution should be mentioned in the initial charter, with a detailed problem statement draft, requirements draft and framework draft. The outcome of this initial exercise would dictate what sort of solutions, if any, to pursue. For example, if any work is done, it may be best to start with IGP and inter-domain MPLS since they can be deployed in a single AS. Multicast right now contributes a much smaller percentage of load than unicast, so it makes sense to do IGP first. For BGP you can always use DFA (just declared historic, my point being that overloading global BGP with new inter-AS metrics is going to be a "hard sell"). > [end of comments] > > > These documents are trying to write requirements, build a framework, > and specify protocols, all based on unproven assertions. > > If the work goes to IRTF, the first order of business must be to > provide compelling proof or at least compelling argument that a > specific approach will have benefit in *real* networks, not hypothetic > networks, and not real topologies with a hypothetic network > architecture (ie: choice of type of equipment and build out). > > Curtis My main point stands. IMO You are out of line to submit nearly a dozen drafts to RTGWG on topics for which research is needed to determine if there is any merit to the approach. Curtis _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
