Re: [Idr] 答复: FW: New Version Notification for draft-wu-idr-flowspec-dip-community-filter-00.txt

Robert Raszuk <robert@raszuk.net> Wed, 13 March 2024 09:21 UTC

Return-Path: <robert@raszuk.net>
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 236BFC15106C for <idr@ietfa.amsl.com>; Wed, 13 Mar 2024 02:21:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CAqDj1VIouCi for <idr@ietfa.amsl.com>; Wed, 13 Mar 2024 02:20:58 -0700 (PDT)
Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 177BBC14F5F8 for <idr@ietf.org>; Wed, 13 Mar 2024 02:20:57 -0700 (PDT)
Received: by mail-ed1-x534.google.com with SMTP id 4fb4d7f45d1cf-56647babfe6so7702900a12.3 for <idr@ietf.org>; Wed, 13 Mar 2024 02:20:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; t=1710321656; x=1710926456; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=rUNE8ymN5szMsR7SfwsJGqIwjFTYP0hJ+oznWakV/9g=; b=fFjwfa7N81LtP8G7czAQNMiC0PR7QHuj6zHOtWNfPQcWLpsvFDonWKf7ZTiMMAye8o qmeAa0URqHvUGVpryK6HWoCcjM95qn9sb4T440BFZNXFxFCquxnyS303I7w72C0McxwL 3HEe05KASSog3J3aKfbHwT0t1TH7xuc6/XIOOfpT0AWcPk75KGNK/ZCdTmSTEFpN1I2S mp12amxITg+cufHj8IkdDrijFxPOCVCDxHWHTbC6GfEHSDpxqIBHw7oyfXoZpbERraE6 L667hKufBmxWDu6+hqM8MiG7Prwcxr+m02+BIRcp6pAa9iZbFwkgvrY9xbcvSOju+8BH oR/w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710321656; x=1710926456; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=rUNE8ymN5szMsR7SfwsJGqIwjFTYP0hJ+oznWakV/9g=; b=PNawm3Zal5kzenJQb3K4qZiLELLgSUTdk3+hHuXF9FwytJYCyEa1VBCx8YjVJSJ8DP WLGqrwtpAQcqTZrKdWfFYMUrTm6nvTZ+41ixLYNXHRZ51EnBMF1XH0HjcM/M574yHw43 bWmIFL0XYfTZ65MAoQIpNsYUWqLthzJer2f2STsCSxWNAiLW4ruouNneG4xv3YSuPX9+ lukdCSFQidJFBYLvj5+s3A7Tov0EdARdCGXsDgQIxQeJ4avEdDKFObd0l55yld1EU0wp zUyRS0APTwmL17K4BRxj8X/cAR0/Y0/Nxg1ZzeQhuwlUmu0ZeilDcscf94dPenx3uLXb QmEg==
X-Gm-Message-State: AOJu0YwR9mmNUbLR4UVgsbPtScfe3ubGneiaK0ocYElXcEopRfZ1MG+5 g42Nb/Y3zu6DTNwMMtUT9xG8acEFwygs3XP+DDFdduZ4oNbcPIlyVe2awqkyBBxjpGv3xtT8Nx1 NR+JtArdcuRl42/rANdBF230vE1q77MMEzpd+IZNr//aA4N9P
X-Google-Smtp-Source: AGHT+IFPjXCmDJ9/W60FTxXzxflYwxwXq5TA+qCqiNXbYkyTw0VLnq46apDRdoHa0wlTAh7+siSb+L3mnlpzx0rHtdY=
X-Received: by 2002:a50:c31a:0:b0:567:9306:5d0b with SMTP id a26-20020a50c31a000000b0056793065d0bmr2157732edb.28.1710321655604; Wed, 13 Mar 2024 02:20:55 -0700 (PDT)
MIME-Version: 1.0
References: <1d8a9005350548acae681108370cb22d@huawei.com> <CAOj+MMGZ7jSZPYSPj=dhw7PkkjjKdGH=cT4DqXLdbdeGLQ+oEg@mail.gmail.com> <a054a310c3514cbe9cc765f572fa3760@huawei.com>
In-Reply-To: <a054a310c3514cbe9cc765f572fa3760@huawei.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Wed, 13 Mar 2024 10:20:44 +0100
Message-ID: <CAOj+MMFE1+TtLPqCbOHAW2qCafH_11eTcco3cQ97AuPZS1Dnbw@mail.gmail.com>
To: wutianhao <wutianhao10=40huawei.com@dmarc.ietf.org>
Cc: "idr@ietf.org" <idr@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000bc07b10613874a07"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/bWwefAhFsEzK2m2WaEXVQJBLv1k>
Subject: Re: [Idr] 答复: FW: New Version Notification for draft-wu-idr-flowspec-dip-community-filter-00.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.39
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: Wed, 13 Mar 2024 09:21:02 -0000

Hi,

Community level filtering have nothing to do with data plane. Installing
such components in RIB, FIB, ACL just does not make any sense to me.

Community based filtering is done in BGP application after parsing the
UPDATE messages, I am yet to see BGP processing done in data plane.

So to me this should never go into Flowspec v1.

For Flowspec v2 is the goal is to broaden the scope to use v2 as
generalized routing protocols policy propagation vehicle so be it.

Kind regards,
Robert






On Wed, Mar 13, 2024 at 10:14 AM wutianhao <wutianhao10=
40huawei.com@dmarc.ietf.org> wrote:

> Hi, Robert
>
>
>
> Thank you for your comments.
>
>
>
> This draft is targeting both FlowSpec v1 and FlowSpec v2. We will add a
> section to describe FlowSpec v2 part.
>
>
>
> This component use control plane information need to be delivered to FIB
> as follows:
>
> BGP -> RIB -> FIB
>
> FlowSpec -> ACL
>
>
>
> In data plane, BGP communities and FlowSpec rules can be combined to
> redirect flow.
>
>
>
> It is indeed departure from the original definition of FlowSpec v1. But we
> think that control plane information can be used to reduce ACL usage
> significantly and do not need to change the FlowSpec v1.
>
>
>
> Best regards,
>
>
>
> Tianhao Wu
>
>
>
>
>
> *发件人**:* Robert Raszuk <robert@raszuk.net>
> *发送时间:* 2024年3月5日 4:11
> *收件人:* wutianhao <wutianhao10@huawei.com>
> *抄送:* idr@ietf.org
> *主题:* Re: [Idr] FW: New Version Notification for
> draft-wu-idr-flowspec-dip-community-filter-00.txt
>
>
>
> Hi,
>
>
>
> I am not sure if this is targeting FlowSpec v2 ... but I would like to
> observe that component types as defined in RFC8955 are about data plane.
>
>
>
> You are proposing an addition of a control plane entity - namely BGP
> Community Attribute.
>
>
>
> I understand that you want to recursively result local installation into
> the data plane all destinations which are advertised in BGP with such
> community, but this is a significant departure from the definition of
> FlowSpec v1.
>
>
>
> It is about signalling dynamically a BGP policy which FlowSpec v1 is not
> doing.  With that being said I recommend that if authors of FlowSpec v2 are
> still working on it allowing it to carry BGP policy - then this would be
> the right place to add the proposed encoding into.
>
>
>
> As currently defined - stand alone extension - it does not seems to even
> fit https://www.iana.org/assignments/flow-spec/flow-spec.xhtml.
>
>
>
> Kind regards,
>
> Robert
>
>
>
>
>
> On Mon, Mar 4, 2024 at 11:55 AM wutianhao <wutianhao10=
> 40huawei.com@dmarc.ietf.org> wrote:
>
> Dear all,
>
> We've submitted a new draft: draft-wu-idr-flowspec-dip-community-filter.
>
> This draft specifies a new BGP Flowspec component type to support
> community-level filtering. Flowspec rules can be reduced by using the
> method defining in this draft. It saves a lot of entry spaces on the
> control plane and forwarding plane, and it would greatly simplify the
> operation of the control plane, and the more destination prefixes with the
> same community has, the more obvious the benefit.
>
> Review and comments are welcome.
>
> Best regards,
> Tianhao
>
> -----Original Message-----
> From: internet-drafts@ietf.org <internet-drafts@ietf.org>
> Sent: 2024年2月29日 17:26
> To: Wanghaibo (Rainsword) <rainsword.wang@huawei.com>; Gejun (Jack, BGP) <
> jack.gejun@huawei.com>; wutianhao <wutianhao10@huawei.com>; Dingxiangfeng
> <dingxiangfeng@huawei.com>
> Subject: New Version Notification for
> draft-wu-idr-flowspec-dip-community-filter-00.txt
>
> A new version of Internet-Draft
> draft-wu-idr-flowspec-dip-community-filter-00.txt has been successfully
> submitted by Tianhao Wu and posted to the IETF repository.
>
> Name:     draft-wu-idr-flowspec-dip-community-filter
> Revision: 00
> Title:    Destination-IP-Community Filter for BGP Flow Specification
> Date:     2024-02-28
> Group:    Individual Submission
> Pages:    7
> URL:
> https://www.ietf.org/archive/id/draft-wu-idr-flowspec-dip-community-filter-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-wu-idr-flowspec-dip-community-filter/
> HTMLized:
> https://datatracker.ietf.org/doc/html/draft-wu-idr-flowspec-dip-community-filter
>
>
> Abstract:
>
>    BGP Flowspec mechanism (BGP-FS) propagates both traffic Flow
>    Specifications and Traffic Filtering Actions by making use of the BGP
>    NLRI and the BGP Extended Community encoding formats.  This document
>    specifies a new BGP-FS component type to support community-level
>    filtering.  The match field is the community of the destination IP
>    address that is encoded in the Flowspec NLRI.  This function is
>    applied in a single administrative domain.
>
>
>
> The IETF Secretariat
>
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>