IETF Logo Mail Archive

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

Christoph Loibl <c@tix.at> Mon, 16 November 2020 09:12 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 4BE463A1618; Mon, 16 Nov 2020 01:12:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, 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 yq2ImNWizKiD; Mon, 16 Nov 2020 01:12:29 -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 E870F3A1611; Mon, 16 Nov 2020 01:12:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tix.at; s=rev1; h=To:References:Message-Id:Cc:Date:In-Reply-To:From:Subject: Mime-Version:Content-Type: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=218aKwApK39ypCszgyjYmUEUhu/ohBcgSh9mAiVYrkg=; b=mX4wj5Hx9KjtHnLuvyL6Er4Y4s 2uhJWuVA60WETXXPZWhMD0hClsTlSYFPqBoPaspGGGOLwTQBWjz09d65X8iSuRh49EI1DjUTQhoMa /IcB6ZHVww+UleXtdJc1rOkRsZFcWHrmE3iJo57HEQDvk6C0vCR+CvqNf7xlXQJLpPd0kUBAAuPwZ uuQd159ntSZWTCAPKKHJ7EazSzG0rJ9+K0SMaF2jLGqGdJkskjXT4oa/u7V2FZF6oD7huoLUZzenA 5dwtZScYq0ouEmgnaZnLAYoJGkRDkoBSM/Qw5khHlXKEL0E8ifOpIBfps/oiIcBq20quA2FQrzv5P d2Ep0inw==;
Received: from 80-110-113-91.cgn.dynamic.surfer.at ([80.110.113.91] helo=[192.168.66.207]) by mail.fbsd.host with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from <c@tix.at>) id 1keaYf-000ETK-Px; Mon, 16 Nov 2020 10:12:22 +0100
Content-Type: multipart/alternative; boundary="Apple-Mail=_4220ED1A-8B4F-47A0-B8EB-A36012B590EF"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
From: Christoph Loibl <c@tix.at>
In-Reply-To: <20201116075756.GQ39170@kduck.mit.edu>
Date: Mon, 16 Nov 2020 10:12:18 +0100
Cc: Jeffrey Haas <jhaas@pfrc.org>, "idr@ietf. org" <idr@ietf.org>, draft-ietf-idr-flow-spec-v6@ietf.org, Robert Raszuk <robert@raszuk.net>, idr-chairs@ietf.org, The IESG <iesg@ietf.org>, Erik Kline <ek.ietf@gmail.com>
Message-Id: <828ACEB0-C1D8-4A83-AED5-7B9F300F0421@tix.at>
References: <E70A15BB-5C6C-447A-832C-571D413139E3@tix.at> <20201109205805.GY39170@kduck.mit.edu> <20201116080901.GI2881@pfrc.org> <20201116075756.GQ39170@kduck.mit.edu>
To: Benjamin Kaduk <kaduk@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, 16 Nov 2020 10:12:21 +0100
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/NWsiYifPM_mO0hvrWpp2OCUAm8o>
Subject: Re: [Idr] [BULK] 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, 16 Nov 2020 09:12:32 -0000

Hi,

While I (personally) would prefer something like Juniper’s implementation. rfc5575bis's consensus was the approach that we suggest an encoding length for each FS component. The current approach in flow-spec-v6 does not break this concept and is consistent also with the base FS document. As Jeffrey mentioned it is also compatible with the “use as less bits as possible” encoding approach. Thanks for the comment Jeffrey. 

I will upload a -20 today. This will fix all the nits and comments from the IESG review process.

Cheers 

Christoph 
 
-- 
Christoph Loibl
c@tix.at | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at



> On 16.11.2020, at 08:57, Benjamin Kaduk <kaduk@mit.edu> wrote:
> 
> On Mon, Nov 16, 2020 at 03:09:01AM -0500, Jeffrey Haas wrote:
>> Ben,
>> 
>> On Mon, Nov 09, 2020 at 12:58:05PM -0800, Benjamin Kaduk wrote:
>>>> 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 will note that Juniper's implementation simply goes for best-fit for any
>> given value.  While the SHOULD for 4-byte sizing won't make us
>> non-conformant, it's not what we do.  E.g. a value that can fit into one
>> byte will use that length.
>> 
>> Given the general encoding of lengths in the base flowspec document, you can
>> insist on whatever size you want for the SHOULD of the size to send, but
>> receivers need to follow Postel's maxim on receipt.
> 
> I agree.
> 
> Thanks for commenting,
> 
> Ben

v2.23.0 | Report a Bug | By Email