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

Jeffrey Haas <jhaas@pfrc.org> Mon, 16 November 2020 07:53 UTC

Return-Path: <jhaas@slice.pfrc.org>
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 7813B3A13F7; Sun, 15 Nov 2020 23:53:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.415
X-Spam-Level:
X-Spam-Status: No, score=-0.415 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FAKE_REPLY_C=1.486, SPF_PASS=-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 2CtdpRCaTAl8; Sun, 15 Nov 2020 23:53:16 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id C20213A15D1; Sun, 15 Nov 2020 23:53:01 -0800 (PST)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 33CAA1E354; Mon, 16 Nov 2020 03:09:02 -0500 (EST)
Date: Mon, 16 Nov 2020 03:09:01 -0500
From: Jeffrey Haas <jhaas@pfrc.org>
To: Benjamin Kaduk <kaduk@mit.edu>, Christoph Loibl <c@tix.at>
Cc: "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: <20201116080901.GI2881@pfrc.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <E70A15BB-5C6C-447A-832C-571D413139E3@tix.at> <20201109205805.GY39170@kduck.mit.edu>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/dYoD1FGSJu14Kmm-VoZrdirE8vM>
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, 16 Nov 2020 07:53:18 -0000

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.

-- Jeff