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

From: Jeffrey Haas <[email-masked]>
Date: Wed, 1 Mar 2017 14:04:25 -0500

[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
network.

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

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 2 Mar 2017 10:21:54 -0500

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, [email-masked] 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