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

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

Return-Path: <jmh@joelhalpern.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 526921204DA; Sun, 15 Apr 2018 20:43:35 -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 A8A7sDZLh1Mi; Sun, 15 Apr 2018 20:43:33 -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 681BC12D77C; Sun, 15 Apr 2018 20:43:33 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 526104E0063; Sun, 15 Apr 2018 20:43:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1523850213; bh=JP6L/BA1q+07hOP3Jbu6apBVqwljguSzU01P1LHnvG0=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=kmtXZdG957CHYzPq9nf6tHSvC20dyy7oVB4fkv9oQbGnEHxppi0eILDitWwtXA1FG HwtZbkMBvZob3v6lhssqnwaFhkHS1ghf+Y9bV6peVIS5H51l5oJ1XHExJpZOzhufBl vgZZnjNVmn7G+a87tp5r1CU+2Iv6EdQfD1PiJ4dw=
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 27DDD1C0B99; Sun, 15 Apr 2018 20:43:32 -0700 (PDT)
To: "Dongjie (Jimmy)" <jie.dong@huawei.com>, "rtg-dir@ietf.org" <rtg-dir@ietf.org>
Cc: "gen-art@ietf.org" <gen-art@ietf.org>, "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@ietf.org" <opsawg@ietf.org>
References: <152363066886.26321.3212300538180273898@ietfa.amsl.com> <76CD132C3ADEF848BD84D028D243C927983DA81F@NKGEML515-MBX.china.huawei.com>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <ae3d19cb-7615-5660-a480-d385be14e45a@joelhalpern.com>
Date: Sun, 15 Apr 2018 23:43:31 -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: <76CD132C3ADEF848BD84D028D243C927983DA81F@NKGEML515-MBX.china.huawei.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/hAj5QY_gdaRBSuBipj4L-XD4uaA>
Subject: Re: [OPSAWG] [RTG-DIR] 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: Mon, 16 Apr 2018 03:43:35 -0000

Thank you Jimmy.
While I disagree, I think this states the case clearly enough for it to 
be up to the working group and relevant ADs.

Yours,
Joel

On 4/15/18 11:40 PM, Dongjie (Jimmy) wrote:
> Hi Joel,
> 
> Thanks a lot for your review comments.
> 
> Regarding your first problem, I don't think this draft introduces "significant new processing load on the router", as similar processing has already been done for the BGP AS number and BGP-nexthop based traffic collection. As described in the draft, the BGP-community based traffic collection is done by BGP lookup and correlating the BGP community with the flow data to be exported. Whether it is done in data plane or control plane is implementation specific and IMO does not belong to a IETF document.
> 
> As for your second problem, as many operators have pointed out, it is a common case to use BGP communities to represent geo locations at various granularities. So we need to provide them the tools to meet their requirements. Standardizing the IEs for BGP community is a good start.
> 
> Best regards,
> Jie
> 
>> -----Original Message-----
>> From: Joel Halpern [mailto:jmh@joelhalpern.com]
>> Sent: Friday, April 13, 2018 10:44 PM
>> 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) 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.
>