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

Donald Eastlake <> Wed, 07 April 2021 02:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DA00D3A3B22; Tue, 6 Apr 2021 19:34:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.848
X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CjDbgczyOzcc; Tue, 6 Apr 2021 19:34:39 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 940133A3B24; Tue, 6 Apr 2021 19:34:39 -0700 (PDT)
Received: by with SMTP id j26so12569164iog.13; Tue, 06 Apr 2021 19:34:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=B5/4So/r1t+j3CDnbB0Vw0dUOgBieuupFE3jhM0c7Ss=; b=mXCetBEZ91lrvmGqbeXeuo80kkT/lHZVZptTJrtwrmMhpIP8zvlEjNcfvg4I5ZAOlY LtLc6axUaiBzOGmBCjq5IhpFCcgLZeOKVJSalgZs/gq40hgQ23Mw95K68SieRxCpNoMA Xk3fMyZJXwH7J4u45AT96T/fUC+3d7JazPxWkAsYyrJEamF6eR7M0w9HcmULIpEh57ua A3em4aTcNpA+3qv3E1U0UsDnpXzZM3gBCoVL/e4PgrAFMbF/axs3bX/Yh/HPrX6BU7gy 0r3yiT506V5Z9+KBco9zpy7BT1rTJ1c7MrHUmQqLyQw218rVsrqJx97yRASptbimj8nc 9fsg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=B5/4So/r1t+j3CDnbB0Vw0dUOgBieuupFE3jhM0c7Ss=; b=lpePyQYwPrYxEoBkpPEMh6JFCAFdeQQBXHiFTvJKpY5Myw8V7amGcTeoYe1l7QHjte xQz7GV35ttNJ9D/3+ZQGmCIiB9afv2efb7fmN6M70Hpw5eFmQl5U8p1KHx6H2jVOsFhb krXoA1EwNnjpR1XMPoeKepueJCsrYaW43vpohyWb/vxTTJ305SPzQNcYn3EpW5KX6Guk OApvY/nx2OXTb7/NgKkAFeD95qNbrlANL6kZZ6SBqvgTQXW7lonASCP+n3Oh5nH00IUS Fd95IHWpEahOa6NrkCcYAkzM9ZgVTd7eHvaSqiN8YKtUBXDinHk1KaoYa+PtOquI9q7C kYNA==
X-Gm-Message-State: AOAM53370dxYG2ESKy+rqmshzi58/sfjsMEfke3NXi121kspVICr23Cz MUtrUJbZaT3X6yrWwLwmPJTTO8y5MoHkQwoWQM1WKZc3BYA=
X-Google-Smtp-Source: ABdhPJx0fW6XQ0xC//a7CCojNsmMfa/GrZbNWdnfGTjtfZc6aaY/o+2knrwVQrh39ciNOAJZPgKm4gz8aRqPKJkMhLo=
X-Received: by 2002:a02:94a9:: with SMTP id x38mr1169573jah.50.1617762877590; Tue, 06 Apr 2021 19:34:37 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Donald Eastlake <>
Date: Tue, 6 Apr 2021 22:34:26 -0400
Message-ID: <>
To: Jeffrey Haas <>
Cc:, "idr@ietf. org" <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [Idr] Applicability of flowspec bits proposal on draft-ietf-idr-flowspec-nvo3
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 07 Apr 2021 02:34:45 -0000

Hi Jeff,

Thanks for posting your thoughts. See below.

On Tue, Apr 6, 2021 at 8:47 AM Jeffrey Haas <> 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.


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.

 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA

> -- Jeff