Re: [Idr] AD Review of draft-ietf-idr-bgp-flowspec-oid-12

[Alvaro Retana <[e-mail]>]

On February 4, 2021 at 7:18:51 PM, Juan Alcaide wrote:


Juan:

Hi!

> I'm not sure if I understand 100% your comments about the abstract. The
> point is for R1 to validate the flowspec route when the ucast best-match
> route is advertised by ASBR2
>
> The solution or hack suggested in the abstract is for ASB1 to advertise the
> flowspec route. So the originator R1 sees is ASBR1 (both for the ucast
> best-match and the flowspec route). We don't have to do any validation for
> an ebgp received route.
>
> IT's assumed that the same AS where the validation rule it's taking place
> is where the flowspec rule is originated. Perhaps that's the confusion.
>
> R1 -ibgp-- ASBR1--ebgp-ASBR2

That is not what I took away from the current abstract. :-(


> We could expand the abstract to make it more clear. Something like the below

Yeah...that explains it better.

I think the Abstract tries to cram too much in.  Maybe put the
explanation (and a little picture) in the Intriduction instead, and
focus on a simple explanation of what the draft does (not details of
the type of problemts).

Thanks!

Alvaro.



> This document describes a modification to the validation procedure defined
> for the dissemination of BGP Flow Specifications. The dissemination of BGP
> Flow Specifications requires that the originator of the Flow Specification
> matches the originator of the best-match unicast route for the destination
> prefix embedded in the Flow Specification. This allows only BGP speakers
> within the data forwarding path (such as autonomous system border routers)
> to originate BGP Flow Specifications. This creates an operational problem
> when the BGP Flow Specifications is originated within the same AS than the
> speakers performing the validation rules. It could be possible to
> disseminate each Flow Specification directly from border routers within the
> AS (i.e. each Flow Specification could be advertised from the same border
> from where the best-match unicast route is received). But this approach
> would be operationally cumbersome in an autonomous system with a large
> number of border routers having complex BGP policies. The modification
> proposed herein enables Flow Specifications to be originated from a
> centralized BGP route controller, that can be positioned any place within
> the AS.