From nobody Mon Nov 9 03:05:31 2020 Return-Path: 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 C3FB33A0658; Mon, 9 Nov 2020 03:05:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tix.at 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 9Yb2Xl0tzxn6; Mon, 9 Nov 2020 03:05:23 -0800 (PST) Received: from mail.fbsd.host (mail.fbsd.host [IPv6:2001:858:58::22]) (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 7749E3A0EA8; Mon, 9 Nov 2020 03:05:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tix.at; s=rev1; h=References:To:Cc:In-Reply-To:Date:Subject:Mime-Version:Content-Type :Message-Id:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=IIiC22WrMaKSiEV16aTHWqVA/r1k2wLSM/vg6r9etn4=; b=dmJAfQlViTv1gcnIiUTDCNSPuN Fxg1MNava1xpEFX5wXDYJ6pnJq8hvp44F4uYLZQPhgwTY2YYDUmCPwGFq/RKptVq5tmGGbsghk0nB IMRPQMuhGZpjpGjVcvM3JHSBNJT5FvUwzPbbYGB1tebfPX4IduBvrPoeJPyfFGA+2vqyjy8dMTSnv awgXQTB7eGpsyQyoDWQkZh+jiLoYf1khqd1ngnJbS94CT9qLXqKi+gYKWAvXH+ILBuTtKSXskk0/g GjJRSPScu97Ro8kfxqAx8xxtbd8n12MRREmnm7NC28U2ZulKR3T2AuGF/u21+FlK/ekpJ1MLKMU07 SPylyhYg==; Received: from 80-110-113-91.cgn.dynamic.surfer.at ([80.110.113.91] helo=[192.168.64.148]) by mail.fbsd.host with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1kc4z2-00024p-3R; Mon, 09 Nov 2020 12:05:12 +0100 From: Christoph Loibl Message-Id: <5D2A4698-A69C-4CD3-B44C-BA82A2664DC5@tix.at> Content-Type: multipart/alternative; boundary="Apple-Mail=_70371D62-E66B-4312-8CAA-81C92965D02C" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Mon, 9 Nov 2020 12:05:09 +0100 In-Reply-To: Cc: Robert Raszuk , Benjamin Kaduk , "idr@ietf. org" , The IESG , draft-ietf-idr-flow-spec-v6@ietf.org, idr-chairs@ietf.org To: Erik Kline References: <160442801878.21168.17412260809706411361@ietfa.amsl.com> <3C5BB93B-5E8C-42AD-B1C1-F96C359EC110@tix.at> <20201104163619.GR39170@kduck.mit.edu> X-Mailer: Apple Mail (2.3608.120.23.2.4) X-Scanned-By: primary on mail.fbsd.host (78.142.178.22); Mon, 09 Nov 2020 12:05:12 +0100 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2020 11:05:26 -0000 --Apple-Mail=_70371D62-E66B-4312-8CAA-81C92965D02C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, I am reading thru the discussion and trying to summarize + my comments: > On 09.11.2020, at 05:35, Erik Kline 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 wrote: >=20 >> On Sat, Nov 07, 2020 at 12:45:09PM +0100, Robert Raszuk wrote: >> Ok 3 octets to keep byte boundary sounds reasonable indeed. >=20 > 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. >=20 > -Ben Correct, if we want a 3 octets (or 20-bits) length we need to = =E2=80=9Cre-invent the wheel=E2=80=9D =3D we need to add a new = =E2=80=9Coperator=E2=80=9D 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.=20 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=20 (numeric_op len=3D10). 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). How can we continue? Cheers=20 Christoph --Apple-Mail=_70371D62-E66B-4312-8CAA-81C92965D02C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 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#sectio= n-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 =E2=80=9Cre-invent the wheel=E2=80=9D= =3D we need to add a new =E2=80=9Coperator=E2=80=9D 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. 

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=3D10).

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).

How can we continue?

Cheers 

Christoph


= --Apple-Mail=_70371D62-E66B-4312-8CAA-81C92965D02C--