Re: [OPSAWG] [GROW] WG LC for draft-ietf-opsawg-ipfix-bgp-community

Jeffrey Haas <jhaas@pfrc.org> Wed, 21 February 2018 17:46 UTC

Return-Path: <jhaas@slice.pfrc.org>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CB1D12D890; Wed, 21 Feb 2018 09:46:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 qlaJeygFkWEi; Wed, 21 Feb 2018 09:46:11 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 9321E1276AF; Wed, 21 Feb 2018 09:46:11 -0800 (PST)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 007EA1E31F; Wed, 21 Feb 2018 12:52:00 -0500 (EST)
Date: Wed, 21 Feb 2018 12:52:00 -0500
From: Jeffrey Haas <jhaas@pfrc.org>
To: Paolo Lucente <paolo@ntt.net>
Cc: Tianran Zhou <zhoutianran@huawei.com>, "grow@ietf.org" <grow@ietf.org>, "draft-ietf-opsawg-ipfix-bgp-community.all@ietf.org" <draft-ietf-opsawg-ipfix-bgp-community.all@ietf.org>, opsawg <opsawg@ietf.org>
Message-ID: <20180221175200.GD16383@pfrc.org>
References: <BBA82579FD347748BEADC4C445EA0F21A6D435FA@NKGEML515-MBX.china.huawei.com> <3D98E8D0-1448-4830-B87E-409132F64F9D@ntt.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <3D98E8D0-1448-4830-B87E-409132F64F9D@ntt.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/HUWo8mCe_nzvfON9v249SOQdGsI>
Subject: Re: [OPSAWG] [GROW] WG LC for draft-ietf-opsawg-ipfix-bgp-community
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Feb 2018 17:46:13 -0000

Paolo,

I don't speak for the authors here, just my opinion.

On Wed, Feb 21, 2018 at 05:37:59PM +0100, Paolo Lucente wrote:
> One concern is that this looks a very isolated effort, ie. why communities
> and not as-path? I remember the story of this draft, it comes from field
> needs and that is in short the answer to the cherry-picking.

Partly, the usual information that people want from flow for AS information
(origin or peer AS) is already available.  The full path, no.  One certainly
could make the argument that the full path could be sent.

Since flow analyzers mostly want the active route's properties, having the
communities to go along with it is helpful.

> The second concern, the one going the opposite direction than the previous
> one, is that in future it could be tempting for somebody to repeat the
> story of this draft and add support for as-paths and/or other BGP
> attributes in IPFIX: here i see a mix-up among the original intent to
> report on data plane information with the reporting on control-plane (BGP)
> information: in other words, is (potentially) encapsulating (all) BGP
> attributes for every sampled packet/flow a valid idea? For example, is not
> BGP/BMP peering at the IPFIX collector itself much more efficient instead
> of moving control-plane info over and over again? At this propo, the
> motivation that roughly 20 years ago it was decided to make source and
> destination ASNs part of NetFlow v5 (and few years later BGP next-hop was
> added as part of NetFlow v9) is a bit weak, IMO; maybe there is more to
> it, and i’d be happy to hear about it. 

Analyzers still find it handy to have source and destination AS.  This in
some cases avoids lag issues due to propagation of sniffed BGP (via iBGP
peering or BMP) for the sampling router.  Additionally, a lot of useful data
can be gathered without having BGP at all at the analyzer.

I do understand the concern, but personally find it unlikely that this is
the feared "slippery slope". [1]

-- Jeff

[1] https://en.wikipedia.org/wiki/Slippery_slope