Re: [Idr] WG LC - draft-ietf-idr-flowspec-nvo3-12 - Technology only (2/4/2020 to 2/18/2020).

Donald Eastlake <> Wed, 10 February 2021 01:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 647C93A1187 for <>; Tue, 9 Feb 2021 17:53:18 -0800 (PST)
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, 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 qVqb9_Cmx67p for <>; Tue, 9 Feb 2021 17:53:17 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::d34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 480113A1181 for <>; Tue, 9 Feb 2021 17:53:17 -0800 (PST)
Received: by with SMTP id s24so281834iob.6 for <>; Tue, 09 Feb 2021 17:53:17 -0800 (PST)
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=4HUQtxsAw2EKLWL4NYbvEDjv8xHY0ZvQ3g5QiS/iCtY=; b=URerlD5zGwyhpAnkn+JtkF9ATuJtd2U520GXdfk5l+eNvdgjIR+TeJRKRccLybFArp 6q5ru/Qnvi7P80ekMLy87qpVvqmGTV8zwrxLRMB36TZLmXqmq7sBymIvDcG9rdu8++4J Df03tT9/SnQQoNNdh8DRjqFJNrBMnkZ+PLfjVwBwq76X4R0hZmu51MP/VJ2Ma7WAPmQA sHuXxL80BYf1kMB/01ika+n6mxt+b4e1ppn0Ym1globLJ3LIfGCORIoJTDZGZZ7JtSAU 5lrTNm0E1Q1IJ8VVOuPKeBmmr4CDfHoD8DpbRiJdELbxfh+KpOSRkU3OJXGin9uh9ein pt1w==
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=4HUQtxsAw2EKLWL4NYbvEDjv8xHY0ZvQ3g5QiS/iCtY=; b=PPiqpMEqUiYJvn7LaBJEGDuCnNMnEW6Nb9tg0VFU3r6t6OZJicjhlmNH+eq4PJANsj ayFuWKopIxNIhNEe2Qty5Nq2sxcjpjIxX9PqvyjZ5/qZ6c/MvTYXXZGciW5AAp5g7JKD U0yhdw3ovDT7wX2AZkWHzrndRuino7eaPJ0/K0Tt1712kKWvYnLQFY5n9GsME6CiimKh 0Jq/Qn5Gji51ddAK2wD6GDPdfkLOniHFlhspCVP3GRlhDdQyrsOyT7GOcR7FQZHGbxLc afPQfELwLj3Q5bxbZDsg5kK0BbuvEAYcsVybyQ0QNuKkM2ijicapipEeAS9OshSKPq5y zhvQ==
X-Gm-Message-State: AOAM533mv9KkM+q0Hj0Ui0R9CDkTUyiem31221yu47whNOCiqihtMdOx cnr44CGl0m+rLm3lkv6GNctZvrUGn8Gr96O04F8=
X-Google-Smtp-Source: ABdhPJwckBhlj7qnS/Qa+tuMLA6vqmYS6I/5z+IuhEBge5OwFLNf2fQb9DA7x3ACE1mREDlHblSMenIrZRZtQ3wH35s=
X-Received: by 2002:a05:6638:388e:: with SMTP id b14mr821531jav.96.1612921996265; Tue, 09 Feb 2021 17:53:16 -0800 (PST)
MIME-Version: 1.0
References: <012d01d6fb0d$b50468c0$1f0d3a40$>
In-Reply-To: <012d01d6fb0d$b50468c0$1f0d3a40$>
From: Donald Eastlake <>
Date: Tue, 09 Feb 2021 20:53:05 -0500
Message-ID: <>
To: Susan Hares <>
Cc: "idr@ietf. org" <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [Idr] WG LC - draft-ietf-idr-flowspec-nvo3-12 - Technology only (2/4/2020 to 2/18/2020).
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, 10 Feb 2021 01:53:18 -0000


I am a co-author and support approval of this draft for standards
track publication. See below

On Thu, Feb 4, 2021 at 10:52 AM Susan Hares <> wrote:
> Greetings:
> This begins a modified draft-ietf-idr-flowspec-nvo3-12.txt.
> It is a modified WG LC because:
> 1) the WG still has to discussion where we make the cutoff for flow-specification v2,
> 2) there are no implementation for this WG LC
> This WG LC should examine the following things:
> 1.) Does WG to standardize this technology with the IPR Statement (which appeared in 5/8/2020 after a modification of the draft)?

Yes. (Note this is the same situation as with
draft-ietf-idr-flowspec-l2vpn which has already been approved by the

> 2) Is this approach to flow-specification for tunnels ready for standardization?

I believe so.

> 3) Would this technology inter-work with tunnels created by draft-ietf-idr-tunnel-encap-22.txt?

I have reviewed draft-ietf-idr-tunnel-encap-22.txt. It is not clear to
me how idr-flowspec-nvo3 draft could fail to "inter-work" with the
idr-tunnel-encap draft. idr-tunnel-encap specifies an attribute and
community to invoke tunneling for certain traffic. idr-flowspec-nvo3
specifies how to match on certain tunnelled traffic and perform some
actions on such traffic.

> 4) Should this technology wait for a flow-specification v2?

The situation is pretty much the same, as far as I can see, as in RFC
8956 and draft-ietf-idr-flowspec-l2vpn. flow-specification v2 will
have to take such things into account whether or not this draft

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

> Cheerily, Sue