Re: [OPSAWG] Rtgdir early review of draft-ietf-opsawg-ipfix-bgp-community-06

li zhenqiang <li_zhenqiang@hotmail.com> Sun, 15 April 2018 14:52 UTC

Return-Path: <li_zhenqiang@hotmail.com>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 356DC1270B4; Sun, 15 Apr 2018 07:52:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.585
X-Spam-Level: *
X-Spam-Status: No, score=1.585 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.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 aaHhztl_oDgW; Sun, 15 Apr 2018 07:52:48 -0700 (PDT)
Received: from APC01-SG2-obe.outbound.protection.outlook.com (mail-oln040092253022.outbound.protection.outlook.com [40.92.253.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A945126CD8; Sun, 15 Apr 2018 07:52:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=yEkTyxA7saZd6RayvsOCWemVduNZQmPIYzkrh++lZiw=; b=NLnCW66g6kCyZ6uWiQKLL2w3p0QWFViFKA3UQZY+SEYlR8e3GMiNbNRIguiYfSsYvwjwdkJ2YjQPbpAjSjY/O1jviIf+ID4k0FIQRTmit8RGQ3jEJIw84SkfwyaKlX3UgQiCP1MfLwlY/IDyFkqz3VwRNPmxO123ZFAY3z+/8txD2RSkR78Vlst/F5EFSAyFHsm9ciZ4YpK8Xd08YfnDW0oZHDHc88uszjVWeYwEVfpAjA1uyx9y5lwARiBZtB1sxAF2YOnga+KkVi1Y4ifLXXJWHVkKT9V9BfVp5kWUp9IB50z7GxkbmPqYPCVKUM1YqxlcY21bmZIoJa9uBqRrvw==
Received: from SG2APC01FT008.eop-APC01.prod.protection.outlook.com (10.152.250.56) by SG2APC01HT179.eop-APC01.prod.protection.outlook.com (10.152.251.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.653.8; Sun, 15 Apr 2018 14:52:43 +0000
Received: from HKXPR0601MB1799.apcprd06.prod.outlook.com (10.152.250.51) by SG2APC01FT008.mail.protection.outlook.com (10.152.250.99) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.675.14 via Frontend Transport; Sun, 15 Apr 2018 14:52:43 +0000
Received: from HKXPR0601MB1799.apcprd06.prod.outlook.com ([fe80::1c96:d34d:5d69:ae92]) by HKXPR0601MB1799.apcprd06.prod.outlook.com ([fe80::1c96:d34d:5d69:ae92%15]) with mapi id 15.20.0675.015; Sun, 15 Apr 2018 14:52:43 +0000
From: li zhenqiang <li_zhenqiang@hotmail.com>
To: "Joel M. Halpern" <jmh@joelhalpern.com>, "rtg-dir@ietf.org" <rtg-dir@ietf.org>
CC: "draft-ietf-opsawg-ipfix-bgp-community.all@ietf.org" <draft-ietf-opsawg-ipfix-bgp-community.all@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, opsawg <opsawg@ietf.org>, "gen-art@ietf.org" <gen-art@ietf.org>
Thread-Topic: Rtgdir early review of draft-ietf-opsawg-ipfix-bgp-community-06
Thread-Index: AQHT1MloTciQIhK0/ESu+vkwx6HGlQ==
Date: Sun, 15 Apr 2018 14:52:43 +0000
Message-ID: <HKXPR0601MB1799868866AF89F9699EAF28FCB10@HKXPR0601MB1799.apcprd06.prod.outlook.com>
References: <152363066886.26321.3212300538180273898@ietfa.amsl.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-incomingtopheadermarker: OriginalChecksum:00C70E009A0877B6D6A78614931A0F036D2E977AD230D003541DF2DDD59DA28B; UpperCasedChecksum:579CA5CA730035F1B73C4027570DEBC3AAC78CF45423E9A0C03DB1900D3DDF7D; SizeAsReceived:7320; Count:46
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [r74pA0mi3DRM5G+bCKdQEPQ9NRxQF1j0]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; SG2APC01HT179; 7:YaCmfUxkXkzNM3DCnrM19Si3gRCHpo+IT1oguKOP4XV9K657OXb/kitVSNTll22QY+85bFsEhsgWAJgBOql4l5Q/z7DIaQUD296PJ30uMhfd5kpJR8jF8kwIQbHyjXc9QMB+gohFMc0/l2nafkE6RktBVnvVRrPffy0VEkXJgV6Y7j13QF/E50UvfleWwsBs8FhHDz7t8al8Eqel8i/rq+4T914S+0Oo+T5nBkAzmrViHbydBnmnXlhF9zGRya5T
x-incomingheadercount: 46
x-eopattributedmessage: 0
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1601125374)(1603101448)(1701031045); SRVR:SG2APC01HT179;
x-ms-traffictypediagnostic: SG2APC01HT179:
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031); SRVR:SG2APC01HT179; BCL:0; PCL:0; RULEID:; SRVR:SG2APC01HT179;
x-forefront-prvs: 0643BDA83C
x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:SG2APC01HT179; H:HKXPR0601MB1799.apcprd06.prod.outlook.com; FPR:; SPF:None; LANG:;
x-microsoft-antispam-message-info: sFt9XYNrYzBT6B6l3HVgllwRmhykTCwheARqZpN1BjCOUxe5J7MbyqMf47j8a7/b1rxygTYOpsK5ctdhGQrXbAHLihWHqup5CazfO1RC8pXkGEQMMyzsUpG3DewJ7vNfiuvHicckqCrsb0zC2wmIKsHSIkK8qE9f9glqUpm36fj8vGWpE/7GxzN5qF79iNvw
Content-Type: multipart/alternative; boundary="_000_HKXPR0601MB1799868866AF89F9699EAF28FCB10HKXPR0601MB1799_"
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: 2c7efdc0-9a86-4069-e5c2-08d5a2e08aa4
X-OriginatorOrg: hotmail.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 24fd1209-d934-423e-a578-ee886993c07f
X-MS-Exchange-CrossTenant-Network-Message-Id: 2c7efdc0-9a86-4069-e5c2-08d5a2e08aa4
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 24fd1209-d934-423e-a578-ee886993c07f
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Apr 2018 14:52:43.3823 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SG2APC01HT179
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/D62iSVZdprpWG-mFG8npXc0Odvc>
Subject: Re: [OPSAWG] Rtgdir early review of draft-ietf-opsawg-ipfix-bgp-community-06
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 15 Apr 2018 14:52:50 -0000

Dear Joel Halpern,

Thank you very much for your review. Please see my preliminary reply below.

For your first concern, the idea is when the routers obtain the information for the already defined BGP related IEs, such as bgpSourceAsNumber, bgpDestinationAsNumber, and bgpNextHopIPv4Address, etc, the information for the IEs defined in this doc can be obtained at the same time since all the BGP related information of a flow is obtained from the matching BGP routing entry when the router receives the first packet of the flow. We explain this point in the forth paragraph of the Introduction part. Our co-author Jie Dong, who is from product vendor Huawei, will explain this in more detail later.

I do NOT think the routers have to change their architectures to report the BGP related information for the traffic flow. Supposing the routers have to do this, they have already done so when implementing the already defined BGP related IEs bgpSourceAsNumber, bgpDestinationAsNumber, and bgpNextHopIPv4Address, etc. The first BGP related information element is not defined by our draft.

We admit that the correlation could be done at the collectors. But we insist that the right place to do the BGP related correlation is the exporters in the routers, because the correlation for the BGP related information is very heavy for the collectors. To do so, the collectors have to run BGP or BMP which is already running in the routers and to do BGP table longest prefix matching lookup to find the correct table entry. We explain this point in the 4th and 5th paragraphs of the Introduction part.

For your second concern, you admit using BGP community attribute to represent the geographical regions and different kinds of customers is a legal practice, so said in RFC4383 and RFC8195.  Why do you think this is unusual and not common? China Mobile uses the standard BGP community to represent the different provinces and different kinds of customers in our field network. Swisscom and AT&T also said this doc was useful for their network operation in the mail list and face to face meeting. Anyway, I will ask for more comments from the operators.

For your coclusion, I'm very confused. From where do you say that the draft admits that this is not needed? If we think what we want is not needed, why we submit this doc. If some words in the doc mislead you, I apologize and will polish them.

Thank you again for your review.

Best Regards,
Zhenqiang Li
________________________________
li_zhenqiang@hotmail.com

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.