Re: [Idr] Benjamin Kaduk's Discuss on draft-ietf-idr-flow-spec-v6-19: (with DISCUSS and COMMENT)

Benjamin Kaduk <kaduk@mit.edu> Mon, 09 November 2020 20:58 UTC

Return-Path: <kaduk@mit.edu>
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 0D39D3A0AD3; Mon, 9 Nov 2020 12:58:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ZQUKUoC3VDMO; Mon, 9 Nov 2020 12:58:18 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01C913A135F; Mon, 9 Nov 2020 12:58:17 -0800 (PST)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 0A9Kw6Cg032514 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 9 Nov 2020 15:58:14 -0500
Date: Mon, 9 Nov 2020 12:58:05 -0800
From: Benjamin Kaduk <kaduk@mit.edu>
To: Christoph Loibl <c@tix.at>
Cc: Erik Kline <ek.ietf@gmail.com>, Robert Raszuk <robert@raszuk.net>, "idr@ietf. org" <idr@ietf.org>, The IESG <iesg@ietf.org>, draft-ietf-idr-flow-spec-v6@ietf.org, idr-chairs@ietf.org
Message-ID: <20201109205805.GY39170@kduck.mit.edu>
References: <160442801878.21168.17412260809706411361@ietfa.amsl.com> <3C5BB93B-5E8C-42AD-B1C1-F96C359EC110@tix.at> <20201104163619.GR39170@kduck.mit.edu> <CAOj+MMENNbMSs6hDJ9SvEinKd5nVnUWB5EPWGbCvKysyBms9Ug@mail.gmail.com> <CAMGpriW2vQYijU_KLVqYG=dnqoH_0yvuRAOODAWib726dHNYtQ@mail.gmail.com> <CAOj+MMG4UmSrdkAamgUAcTx4kVCqoFmPfvfMXzbWOEEJZwRh6w@mail.gmail.com> <CAMGpriUQU5JbsZ+8CUcPCJQM+U0R0EcMa-Riy-Sf7YEVuo7wnw@mail.gmail.com> <5D2A4698-A69C-4CD3-B44C-BA82A2664DC5@tix.at>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <5D2A4698-A69C-4CD3-B44C-BA82A2664DC5@tix.at>
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/a6bFf6kaPuEGTwVLfxVyoJmj-kY>
Subject: Re: [Idr] Benjamin Kaduk's Discuss on draft-ietf-idr-flow-spec-v6-19: (with DISCUSS and COMMENT)
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: Mon, 09 Nov 2020 20:58:20 -0000

On Mon, Nov 09, 2020 at 12:05:09PM +0100, Christoph Loibl wrote:
> Hi,
> 
> I am reading thru the discussion and trying to summarize + my comments:
> 
> > On 09.11.2020, at 05:35, Erik Kline <ek.ietf@gmail.com> wrote:
> > Whether randomized or not, I would imagine the use of flow label matching would be more the exception than the rule.
> 
> 
> ack.
> 
> > On 09.11.2020, at 05:32, Benjamin Kaduk <kaduk@mit.edu> wrote:
> > 
> >> On Sat, Nov 07, 2020 at 12:45:09PM +0100, Robert Raszuk wrote:
> >> Ok 3 octets to keep byte boundary sounds reasonable indeed.
> > 
> > Well, the
> > https://tools.ietf.org/html/draft-ietf-idr-rfc5575bis-27#section-4.2.1.1
> > 'len' encoding options don't give a 3-byte option for the value field.
> > Which is why I was assuming 4-bytes.
> > 
> > -Ben
> 
> Correct, if we want a 3 octets (or 20-bits) length we need to “re-invent the wheel” = we need to add a new “operator” that supports 3-byte length etc. Not only the document needs to extended, but also implementations need to take care of yet another operator encoding format. 

Exactly, and that is (IMO clearly) something for flowspec v2 if at all, not
this document.

> We can however easily require the length of the flow-label field to be 4-octets:
> 
> 	Type 13 component values MUST be encoded as 4-octet quantity 
>         (numeric_op len=10).
> 
> But this is an exception because we usually use SHOULD there in rfc5575bis (only because of historical incompatibilities that could not be changed in the -bis though), and I am not sure if adding this special case really makes it better (since it does not reduce complexity).

There do seem to be a couple "MUST"s as well (but maybe just for fields
that are smaller than 1 octet or flags, so the reasoning is a little
different than for the case we're looking at).  I don't think this issue is
significant enough that we need to diverge from 5575bis (and 5575 itself),
though, and I do see what you mean about "SHOULD" being most common.

> How can we continue?

I think it would be okay to just drop the specific mention of 1- and 2-byte
encoding for the flow label match, so we have "[t]ype 13 component values
SHOULD be encoded as 4-byte quantities (len=10)".

I'm of course happy to hear other suggestions as well!

Thanks,

Ben