Re: [tsvwg] Advance notice on request to poll TSVWG for adoption of draft-kaippallimalil-tsvwg-media-hdr-wireless-03

Alex Burr <alex.burr@ealdwulf.org.uk> Sat, 28 October 2023 21:36 UTC

Return-Path: <alex.burr@ealdwulf.org.uk>
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 38257C14CF1E for <tsvwg@ietfa.amsl.com>; Sat, 28 Oct 2023 14:36:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.105
X-Spam-Level:
X-Spam-Status: No, score=-7.105 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ealdwulf.org.uk
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mG4VZJl8bEh3 for <tsvwg@ietfa.amsl.com>; Sat, 28 Oct 2023 14:36:06 -0700 (PDT)
Received: from mail-4018.proton.ch (mail-4018.proton.ch [185.70.40.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CDADC14CF1B for <tsvwg@ietf.org>; Sat, 28 Oct 2023 14:36:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ealdwulf.org.uk; s=protonmail3; t=1698528963; x=1698788163; bh=XiRwwX5pShllHW1bn0ljnLT6MhDXOn+n4xMH1kIhhoQ=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=RBMazttClQ9th/YbLA38EAWWjmFZ25FNf/CRdILhr4tSXkCSqiZs3C3F8MWcFAAEg w/FbF7KDBVluYQRbpAPNkQWgReG+Vf8pwYcAs4K6gNoilOCmS5Zqy68WnqYfwX2Ml+ VRUAsYjI6FWr+W1HWVHAMg8i17U/YnjdPOthamRDoBRzUz2FQkVaBg98qfBB4MHtVw 5UNfT3gjYvsubGKJHrCM8q8VgmNB3EwQmS1FMh62jPCIMAILCNbDTvgbyQo3KSJb7z l2c+57flpVXJhl5ZodK9piWojq5T4KTlK06KxRMoHe1OcK6xaxlnefdlj/Ef/vgz/b h8M7c/Da6sZUw==
Date: Sat, 28 Oct 2023 21:35:46 +0000
To: "C. M. Heard" <heard@pobox.com>
From: Alex Burr <alex.burr@ealdwulf.org.uk>
Cc: Kaippallimalil John <john.kaippallimalil@futurewei.com>, Sri Gundavelli <sgundave@cisco.com>, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>, Joe Touch <touch@strayalpha.com>, TSVWG <tsvwg@ietf.org>
Message-ID: <PSwe6NFEkjRcgVQfIHJ-n_YuRvXsM6IVLhSqmJi20a9Iz5CbqkgArZq-2UtXNF5c6t5cjeOkJPYdcMO0q9qr8GA2xVyz_EFCHP3DRAaIoH8=@ealdwulf.org.uk>
In-Reply-To: <CACL_3VFvjNXGWh3jUg7b21z6f8uWQr8aKe_Lok+gqt-_jy1XKg@mail.gmail.com>
References: <CAKKJt-cr7e5pUR=zxaO35Tjn2d=oM-xBvpdyGop+xaLOG-_U9g@mail.gmail.com> <CALx6S34__pK8tTM08fzTAxx=_dAM4MsEwH1-RL7eXGrCdtnR1Q@mail.gmail.com> <7E9754EA-9A11-49F6-A3F2-3F5E630CEBA6@strayalpha.com> <SN4PR13MB5311CF46AF56025360252C3AE8DCA@SN4PR13MB5311.namprd13.prod.outlook.com> <CALx6S378sTLPzis3=qB07OvojjbCTV8St21-31_oZzsUNZ-5vA@mail.gmail.com> <3D728108-E440-4625-BC4F-F1D134C1BD63@gmx.de> <CALx6S36G3s6UjfLXoxdotGoJaaQgXDhBCTVJi=j8=NhQQDUMWw@mail.gmail.com> <CACL_3VFvjNXGWh3jUg7b21z6f8uWQr8aKe_Lok+gqt-_jy1XKg@mail.gmail.com>
Feedback-ID: 48452497:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/co-RoVgfNsVJDi9qpDPZJIgXHAM>
Subject: Re: [tsvwg] Advance notice on request to poll TSVWG for adoption of draft-kaippallimalil-tsvwg-media-hdr-wireless-03
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.39
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: Sat, 28 Oct 2023 21:36:11 -0000

Hi all,

What if, instead of implementing network options 
piecemeal as UDP options, there were instead defined a UDP option which
just encapsulates the whole HBH  extension header, to get it past nodes that
would drop it?

This would have the following advantages:

- rather than taking away energy from getting HBH options to work, it would
add to it.

- The spec for this 'HBH header encapsulation  option' could recommend that
network nodes which processes HBH options inside  it, SHOULD also process the 
same options if found in an unencapsulated HBH extension header. In this way,
those nodes would be ready if  HBH options end up being transmissible over the
internet.
 
- It would consume only one UDP option type, instead of one per function. All
 'network options' would be enumerated in one place, in the HBH options list.

- If the HBH header sees greater  use in this way, it would provide an 
argument for enabling  it to pass unencapsulated.

NB I don't specifically have an opinion on  whether the media header should be an HBH
option. But if it should be, maybe this is a useful way of resolving the difficulty of
avoiding packets containing it being dropped.

Alex