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

"lizhenqiang@chinamobile.com" <lizhenqiang@chinamobile.com> Mon, 20 February 2017 08:58 UTC

Return-Path: <lizhenqiang@chinamobile.com>
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 6404A128BA2; Mon, 20 Feb 2017 00:58:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.59
X-Spam-Level:
X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 ODsUNf_mhvww; Mon, 20 Feb 2017 00:58:33 -0800 (PST)
Received: from cmccmta1.chinamobile.com (cmccmta1.chinamobile.com [221.176.66.79]) by ietfa.amsl.com (Postfix) with ESMTP id F219512706D; Mon, 20 Feb 2017 00:58:31 -0800 (PST)
Received: from spf.mail.chinamobile.com (unknown[172.16.121.17]) by rmmx-syy-dmz-app02-12002 (RichMail) with SMTP id 2ee258aaafb0d4b-061ae; Mon, 20 Feb 2017 16:58:24 +0800 (CST)
X-RM-TRANSID: 2ee258aaafb0d4b-061ae
X-RM-SPAM-FLAG: 00000000
Received: from cmcc-PC (unknown[221.130.253.135]) by rmsmtp-syy-appsvr09-12009 (RichMail) with SMTP id 2ee958aaafaefa8-27ea6; Mon, 20 Feb 2017 16:58:23 +0800 (CST)
X-RM-TRANSID: 2ee958aaafaefa8-27ea6
Date: Mon, 20 Feb 2017 16:58:32 +0800
From: "lizhenqiang@chinamobile.com" <lizhenqiang@chinamobile.com>
To: "Paolo Lucente" <paolo@ntt.net>
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>
X-Priority: 3
X-Has-Attach: no
X-Mailer: Foxmail 7, 2, 7, 164[cn]
Mime-Version: 1.0
Message-ID: <2017021710323644287217@chinamobile.com>
Content-Type: multipart/alternative; boundary="----=_001_NextPart511787134451_=----"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipfix/p5tDMAiyxEKs2-Bnebbky0U-n3M>
Cc: opsawg <opsawg@ietf.org>, opsawg-chairs <opsawg-chairs@ietf.org>, grow <grow@ietf.org>, "ipfix@ietf.org" <ipfix@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: Mon, 20 Feb 2017 08:58:36 -0000

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


lizhenqiang@chinamobile.com
 
From: Paolo Lucente
Date: 2017-02-17 06:52
To: lizhenqiang
CC: zhoutianran; opsawg; opsawg-chairs; grow; ipfix@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, lizhenqiang@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-bounces@ietf.org] On Behalf Of Ignas Bagdonas
> Sent: Tuesday, February 14, 2017 9:46 PM
> To: Tianran Zhou <zhoutianran@huawei.com>;
> Cc: opsawg@ietf.org; opsawg-chairs@ietf.org; grow@ietf.org grow@ietf.org <grow@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
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow
> _______________________________________________
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow