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
