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

"Aijun Wang" <wangaijun@tsinghua.org.cn> Mon, 16 April 2018 02:45 UTC

Return-Path: <wangaijun@tsinghua.org.cn>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 79F6812D77C; Sun, 15 Apr 2018 19:45:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.21
X-Spam-Level: **
X-Spam-Status: No, score=2.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_BL=0.01, RCVD_IN_MSPIKE_L3=4.1, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id wb3NsUr2y1N2; Sun, 15 Apr 2018 19:45:22 -0700 (PDT)
Received: from m21397.mail.qiye.163.com (m21397.mail.qiye.163.com []) by ietfa.amsl.com (Postfix) with ESMTP id 6B9A312D77A; Sun, 15 Apr 2018 19:45:21 -0700 (PDT)
Received: from WangajPC (unknown []) by m21397.mail.qiye.163.com (Hmail) with ESMTPA id BA842142BF7; Mon, 16 Apr 2018 10:45:19 +0800 (CST)
From: "Aijun Wang" <wangaijun@tsinghua.org.cn>
To: <jmh@joelhalpern.com>
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>
In-Reply-To: <SINPR0601MB18052453D8D09372BE4FB583FCB10@SINPR0601MB1805.apcprd06.prod.outlook.com>
Date: Mon, 16 Apr 2018 10:45:18 +0800
Message-ID: <00d101d3d52c$f57047d0$e050d770$@org.cn>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D2_01D3D570.039387D0"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AQHT1IDANG9Z65W2K0qtbzqg9K7avaQCrqFw
Content-Language: zh-cn
X-HM-Tid: 0a62cc57a9d97f6bkuukba842142bf7
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/292Y3O7DHO2xQYD4v_U7_AqOzN0>
Subject: [Gen-art] =?gb2312?b?tPC4tDogUnRnZGlyIGVhcmx5IHJldmlldyBvZiBkcmFm?= =?gb2312?b?dC1pZXRmLW9wc2F3Zy1pcGZpeC1iZ3AtY29tbXVuaXR5LTA2?=
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 02:45:25 -0000

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



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

CC: draft-ietf-opsawg-ipfix-bgp-community.all@ietf.org; ietf@ietf.org;
opsawg@ietf.org; 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)

one has to give up and move all the information through the control plane.

even the control plane likely has to add complexity to its RIB logic, as it

to move additional information from BGP to the common structures.


The secondary problem is that this additional work is justified for the

by the claim that the unusual usage of applying community tags for

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.

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.