IETF Logo Mail Archive

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

Christoph Loibl <c@tix.at> Mon, 09 November 2020 11:05 UTC

Return-Path: <c@tix.at>
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 <c@tix.at>) id 1kc4z2-00024p-3R; Mon, 09 Nov 2020 12:05:12 +0100
From: Christoph Loibl <c@tix.at>
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, 09 Nov 2020 12:05:09 +0100
In-Reply-To: <CAMGpriUQU5JbsZ+8CUcPCJQM+U0R0EcMa-Riy-Sf7YEVuo7wnw@mail.gmail.com>
Cc: Robert Raszuk <robert@raszuk.net>, Benjamin Kaduk <kaduk@mit.edu>, "idr@ietf. org" <idr@ietf.org>, The IESG <iesg@ietf.org>, draft-ietf-idr-flow-spec-v6@ietf.org, idr-chairs@ietf.org
To: Erik Kline <ek.ietf@gmail.com>
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>
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: <https://mailarchive.ietf.org/arch/msg/idr/luEilWuDYk5e6kFadAKeupI7gT4>
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 11:05:26 -0000

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. 

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

How can we continue?

Cheers 

Christoph

v2.29.0 | Report a Bug | By Email | System Status