Re: [IPFIX] [GROW] [OPSAWG] WG adoption poll for draft-li-opsawg-ipfix-bgp-community-02

Jeffrey Haas <jhaas@pfrc.org> Thu, 02 March 2017 15:16 UTC

Return-Path: <jhaas@slice.pfrc.org>
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 309C2129996; Thu, 2 Mar 2017 07:16:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level:
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 v57NAspoXIiN; Thu, 2 Mar 2017 07:16:04 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 4587C1297F1; Thu, 2 Mar 2017 07:16:04 -0800 (PST)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 73D501E32D; Thu, 2 Mar 2017 10:21:54 -0500 (EST)
Date: Thu, 2 Mar 2017 10:21:54 -0500
From: Jeffrey Haas <jhaas@pfrc.org>
To: "lizhenqiang@chinamobile.com" <lizhenqiang@chinamobile.com>
Message-ID: <20170302152153.GD24913@pfrc.org>
References: <BBA82579FD347748BEADC4C445EA0F21A22B8B05@NKGEML515-MBX.china.huawei.com> <7023a95c-c6a9-4d6a-b009-8f35e447aa4e@gmail.com> <76CD132C3ADEF848BD84D028D243C9279357F4EA@NKGEML515-MBX.china.huawei.com> <2017021611151726192539@chinamobile.com> <EC4D38F4-7735-4C76-8590-FF6B4B012949@ntt.net> <2017021710323644287217@chinamobile.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <2017021710323644287217@chinamobile.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipfix/7AMM0aDYtqobujSE9ij79xM96gM>
Cc: "ipfix@ietf.org" <ipfix@ietf.org>, grow <grow@ietf.org>, opsawg-chairs <opsawg-chairs@ietf.org>, opsawg <opsawg@ietf.org>
Subject: Re: [IPFIX] [GROW] [OPSAWG] WG adoption poll for draft-li-opsawg-ipfix-bgp-community-02
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IPFIX WG discussion list <ipfix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipfix>, <mailto:ipfix-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipfix/>
List-Post: <mailto:ipfix@ietf.org>
List-Help: <mailto:ipfix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipfix>, <mailto:ipfix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Mar 2017 15:16:05 -0000

My original response to IDR and opsawg missed this thread on grow.

I believe most of my concerns are covered in this thread and I don't require
a separate answer. :-)


On Mon, Feb 20, 2017 at 04:58:32PM +0800, lizhenqiang@chinamobile.com wrote:
> Thank you for you opinion. The extended and large communities will be considered after the adoption and according to the working group consensus.

FWIW, I agree with your assessment that extended communities are less likely
to be important to your use case. However, large communities will very
quickly become just as important.

> Please see the appendix  in the draft for the example. bgpDestinationCommunityList is a basicList of bgpCommunity.
> 
> If you don't like the BGP communities according to the source IP of a specific flow, you can indicate it in the templete, i.e. do not specify bgpSourceCommunityList IE in the templete set. Then the exporter will not export the information. 

I do believe you'll need to figure out what to do about overflow of too many
communities.  As suggested in my other response, please consider
prioritizing the inclusion of the well-known communities.

> bgpSourceCommunityList does have values in some network environments. For example,  the overalll network of China Mobile consists of a backbone network and several province networks. Each component network is configured with a few communities. BGP anounces those communities among the component networks. When one province wants to know where (i.e. from which provinces) its incoming traffic comes from, it can use bgpSourceCommunityList.

However, this still causes you difficulty for BGP multipath scenarios.

-- Jeff