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

[Robert Raszuk <[e-mail]>]

Hi Jeff,

Looks like we have converged.

Would it be possible to include your below sentence explicitly/verbatim in
the draft:

"It is also an option for an implementation that understands a new component
that doesn't want to implement it in forwarding to advertise support for
that component and propagate it even if it doesn't locally use it. "

With that I am happy as that was my point. And of course anyone is free to
do what they like (both implementation and operation wise). The draft/rfc
will only provide options.

Cheers,
R.






On Thu, Apr 8, 2021 at 2:24 AM Jeffrey Haas <[e-mail]> wrote:

> On Thu, Apr 08, 2021 at 12:30:18AM +0200, Robert Raszuk wrote:
> > You say: "So, it's a filter against NLRI that have unsupported component
> > types."
> >
> > I say: There is a significant difference between hardware support of a
> > given filtering type and BGP ability to recognize it. And that is not
> > reflected in the draft. Worse both are made equal.
> >
> > The deployment I am worried about is that lack of hardware support or
> > perhaps even configuration protecting router to dynamically install some
> > filters will trigger no capability to be sent hence in spite of software
> > fully capable of parsing the entire "new" NLRI such BGP UPDATE will not
> be
> > received. If not received it will not be propagated to peers (say EBGP
> > peers) hence the end effect of flowspec will be broken.
>
> Actually, it is reflected in the draft.
>
> : 4.  Restricting BGP Flowspec Components in a Deployment
> :
> :    The filtering components specified in [RFC8955] are well supported in
> :    implementations of the RFC.  However, as new platforms work to
> :    support not only this existing RFC, but future features,
> :    implementations may be unwilling or unable to support the packet
> :    forwarding behaviors for a given component type.  The Flowspec
> :    Capability Bits provides the ability for an implementation to limit
> :    what forms of filtering are executed by the BGP Speaker.
>
> It was also part of the presentation.
>
> I acknowledge that you might not like that as a feature.
>
> It is also an option for an implementation that understands a new component
> that doesn't want to implement it in forwarding to advertise support for
> that component and propagate it even if it doesn't locally use it.
>
> This is no worse than policy.
>
> It's also not a detail I'm set on as a key feature of the draft.  The core
> of the proposal is to deal with incremental deployment of new components.
> And that said, even if you put into the draft, "If you don't want to use it
> but understand it, advertise support for propagation purposes."
>
> Someone will still use it for filtering.  I've at least noted that will
> happen up front.
>
> We can perhaps have the domain discussion this implies in the thread Jakob
> has forked.
>
> -- Jeff
>