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

From: Jeffrey Haas <[email-masked]>
Date: Tue, 6 Apr 2021 09:09:26 -0400

[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.

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.

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?
- 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.

-- Jeff

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 6 Apr 2021 22:34:26 -0400

Hi Jeff,

Thanks for posting your thoughts. See below.

> that there's some level of applicability for the problem my draft is

I think you are right.

> 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.

>   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.

>   flowspec capability bits proposal can be updated to cover match type for

That seems reasonable.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [email-masked]