[Detnet] DetNet: Please consider draft-eckert-6man-qos-exthdr-discuss-00 -> 6MAN

Toerless Eckert <tte@cs.fau.de> Mon, 04 March 2024 22:55 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
X-Original-To: detnet@ietfa.amsl.com
Delivered-To: detnet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F8B8C14F711 for <detnet@ietfa.amsl.com>; Mon, 4 Mar 2024 14:55:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.66
X-Spam-Level:
X-Spam-Status: No, score=-1.66 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=no autolearn_force=no
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 GKyjzmliVvhg for <detnet@ietfa.amsl.com>; Mon, 4 Mar 2024 14:55:53 -0800 (PST)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F338DC180B40 for <detnet@ietf.org>; Mon, 4 Mar 2024 14:55:52 -0800 (PST)
Received: from faui48e.informatik.uni-erlangen.de (faui48e.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:51]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTPS id 4TpYvT0550znkNC for <detnet@ietf.org>; Mon, 4 Mar 2024 23:55:49 +0100 (CET)
Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id 4TpYvS6PBXzkn1d; Mon, 4 Mar 2024 23:55:48 +0100 (CET)
Date: Mon, 04 Mar 2024 23:55:48 +0100
From: Toerless Eckert <tte@cs.fau.de>
To: detnet@ietf.org
Message-ID: <ZeZRdNh0hIsjKWFX@faui48e.informatik.uni-erlangen.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/ocrU3NlBSe0HcVRolHVcAwq9-V0>
Subject: [Detnet] DetNet: Please consider draft-eckert-6man-qos-exthdr-discuss-00 -> 6MAN
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Discussions on Deterministic Networking BoF and Proposed WG <detnet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/detnet>, <mailto:detnet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/detnet/>
List-Post: <mailto:detnet@ietf.org>
List-Help: <mailto:detnet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/detnet>, <mailto:detnet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Mar 2024 22:55:55 -0000

Dear colleagues

We have just posted subject draft with the intent to start a discussion about a framework for
common IPv6 extension headers for IPv6, primarily to make it easier to create extension headers in support
of DetNet functions. Both PREOF and potentially related end-to-end functions we might want to have as well
as hop-by-hop 'stateless' processing which we are discussing in detnet.

One of the goals would be to reduce the complexity of getting IETF to accept not only standard, but also
experimental, informational or even externally specified QoS metadata in IPv6 packet headers by
writing all the common requirements and behaviors once in a common (standards track) header format RFC
so that individual new algorithms/functions would only need to describe their algorithmic deltas (such
as their metadata).

The owner of such header specification  is of course the 6MAN WG in the IETF. So if you are
interested in the effort as someone wanting to easier get DetNet function support in IPv6, then please
chime in on the thread i started on the 6MAN mailing list ipv6@ietf.org

Btw: when trying to collect the information about the QoS mechanisms proposed in DetNet, i also found that
our drafts are not really well describing the exact desired processing of packet metadata and its format.
So i think it also helps for refining our own specs to be faced with the actual packetization questions.

Examples are timestamps we have as metadata in some proposals and how to deal with e.g.: wraparound if
we do not want to carry e.g.: full 64 bit timestamps, but only (IMHO sufficient) 32 bit ones..

I have asked the DetNet chairs for a slot to present the idea also in DetNet as FYI.

Cheers
    Toerless