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

Jeffrey Haas <jhaas@pfrc.org> Tue, 06 April 2021 12:47 UTC

Return-Path: <jhaas@slice.pfrc.org>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E38DA3A20BA; Tue, 6 Apr 2021 05:47:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uKCk1eG3lzgG; Tue, 6 Apr 2021 05:47:35 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 745B13A204A; Tue, 6 Apr 2021 05:47:07 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id AC3B11E459; Tue, 6 Apr 2021 09:09:26 -0400 (EDT)
Date: Tue, 6 Apr 2021 09:09:26 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: Donald Eastlake <d3e3e3@gmail.com>, draft-ietf-idr-flowspec-nvo3@ietf.org
Cc: idr@ietf.org
Message-ID: <20210406130926.GO31047@pfrc.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/oLTOcI_h0M39vlwIebj91JYmuxs>
Subject: [Idr] Applicability of flowspec bits proposal on draft-ietf-idr-flowspec-nvo3
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Apr 2021 12:47:44 -0000

[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