RE: PANET side-meeting

I agree with Curtis on this.  As I said in another thread. It is not clear to me even if operators wanted to do Power aware routing why we would need the extensions proposed in some of these documents. As a vendor I'm not likely to keep dynamic power levels per port. 

Don      

-----Original Message-----
From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of Curtis Villamizar
Sent: Monday, February 11, 2013 11:19 AM
To: Mingui Zhang
Cc: rtgwg@ietf.org; Susan Hares
Subject: Re: PANET side-meeting

In message <4552F0907735844E9204A62BBDD325E732AFF6E9@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
rtgwg@ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg