Re: [Detnet] PREOF signaling

Toerless Eckert <> Wed, 16 February 2022 17:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8EAA83A1447 for <>; Wed, 16 Feb 2022 09:36:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.869
X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EOdZbGrEpvir for <>; Wed, 16 Feb 2022 09:36:24 -0800 (PST)
Received: from ( [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 207643A1444 for <>; Wed, 16 Feb 2022 09:36:23 -0800 (PST)
Received: from ( [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 (Postfix) with ESMTPS id C9175549C7C; Wed, 16 Feb 2022 18:36:16 +0100 (CET)
Received: by (Postfix, from userid 10463) id B65114EA68A; Wed, 16 Feb 2022 18:36:16 +0100 (CET)
Date: Wed, 16 Feb 2022 18:36:16 +0100
From: Toerless Eckert <>
To: "Pascal Thubert (pthubert)" <>
Cc: "" <>
Message-ID: <>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <>
Archived-At: <>
Subject: Re: [Detnet] PREOF signaling
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussions on Deterministic Networking BoF and Proposed WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 16 Feb 2022 17:36:29 -0000

Pascal, *:

Thanks a lot for the HbH header work!

(Q: Remind me, which one is the UDP encap ?)

The HbH header document has a lot of interesting, but quite novel ideas that
should further be discussed. In general i think we should separate the data
model we want for DetNet services from the encapsulation, aka: create one
document where we define the desired data model (in an extensible fashion),
and then one or more encapsulations reusing the same data model.

Ideally the encapsulation documents would not need to be updated when we add
more data model items, e.g.: by use of appropriate registry definition. Aka:
the encoding rules should come from the registry or be pre-defined for all
supportable data-model extensions.

Wrt to the data items proposed:

- In MPLS we have other than just 32/8 bit sequence number counters, so i think
  we should have a data model which is a superset of what we have in MPLS to
  ease migration.

- The text is a bit euphemistic on the use of timestamps instead of sequence
  numbers (great marketing ;-). I think for fairness it should mention also key downsides:

  - It does not permit to detect loss

  - The elimination function becomes much harder to implement at high speeds,
    because efficient methods of matching duplicates (bitmasks for sequence
    number spaces) cannot be used.

Overall, i think that timestamps for PREOF would be even more of a new DetNet QoS
feature as T-CQF is for bounded latency (draft-eckert-detnet-mpls-tc-tcqf), which does
not even introduce new packet headers, but just new algorithms inside the

Aka: I am all for being more innovative in DetNet, but our really very conservative
and very well vetted T-CQF mechanism has not been making progress in DetNet for
about 4 years now, so i would really appreciate if we would also consider
that such long waiting work would be taken care of in the WG. Especially (and this
is another linkage to your draft) when we would start introducing new data-models
and not taking the data items required for example for T-CQF also into account).


On Sun, Feb 13, 2022 at 08:22:00AM +0000, Pascal Thubert (pthubert) wrote:
> Dear WG
> The HbH draft is soon to expire, and I do not see that we had a deep discussion and a consensus on which kind of signaling will work best for DetNet IPv6.
> We have a proposal to encapsulate over UDP, which appears ready for adoption, and one to use IPv6 extension headers, which is ready to expire; arguments on the table include:
> Size of the encapsulation
> Complexity of silicon implementation
> Reuse of MPLS design
> IP version independence
> DetNet and SRv6
> Flow vs path (the pipe and the water)
> I believe that each of those topics deserves a solid discussion before the group jumps on the UDP solution. The wrong decision now could mean a lot of wasted effort in the future.
> Regards,
> Pascal
> Début du message transféré :
> De: IETF Secretariat <>
> Date: 13 février 2022 à 09:04:11 UTC+1
> À:
> Objet: Expiration impending: <draft-pthubert-detnet-ipv6-hbh-06.txt>
> The following draft will expire soon:
> Name:     draft-pthubert-detnet-ipv6-hbh
> Title:    IPv6 Options for DetNet
> State:    I-D Exists
> Expires:  2022-02-25 (in 1 week, 4 days)

> _______________________________________________
> detnet mailing list