RE: PANET side-meeting

Mingui Zhang <zhangmingui@huawei.com> Tue, 12 February 2013 06:07 UTC

Return-Path: <zhangmingui@huawei.com>
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1DF321F8C3E for <rtgwg@ietfa.amsl.com>; Mon, 11 Feb 2013 22:07:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y0ITxgLtBrtL for <rtgwg@ietfa.amsl.com>; Mon, 11 Feb 2013 22:07:08 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id DCDF221F8C48 for <rtgwg@ietf.org>; Mon, 11 Feb 2013 22:07:04 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id APQ33138; Tue, 12 Feb 2013 06:06:50 +0000 (GMT)
Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 12 Feb 2013 06:06:29 +0000
Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 12 Feb 2013 06:06:46 +0000
Received: from NKGEML508-MBX.china.huawei.com ([169.254.7.33]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.01.0323.007; Tue, 12 Feb 2013 14:06:36 +0800
From: Mingui Zhang <zhangmingui@huawei.com>
To: "curtis@occnc.com" <curtis@occnc.com>
Subject: RE: PANET side-meeting
Thread-Topic: PANET side-meeting
Thread-Index: AQHOCHNvKuTqdHe8Bkmtrak3KqQ1B5h1uvPn
Date: Tue, 12 Feb 2013 06:06:36 +0000
Message-ID: <4552F0907735844E9204A62BBDD325E732AFF828@nkgeml508-mbx.china.huawei.com>
References: Your message of "Sun, 10 Feb 2013 13:28:14 GMT." <4552F0907735844E9204A62BBDD325E732AFF6E9@nkgeml508-mbx.china.huawei.com>, <201302111619.r1BGJCTH031475@gateway1.orleans.occnc.com>
In-Reply-To: <201302111619.r1BGJCTH031475@gateway1.orleans.occnc.com>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.99.198.98]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: Susan Hares <susan.hares@huawei.com>, "rtgwg@ietf.org" <rtgwg@ietf.org>
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Area Working Group <rtgwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtgwg>
List-Post: <mailto:rtgwg@ietf.org>
List-Help: <mailto:rtgwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Feb 2013 06:07:10 -0000

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 [curtis@occnc.com]
Sent: Tuesday, February 12, 2013 0:18
To: Mingui Zhang
Cc: curtis@occnc.com; Tony Li; 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