Re: [Idr] WG LC draft-ietf-idr-flowspec-path-redirect-10.txt [11/17/2019 to 12/2/2019]

Jeffrey Haas <jhaas@pfrc.org> Mon, 02 December 2019 17:25 UTC

Return-Path: <jhaas@slice.pfrc.org>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57B6A1200C3 for <idr@ietfa.amsl.com>; Mon, 2 Dec 2019 09:25:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] 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 34sGo7uLQ0Xb for <idr@ietfa.amsl.com>; Mon, 2 Dec 2019 09:25:58 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 50951120099 for <idr@ietf.org>; Mon, 2 Dec 2019 09:25:58 -0800 (PST)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 4C6511E2F5; Mon, 2 Dec 2019 12:30:10 -0500 (EST)
Date: Mon, 02 Dec 2019 12:30:09 -0500
From: Jeffrey Haas <jhaas@pfrc.org>
To: Robert Raszuk <robert@raszuk.net>
Cc: "Van De Velde, Gunter (Nokia - BE/Antwerp)" <gunter.van_de_velde@nokia.com>, Sue Hares <shares@ndzh.com>, "idr@ietf.org" <idr@ietf.org>
Message-ID: <20191202173009.GH18175@pfrc.org>
References: <016501d59dd2$e5458850$afd098f0$@ndzh.com> <D0AA5E62-4AE5-43A5-BA23-E66D98AF657B@pfrc.org> <AM6PR07MB482356A327D714512EBAF2DBE0460@AM6PR07MB4823.eurprd07.prod.outlook.com> <CAOj+MMF5SXRuQ-KETkJMRQV4uu5LZyK75AKrKiUMEjpBA7d9ow@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAOj+MMF5SXRuQ-KETkJMRQV4uu5LZyK75AKrKiUMEjpBA7d9ow@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/Vfj1Zt-c-Axjd72geJfk_gzY4Ek>
Subject: Re: [Idr] WG LC draft-ietf-idr-flowspec-path-redirect-10.txt [11/17/2019 to 12/2/2019]
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Dec 2019 17:25:59 -0000

Robert,

On Fri, Nov 29, 2019 at 10:34:26AM +0100, Robert Raszuk wrote:
> Gunter,
> 
> To your and Jeff's point regarding multiple redirect rules I have a bit
> different perspective.
> 
> First let's observe that redirect could be realized in two forms (both are
> valid and used in practice):
> 
> -A- redirect of the original flow
> -B- redirect of copy of the flow
> 
> See while in -A- clearly one redirect must be used, in -B- on the
> other hand multiple redirects should be supported. One span, one security
> TAP, one TCP analyzer etc ...
> 
> Your draft defines -A-. To add -B- all what is needed is just one bit flag.
> 
> Would you consider it ?

We had a bit of this discussion as part of the redirect-to-ip draft.  I
believe our discussion yielded that while we liked the idea and saw exactly
the types of behaviors of possible benefit, we also found it unlikely that
we'd get proper hardware support to do a copy to multiple destinations.

I know similar issues complicate most hardware implementations of
ipfix/netflow from past experience.

Somewhat similar to the flow analysis case, it's common to have a device act
as the primary receiver of such a flow to replicate it to the devices of
interest so as to offload the work from the forwarding linecards.

-- Jeff