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

Paolo Lucente <> Thu, 16 February 2017 22:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2C37912955E; Thu, 16 Feb 2017 14:52:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.936
X-Spam-Status: No, score=-1.936 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WrCN4yc5_JmP; Thu, 16 Feb 2017 14:52:37 -0800 (PST)
Received: from ( [IPv6:2001:418:3ff:5::26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3176D124281; Thu, 16 Feb 2017 14:52:37 -0800 (PST)
Received: by with esmtpsa (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.88) (envelope-from <>) id 1ceUue-0003og-5a (; Thu, 16 Feb 2017 22:52:33 +0000
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: text/plain; charset="us-ascii"
From: Paolo Lucente <>
X-Priority: 3
In-Reply-To: <>
Date: Thu, 16 Feb 2017 23:52:23 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <>
X-Mailer: Apple Mail (2.3124)
Archived-At: <>
X-Mailman-Approved-At: Thu, 16 Feb 2017 20:41:16 -0800
Cc: opsawg <>, opsawg-chairs <>, grow <>, "" <>
Subject: Re: [IPFIX] [GROW] [OPSAWG] WG adoption poll for draft-li-opsawg-ipfix-bgp-community-02
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IPFIX WG discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 16 Feb 2017 22:54:52 -0000


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


> On 16 Feb 2017, at 04:15, 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 [] On Behalf Of Ignas Bagdonas
> Sent: Tuesday, February 14, 2017 9:46 PM
> To: Tianran Zhou <>
> Cc:;; <>
> 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)
> >
> >
> > 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
> >
> >
> _______________________________________________
> GROW mailing list
> _______________________________________________
> GROW mailing list