Re: [Idr] FW: WG adoption poll for draft-li-opsawg-ipfix-bgp-community-02

Jeffrey Haas <> Wed, 01 March 2017 18:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AC5651297F3; Wed, 1 Mar 2017 10:58:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.903
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PW13wGKNC_WS; Wed, 1 Mar 2017 10:58:37 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 0849712966A; Wed, 1 Mar 2017 10:58:37 -0800 (PST)
Received: by (Postfix, from userid 1001) id E87401E32D; Wed, 1 Mar 2017 14:04:25 -0500 (EST)
Date: Wed, 1 Mar 2017 14:04:25 -0500
From: Jeffrey Haas <>
Message-ID: <>
References: <> <001201d2865a$48899340$d99cb9c0$>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <001201d2865a$48899340$d99cb9c0$>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <>
Subject: Re: [Idr] FW: WG adoption poll for draft-li-opsawg-ipfix-bgp-community-02
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 01 Mar 2017 18:58:38 -0000

[Please note I am not on the opsawg list.]

On Mon, Feb 13, 2017 at 07:35:45PM -0500, Susan Hares wrote:
> IDR WG: 
> The OPSAWG chairs are reviewing the
> draft-li-opsawg-ipfix-bgp-community-02.txt for WG adoption.  Please comment
> on this OPSAWG list and/or IDR list if you feel this draft should be adopted
> on not adopted. 

I see that the draft was adopted and, as someone who previously worked on
flow generators, think it's a potentially useful feature.  I have a few
brief comments:

1. Is there long-term intent to include other types of community data, such
as extended communities or large communities?
2. The density of flow records significant impacts how quickly flow
collectors are able to process the information.  Unless I'm missing
something, the draft doesn't seem to constrain how many communities might be
able to be sent as part of the flow record as part of the community list.
The authors may want to discuss mechanisms or implementations wherein the
number of items in the list *might* be constrained and what to do in
reporting if the list is truncated or not.
2a. When it's necessary to truncate sending some of the communities, it
might be worth potentially preferring the communities in the well-known
space.  Knowing that a flow at a given ingress is intended to be constrained
downstream may help detecting leaks when performing flow correlation in a

Aside - 3. It's well known that flow collectors on BGP edge devices that may
be distributing traffic over BGP multipaths may not even consistently report
BGP data such as peer-as or origin-as for the flows traversing that
multipath, despite being part of the existing flow record format.  In such
situations, the communities are potentially of low value.

-- Jeff