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, lizhenqi...@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 _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
