Hi Paolo， Thank you for you opinion. The extended and large communities will be considered after the adoption and according to the working group consensus.
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. 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. Best Regards, Zhenqiang lizhenqi...@chinamobile.com From: Paolo Lucente Date: 2017-02-17 06:52 To: lizhenqiang CC: zhoutianran; opsawg; opsawg-chairs; grow; ip...@ietf.org Subject: Re: [GROW] [OPSAWG] WG adoption poll for draft-li-opsawg-ipfix-bgp-community-02 Hi, I support Ignas comment with regards to Extended and Large communities. Can you make evident the role, ie. via an example, of the bgpCommunity IE compared to the one of bgpDestinationCommunityList? Also, i'm puzzled by the presence of bgpSourceCommunityList: i see that in "1. Introduction" you kind of close that up saying that there is a Mediator that would take care of the correlation - understandable but then again we all know with a (loosely determined) level of indirection any problem can be addressed; since you also say the draft comes "comes from the field network", i was wondering whether you were subtending to reverse BGP lookups to make this work in practice. In which case, i'd say warning flag: BGP lookups against the source IP address/prefix of a flow would be of no general applicability at all - think, for example, to the common case of an ISP (remotely) connected to an IXP where you have N BGP peers and hence potentially multiple advertisements per prefix, which one you pick for correlation would not be a deterministic exercise. Paolo > On 16 Feb 2017, at 04:15, lizhenqi...@chinamobile.com wrote: > > Dear Ignas, > > Thank you very much for your support and suggestion. > > Since the problem to be solved in this draft comes from the field network, we > only provide the method to carry standard BGP commmunities in IPFIX. Extended > communities are ususlly used for other purposes than standard communities, > such as route target, actions for BGP flowspec etc. Whether or not we really > need to cover entended communities, I want to see more comments. Large > communities are relavitely new. RFC8092 was published recentlly. Anyway, > however, it is easy for us to cover both extended communities [RFC4360] and > large communities [RFC8092] after the adoption and further comment consensus. > Text contribution is welcome. By the way, I want to know the opinions about > the wide communities. Do we need to cover them together? > > As you said, this draft was a good start. It has value to be a working group > item. We can continue the comments and discussion after the adoption and we > will improve the document according to the consensus. Operational > considerations will be covered in the next version. > > Best Regards, > Zhenqiang Li > China Mobile > > -----Original Message----- > From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Ignas Bagdonas > Sent: Tuesday, February 14, 2017 9:46 PM > To: Tianran Zhou <zhoutian...@huawei.com> > Cc: opsawg@ietf.org; opsawg-cha...@ietf.org; g...@ietf.org g...@ietf.org > <g...@ietf.org> > Subject: Re: [GROW] [OPSAWG] WG adoption poll for > draft-li-opsawg-ipfix-bgp-community-02 > > Hi there, > > [Copying GROW WG as this might be relevant to their coverage areas] > > The document seems to be a good start but covers only standard communities. > This is not sufficient given the universal deployment of 4 octet ASNs. Both > extended communities [RFC4360] and large communities [RFC8092] are needed and > are used to address the signalling requirements for AS4 ASNs. Having separate > documents each addressing only a specific type of community does not seem > practical and rational. The document should include the definitions for IEs > covering extended and large communities. > > What is the logic of selecting multiple communities for export that a prefix > may have been decorated with? Is it all of them all the time? The upper limit > may be reaching 16000 standard communities per prefix - would that fit into > resulting IPFIX IE? If there is a limit, how does it work? Is there any > interpretation done on the values of the communities (all types, not just > standard ones)? Those all are operational considerations aspects and should > be covered in the document, appendix A likely could be a good place for it. > > Security considerations on the privacy aspects would to be covered. > > Ignas > > > > > On 13/02/2017 03:36, Tianran Zhou wrote: > > Dear OPSAWG, > > > > In Seoul, we got enough interest and positive response on this IPFIX IE > > extension draft. > > By the authors' request, this email starts a formal poll. The chairs would > > like to know if the WG participants agree that the following document > > should be adopted as a WG document in OPSAWG. > > > > Export BGP community information in IP Flow Information Export (IPFIX) > > https://tools.ietf.org/html/draft-li-opsawg-ipfix-bgp-community-02 > > > > The adoption poll will take two weeks. Please let us know your opinion by > > Feb 27. It would also be good to hear who is willing to review and/or > > implement or deploy the extension described in the document. > > > > Since we already found that the majority of the f2f participants at our > > IETF97 session like this idea, please do speak up now if you do not agree > > or have serious objections (with explanation of course). > > > > Regards, > > Tianran > > > > _______________________________________________ > > OPSAWG mailing list > > OPSAWG@ietf.org > > https://www.ietf.org/mailman/listinfo/opsawg > > _______________________________________________ > GROW mailing list > g...@ietf.org > https://www.ietf.org/mailman/listinfo/grow > _______________________________________________ > GROW mailing list > g...@ietf.org > https://www.ietf.org/mailman/listinfo/grow
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
