Re: [Idr] Feedback from mike during IETF 119 (was Re: FW: New Version Notification for draft-wu-idr-flowspec-dip-community-filter-00.txt)

Hi Tianhao,

Thanks for your response.

When we build protocol extensions, we need to also consider that they are
mechanisms that can be used more generally and more widely than what one
may assume in the beginning.

Just my 2c

Thanks,
Ketan

On Tue, Mar 19, 2024 at 12:48 PM wutianhao <wutianhao10@huawei.com> wrote:

> Hi Ketan,
>
>
>
> Thank you for your comments.
>
>
>
> I want to first clarify the scenario where this extension is applied. This
> draft is not targeted to DDOS scenario, but to traffic redirections for
> imporving network performance.
>
>
>
> In this scenario, the network operators use Destination-IP-Community
> filters as follows.
>
>
>
> 1. identify which prefixes to be redirected
>
> 2. choose an unused BGP communities for generating FlowSpec rules
>
> 3. announce the BGP updates (destination prefixes are those prefixes) with
> this BGP community
>
>
>
> Thus, the prefixes and communities are planned in advance.
>
>
>
> Hope this answer can solve your problem. Please don't hesitate to contact
> us if you have any further questions.
>
>
>
> Best regards,
>
>
>
> Tianhao Wu
>
>
>
> *From:* Ketan Talaulikar <ketant.ietf@gmail.com>
> *Sent:* Monday, March 18, 2024 12:56 PM
> *To:* Robert Raszuk <robert@raszuk.net>
> *Cc:* Jeff Haas <jhaas@pfrc.org>; wutianhao <wutianhao10@huawei.com>;
> idr@ietf. org <idr@ietf.org>
> *Subject:* Feedback from mike during IETF 119 (was Re: [Idr] FW: New
> Version Notification for draft-wu-idr-flowspec-dip-community-filter-00.txt)
>
>
>
> Hello Authors,
>
>
>
> I am repeating my comments from the IDR session earlier today.
>
>
>
> For Flowspec the larger scale challenge is the resources in the hardware
> for the actual rule - something that this proposal does not alter. The
> FlowSpec route space in the BGP control plane is not really a big deal for
> routers (not when compared to the h/w resources). So, does this really
> solve a real/practical problem?
>
>
>
> By using this mechanism of matching community, both the router and the
> FlowSpec controller is losing control over the number of rules generated.
> Even if there was a cap, it is tricky on what prefixes are picked and what
> happens with there are issues with the setting of these communities. How
> does the FlowSpec controller know which specific destinations are being
> filtered? Is that not important for a deployment - e.g., for DDOS scenario?
>
>
>
> While this proposal sounds interesting, I would suggest to please consider
> the above aspects and at least update the draft to cover those
> considerations.
>
>
>
> Thanks,
>
> Ketan
>
>
>
> On Fri, Mar 15, 2024 at 2:39 PM Robert Raszuk <robert@raszuk.net> wrote:
>
> Hi Jeff,
>
>
>
> So just to make sure we are on the same page.
>
>
>
> Are you saying that it is perfectly ok to turn BGP into a control plane
> filtering protocol pushing BGP configuration (here  policies) around the
> network ?
>
>
>
> Cheers,
>
> R.
>
>
>
>
>
>
>
>
>
>
>
> On Fri, Mar 15, 2024 at 4:29 AM Jeff Haas <jhaas@pfrc.org> wrote:
>
> Tianhao,
>
> While I don’t quite share the same concerns that Robert does, I do have
> concerns about these RIB properties-based filters in terms of filter
> stability and deployment.
>
> Section 6 procedures in RFC 8955 provide an example of RIB interaction,
> albeit only on the flowspec destination component and the RIB-in route
> covering that component. While there may be some instability of the route,
> there is some reasonable expectation that stability is the intent for that
> procedure.
>
> In the case of the AS filter, the origin as is usually stable.
>
> Communities can be very unstable, especially for the set of candidate
> routes for the loc-rib entry.
>
> Please consider discussing this point during your presentation.
>
> Jeff.
>
>
> Sent from my iPad
>
> > On Mar 4, 2024, at 05:55, 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
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
>