Re: [Idr] Applicability of flowspec bits proposal on draft-ietf-idr-flowspec-nvo3

[Donald Eastlake <[e-mail]>]

Hi Jeff,

Thanks for posting your thoughts. See below.

On Tue, Apr 6, 2021 at 8:47 AM Jeffrey Haas <[e-mail]> wrote:
>
> [Speaking as an individual contributor.]
>
> Donald, and co-authors of draft-ietf-idr-flowspec-nvo3,
>
> While I was working through the scenarios for draft-haas-bgp-flowspec-bits
> as a mechanism to permit incremental deployment of new Flowspec features, I
> hadn't given much thought to the impacts on the Flowspec for nvo3 draft.
>
> During IETF-110, Donald commented that the nvo3 proposal uses a different
> SAFI and thus likely didn't have the problems the flowspec bits proposal is
> intended to address.  Upon reviewing the Flowspec for nvo3 proposal, I think
> that there's some level of applicability for the problem my draft is
> intended to address.

I think you are right.

> In the nvo3 proposal, the flowspec NLRI consists of:
>
>   Length, tunnel type, flags +
>   RD (optional) +
>   Outer Flowspec +
>   Tunnel Header Flowspec +
>   Inner Flowspec (optional)
>
> The Tunnel Header Flowspec does indeed use a more appropriate TLV
> format that addresses the main extensibility issue for Flowspec; the
> missing and implied length field for many components but no length for
> unknown components.  However, it contains potentially two additional
> Flowspecs using the existing encoding rules.
>
> Presuming that flowspec v2 isn't done prior to flowspec nvo3 shipping, this
> means that some form of incremental deployment issue may exist if there's a
> desire for a new feature to be used for matching outer or inner flowspecs.

Yup.

And this applies to a slightly lesser extent to
draft-ietf-idr-flowspec-l2vn because it optional contains an IPv4 or
IPv6 flowspec.

> Clearly this isn't a problem today.  But it does raise some interesting
> issues:
> - If something like the flowspec capability bits were used, does it apply to
>   both the inner and outer flowspec fields?

Something like flowspec capabilities should apply to any flowspec of
the type for which their are capability bits.

> - The current flowspec capability bits proposal isn't intended to handle the
>   Tunnel Header Flowspec, which is in its own registry.  It likely does NOT
>   need to be used for incremental deployment purposes.  However, the second
>   motivation in the flowspec capability bits draft is signaling support for a
>   component type.  If only a subset of tunnel match types is available on a
>   platform, would a similar mechanism be useful?  If so, perhaps the
>   flowspec capability bits proposal can be updated to cover match type for
>   tunnel types as well.

That seems reasonable.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   [phone] (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [e-mail]

> -- Jeff