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

[wutianhao <[e-mail]>]

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 <[e-mail]>
Sent: Monday, March 18, 2024 12:56 PM
To: Robert Raszuk <[e-mail]>
Cc: Jeff Haas <[e-mail]>; wutianhao <[e-mail]>; idr@ietf. org <[e-mail]>
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 <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> 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=[e-mail]<mailto:[e-mail]>> 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: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
> Sent: 2024年2月29日 17:26
> To: Wanghaibo (Rainsword) <[e-mail]<mailto:[e-mail]>>; Gejun (Jack, BGP) <[e-mail]<mailto:[e-mail]>>; wutianhao <[e-mail]<mailto:[e-mail]>>; Dingxiangfeng <[e-mail]<mailto:[e-mail]>>
> 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
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/idr

_______________________________________________
Idr mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/idr
_______________________________________________
Idr mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/idr