Re: [tsvwg] draft-ietf-udp-options issues from IETF 104

Derek Fawcus <dfawcus+lists-tsvwg@employees.org> Tue, 16 July 2019 21:04 UTC

Return-Path: <dfawcus@employees.org>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A868120168 for <tsvwg@ietfa.amsl.com>; Tue, 16 Jul 2019 14:04:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.107
X-Spam-Level:
X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 ioRPgsz1-3Kt for <tsvwg@ietfa.amsl.com>; Tue, 16 Jul 2019 14:04:27 -0700 (PDT)
Received: from clarinet.employees.org (unknown [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 393061200E7 for <tsvwg@ietf.org>; Tue, 16 Jul 2019 14:04:25 -0700 (PDT)
Received: by clarinet.employees.org (Postfix, from userid 1736) id 279D74E11AD3; Tue, 16 Jul 2019 21:04:24 +0000 (UTC)
Date: Tue, 16 Jul 2019 22:04:24 +0100
From: Derek Fawcus <dfawcus+lists-tsvwg@employees.org>
To: tsvwg <tsvwg@ietf.org>
Message-ID: <20190716210424.GA59147@clarinet.employees.org>
References: <CE03DB3D7B45C245BCA0D24327794936306138E9@MX307CL04.corp.emc.com> <CAPDqMeoyNb7vQTdqxLpZpnKb9S7QKeDJNLyQJBmq95yXhB+xfQ@mail.gmail.com> <7D365770-64FE-40BC-901D-B4D7DF6B484B@strayalpha.com> <20190713182554.GB39770@clarinet.employees.org> <CALx6S36mH2M6SYnRSecWXa7k_d1u8O43+CXE-=KqeO0x2e5+qw@mail.gmail.com> <82FF6486-FABF-4D2C-B5E2-178779C720A4@strayalpha.com> <30c17e9c174f6b0da3ecc6b503a8cb17@strayalpha.com> <CACL_3VGs7j+y5vFNT3OL9OKX8ue4rv-Cxi467KR-vbhnMdx86g@mail.gmail.com> <2f71a292f924a9b8de4227c4bbc2f809@strayalpha.com> <CACL_3VGrF5UnbVsSzZZoy1i57WKiQKBX2T3a16UyEVHY=Kr3XA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CACL_3VGrF5UnbVsSzZZoy1i57WKiQKBX2T3a16UyEVHY=Kr3XA@mail.gmail.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/g8UfRU8xYT6N9qWi3ctOZwetl98>
Subject: Re: [tsvwg] draft-ietf-udp-options issues from IETF 104
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Jul 2019 21:04:29 -0000

I need to draw some pictures to work things out, and also consider the
FRAG implications, but I'm sort of liking the general direction
of Mike's suggestions in this sub thread.

I also now need to ponder upon OCS staying an option, or being a fixed
field, since as I understand it, the current scheme suggested would
allow for a naïve scan over the surplus using the standard 16 bit
checksum (suitably initialised).

The implications for LITE data seem poor, but I guess if/when middleboxes
get fixed (or in controlled environments) LITE with no checksum coverage
could be more easily handled using the fixed position checksum (i.e. no
OCS option), if we used 0000 to represent no validation of the surplus,
and it only carried the LITE data - i.e. no other options.

DF