Re: [Detnet] liaison response to ITU-T SG13 LS217

Toerless Eckert <> Sat, 13 November 2021 03:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D334A3A0FDE for <>; Fri, 12 Nov 2021 19:08:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.369
X-Spam-Status: No, score=-0.369 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_ABOUTYOU=0.5, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id P_gIL6VyvUNM for <>; Fri, 12 Nov 2021 19:08:24 -0800 (PST)
Received: from ( [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4E6DF3A0FDC for <>; Fri, 12 Nov 2021 19:08:23 -0800 (PST)
Received: from ( []) (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 C1F6854804B; Sat, 13 Nov 2021 04:08:16 +0100 (CET)
Received: by (Postfix, from userid 10463) id AC9124E9D8C; Sat, 13 Nov 2021 04:08:16 +0100 (CET)
Date: Sat, 13 Nov 2021 04:08:16 +0100
From: Toerless Eckert <>
To: Janos Farkas <>
Cc: DetNet WG <>
Message-ID: <>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <>
Archived-At: <>
Subject: Re: [Detnet] liaison response to ITU-T SG13 LS217
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: Sat, 13 Nov 2021 03:08:29 -0000


Thanks a lot for the writeup.

I find this liaison exchange standalone cumbersome
and most likely not very useful by by itself. You found
a couple of technical points and gave them a few more pointers,
but will that affect anything on their side ? (btw.: i don't
have access to Y.3113, so i can't judge what you wrote, but
i am sure its correct)

Maybe a bit tongue in cheek, but fundamentally honest:

" Thank you for your liaison. Upon reading your documents, we
  think that DetNet has technology solution compoments for
  many of the requirements you describe in your documents.
  We look forward to see DetNet being adopted by your members
  with the help of your specifications.
  If there more specific questions about DetNet and/or
  gaps you identify in it to meet your requirements, we encourage
  your participants to bring those questions and discussion points
  directly to the DetNet WG. We are also always open to look into
  organizing workshops for a more structured ToI and/or discussion
  about DetNet. "
In other words: why not market/explain DetNet to them and/or have them tell
us what we're missing. For example upon scanning their
documents i saw them discussing an aggregation function/component,
which Pascal also is interested in. So it might be useful for
more DetNet folks to identify if anything theyve written can serve
as additiona evidence for gaps we have.

And wrt to Toi: Last time we had good overview
of DetNet was in Bangalore (joint meeting with TSN), so not a bad time to think having
a similar event again.

And doing it virtually might actually reach
more people than in-person, especially when we do it on IETF
webex and make it easy to attend. As i said, there is likely a
larger research community out there working on TSN that we might
attract as well if we spend a bit of time upfront to market
the event to researchers and are careful with the timing so
its useful for such type of attendees.


On Fri, Nov 12, 2021 at 02:09:38PM +0000, Janos Farkas wrote:
> WG,
> As we discussed this week, we suggest responding to the liaison we received from ITU-T SG13:
> Several of us worked on an initial draft proposal as contributors, see below.
> Please review and comment.
> Regards,
> János and Lou
> Dear Colleagues,
> The Internet Engineering Task Force (IETF) Deterministic Networking (DetNet) Working Group (WG) appreciates your liaison statement informing us about your work. We would like to take the opportunity to inform you about our work and share some of our observations on the work referenced in your Liaison

> For those not familiar with the IETF DetNet WG, a description of its charter cand be found at The WG defines technology for Internet Protocol (IP) and Multiprotocol Label Switching (MPLS) networks to achieve bounded latency, including upper and lower bound, i.e., bounded packet delay variation (sometimes referred to as jitter), bounded loss, and high availability/reliability. The DetNet WG collaborates with the IEEE 802.1 Time-Sensitive Networking (TSN) Task Group (TG) to define a common architecture for both Layer 2 and Layer 3.

> As a Layer 3 routed technology, one of the benefits of DetNet is that it provides desired deterministic characteristics at a larger scale than TSN. We would also like to point out that the way of working in the WG is evolutionary, from addressing more tractable problems towards more complex problems. We would like to inform you that the first phase of DetNet standards is mature, the majority have been published, see:  Considering your interest on large scale networks, we note the WG has already begun work on addressing larger scale networks. For example, see and

> We note that DetNet work appears to not be reflected  in either ITU-T Y.3113 or the Draft Recommendations attached to your liaison. Draft Recommendation ITU-T Y.IMT2020-jg-lsn references the use of the time-stamping function of RTP, UDP and TCP, implying the use case is IP packets, whereas the statement in this Draft (and ITU-T Y.3113) says, "Routing and upper layer functions lie outside the scope of this Recommendation". It is not clear if this solution is targeted to IP networks. As we have explained above, the DetNet WG is chartered by the IETF to provide bounded latency solutions for IP networks.

> The definition of domain (3.2.2 in ITU-T Y.3113 and ITU-T Y.IMT2020-fa-lg-lsn) cites RFC 8655, "Deterministic Networking Architecture". However, this definition of domain is different than RFC 8655, which focuses on the capabilities of the nodes, not their administrator. The definition of "large scale" in the provided documents is  "16 or more relay nodes". It is not clear where the number 16 is derived as a definition of a large-scale network. Please note that the DetNet WG defined solutions have no specific node count limitations and are support networks with more than 16 hops.

> We note that ITU-T Y.IMT2020-jg-lsn relies on a solution published in a Journal, and timestamping each packet of data flows. We suggest consulting IETF experts in the Timing over IP Connection and Transfer of Clock (tictoc) WG. We also note other relevant work in ITU-T SG15/Q13, IEEE 1588, IEEE 802.3, and IEEE 802.1.
> As the IETF's Liaison statement to ITU-T-TSAG ( expressed, if the intent of this work covers IETF technologies, requirements or proposals, it is requested for solution work to be discussed in IETF before any work in other SDOs. The success of standardization efforts is dependent on collaboration among the SDOs, as opposed to duplication of efforts and multiple diverging solutions, which will not benefit the industry. We welcome all interested parties to join our efforts.

> _______________________________________________
> detnet mailing list