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

[Jeffrey Haas <[e-mail]>]

[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