Re: [Gen-art] 答复: Rtgdir early review of draft-ietf-opsawg-ipfix-bgp-community-06

"Joel M. Halpern" <jmh@joelhalpern.com> Mon, 16 April 2018 03:42 UTC

Return-Path: <jmh@joelhalpern.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 772AA12D77C; Sun, 15 Apr 2018 20:42:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M0upy8DgizHo; Sun, 15 Apr 2018 20:42:10 -0700 (PDT)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDDD41204DA; Sun, 15 Apr 2018 20:42:10 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id C152E1C0B99; Sun, 15 Apr 2018 20:42:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1523850130; bh=F2C221reOC00PBJMp2JT4KXyaL30W7r0+xiE6m12xmA=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=pN+26xUsa02IUomPlySSCSBuGvSsBzOFHYY5U8LbxQLd17Ffcv/lj92PzRRmdzzU5 kec/IYDGO6HhRtXS4cQzDtA/XsEflF18D8ciWtRLgAztwQYtJx31uqqX70L3wpCfKi RHcEasMjHXygppqBGuBYFJQTI2cShTMlPc1tHK4Y=
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from Joels-MacBook-Pro.local (unknown [50.225.209.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id D7E674E00AE; Sun, 15 Apr 2018 20:42:08 -0700 (PDT)
To: Aijun Wang <wangaijun@tsinghua.org.cn>
Cc: rtg-dir@ietf.org, draft-ietf-opsawg-ipfix-bgp-community.all@ietf.org, ietf@ietf.org, opsawg@ietf.org, gen-art@ietf.org
References: <SINPR0601MB18052453D8D09372BE4FB583FCB10@SINPR0601MB1805.apcprd06.prod.outlook.com> <00d101d3d52c$f57047d0$e050d770$@org.cn>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <9b559b32-51d0-d761-ae00-08403a041544@joelhalpern.com>
Date: Sun, 15 Apr 2018 23:42:07 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <00d101d3d52c$f57047d0$e050d770$@org.cn>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/qsq3jGT_qAomSL1a3zUS9c4X7fw>
Subject: Re: [Gen-art] =?utf-8?b?562U5aSNOiBSdGdkaXIgZWFybHkgcmV2aWV3IG9mIGRy?= =?utf-8?q?aft-ietf-opsawg-ipfix-bgp-community-06?=
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Apr 2018 03:42:12 -0000

There seem to be two separate issues.

The first issue is what information from BGP would one like to correlate 
with the traffic flows.  I understand that there is useful information. 
The motivation given in the draft seems to apply to more cases than I 
thought, but still it is of limited applicability.

More importantly is the question of whether the proposed method is the 
right way to get the information.  As the draft acknowledges, there are 
other ways to get the information.  Ways that do not need new router 
software much less modifications of the fast path.
There is an argument in the draft about timeliness.  At least for the 
use case document in the draft, that argument does not hold water.

Yours,
Joel

On 4/15/18 10:45 PM, Aijun Wang wrote:
>     Hi, Joel:
> 
>     Can we consider this draft from other viewpoints? If the router can
>     report and correlate the traffic with its associated community, the
>     usage of the community to differentiate the customer, the service
>     category that be accessed and the geographical region etc. will be
>     flourished.
> 
>     And currently, China Telecom has some internal usage regulation for
>     community to differentiate some important customers and the related
>     services.
> 
>     Best Regards.
> 
>     Aijun Wang
> 
>     Network R&D and Operation Support Department
> 
>     China Telecom Corporation Limited Beijing Research
>     Institute,Beijing, China.
> 
> *From:*Joel Halpern <mailto:jmh@joelhalpern.com>
> 
> *Date:* 2018-04-13 22:44
> 
> *To:*rtg-dir@ietf.org <mailto:rtg-dir@ietf.org>
> 
> *CC:*draft-ietf-opsawg-ipfix-bgp-community.all@ietf.org 
> <mailto:draft-ietf-opsawg-ipfix-bgp-community.all@ietf.org>; 
> ietf@ietf.org <mailto:ietf@ietf.org>; opsawg@ietf.org 
> <mailto:opsawg@ietf.org>; gen-art@ietf.org <mailto:gen-art@ietf.org>
> 
> *Subject:* Rtgdir early review of draft-ietf-opsawg-ipfix-bgp-community-06
> 
> Reviewer: Joel Halpern
> 
> Review result: Not Ready
> 
> This is both a gen-art re-review and a routing directorate requested review.
> 
> The revisions from draft-04 to -06 show some improvement.  However, I still
> 
> have serious problems with this work.
> 
> The primary problem is that this seems to violate the designed work
> 
> distribution in the IPFIX architecture.  The draft itself notes that the
> 
> correlation requested could be done in the collector.  Which is where
> 
> correlation is designed to be done.  Instead, it puts a significant new
> 
> processing load on the router that is delivering the IPFIX information.  For
> 
> example, if one delivers IPFIX from the router data plane, one either has to
> 
> modify the router architecture to include additional complex computed
> 
> information in the data plane architecture (a bad place to add 
> complexity) or
> 
> one has to give up and move all the information through the control 
> plane.  And
> 
> even the control plane likely has to add complexity to its RIB logic, as 
> it has
> 
> to move additional information from BGP to the common structures.
> 
> The secondary problem is that this additional work is justified for the 
> router
> 
> by the claim that the unusual usage of applying community tags for 
> geographical
> 
> location of customers is a common practice.  It is a legal practice.  And I
> 
> presume it is done somewhere or the authors would not be asking for 
> it.   But
> 
> it is not common.
> 
> In short, since even the draft admits that this is not needed, I recommend
> 
> against publishing this document as an RFC.
>