Re: [Idr] WG adoption for draft-haas-flowspec-capability-bits - 3/30 to 4/13

[Robert Raszuk <[e-mail]>]

Hi,

I have a question on how practical this proposal is.

Fundamental problem with today's BGP capabilities is that the information
is only known to the peer.

So if I inject flowspec rule from behind the RR the RR will suppress some
updates but:

* sender will have no clue about it
* any other flow spec BGP speaker which supports request filtering down the
BGP path will never get the chance to receive and apply the filter.

Both are IMHO bad. The latter is in fact directly against flowspec spirit
to apply filtering as close to the src even if hops on the way are not
capable of doing so.

So I am yet to be convinced this proposal is useful.

Today as a general rule if a router does not support an extension received
via flowspec it just does not apply it but still can happily propagate the
update down the road.

Even if one is to use flowspec for config distribution (aside the
discussion if this is a good or bad idea) the sender behind RR or in
different ASN under the same org will never be sure if some extensions are
supported or not by the intended receiver.

I think what we have here on the table is an illustration about the growing
need for domain wide (or set of domains under the same admin) capability
distribution such that all BGP speakers could advertise their
capabilities to interested parties. A bit broader than flowspec, but could
be useful here.

Cheers,
R.

On Tue, Mar 30, 2021 at 3:33 PM Susan Hares <[e-mail]> wrote:

> This is a Working Group adoption call for
> https://tools.ietf.org/html/draft-haas-flowspec-capability-bits
>
> The draft suggests a mechanism to address our incremental deployment issues
> for BGP Flowspec.
>
> As you discuss this mechanism, there are 3 questions to consider:
>
> 1) Is this document clear about the proposal?
>
> 2) Do you think we should do this with Flow Specification v2?
> Or should we do this instead of Flow Specification v2?
>
> 3) Will this help operational networks?
>
> Cheerily, Susan Hares
>
>
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>