[Detnet] Re: a comment on draft-eckert-detnet-tcqf
peng.shaofu@zte.com.cn Wed, 14 January 2026 02:08 UTC
Return-Path: <peng.shaofu@zte.com.cn>
X-Original-To: detnet@mail2.ietf.org
Delivered-To: detnet@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 1BD4FA756B07 for <detnet@mail2.ietf.org>; Tue, 13 Jan 2026 18:08:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=unavailable autolearn_force=no
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Z5WfBqgJoB7 for <detnet@mail2.ietf.org>; Tue, 13 Jan 2026 18:08:29 -0800 (PST)
Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [160.30.148.35]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 5BC79A756AEE for <detnet@ietf.org>; Tue, 13 Jan 2026 18:08:29 -0800 (PST)
Received: from mse-fl2.zte.com.cn (unknown [10.5.228.133]) (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 mxhk.zte.com.cn (FangMail) with ESMTPS id 4drTzt5HBzz8Xs6v; Wed, 14 Jan 2026 10:08:26 +0800 (CST)
Received: from njy2app02.zte.com.cn ([10.40.13.116]) by mse-fl2.zte.com.cn with SMTP id 60E28ITl073313; Wed, 14 Jan 2026 10:08:18 +0800 (+08) (envelope-from peng.shaofu@zte.com.cn)
Received: from mapi (njb2app07[null]) by mapi (Zmail) with MAPI id mid201; Wed, 14 Jan 2026 10:08:19 +0800 (CST)
X-Zmail-TransId: 2aff6966fa9355a-d5e99
X-Mailer: Zmail v1.0
Message-ID: <202601141008192610wPhbA8wppcSYTCk-A38Y@zte.com.cn>
In-Reply-To: <AS8PR07MB95671BDC528FD9F1E0BF2BBAF28EA@AS8PR07MB9567.eurprd07.prod.outlook.com>
References: AS8PR07MB95679D1434EFB34FC34C3886F284A@AS8PR07MB9567.eurprd07.prod.outlook.com,AS8PR07MB95671BDC528FD9F1E0BF2BBAF28EA@AS8PR07MB9567.eurprd07.prod.outlook.com
Date: Wed, 14 Jan 2026 10:08:19 +0800
Mime-Version: 1.0
From: peng.shaofu@zte.com.cn
To: Janos.Farkas=40ericsson.com@dmarc.ietf.org
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-fl2.zte.com.cn 60E28ITl073313
X-TLS: YES
X-SPF-DOMAIN: zte.com.cn
X-ENVELOPE-SENDER: peng.shaofu@zte.com.cn
X-SPF: None
X-SOURCE-IP: 10.5.228.133 unknown Wed, 14 Jan 2026 10:08:26 +0800
X-Fangmail-Anti-Spam-Filtered: true
X-Fangmail-MID-QID: 6966FA9A.000/4drTzt5HBzz8Xs6v
Message-ID-Hash: EPXRECZ3CSMNILWEWYXAQBW3ISQ2WQ4F
X-Message-ID-Hash: EPXRECZ3CSMNILWEWYXAQBW3ISQ2WQ4F
X-MailFrom: peng.shaofu@zte.com.cn
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-detnet.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: detnet@ietf.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [Detnet] Re: a comment on draft-eckert-detnet-tcqf
List-Id: Discussions on Deterministic Networking BoF and Proposed WG <detnet.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/Sdc_Nby9E00Z0Z_fXVXK2vQT-ic>
List-Archive: <https://mailarchive.ietf.org/arch/browse/detnet>
List-Help: <mailto:detnet-request@ietf.org?subject=help>
List-Owner: <mailto:detnet-owner@ietf.org>
List-Post: <mailto:detnet@ietf.org>
List-Subscribe: <mailto:detnet-join@ietf.org>
List-Unsubscribe: <mailto:detnet-leave@ietf.org>
Hi Janos, Agree with your observation for "tagged" that CQF uses ethernet VLAN tag.PCP mapping to specific IPV values for CQF flows. I think that the encoding method of all EDP solutions can be commonly defined in a separate document, e.g., MPLS encoding commonly defined in draft-ietf-mpls-mna-detnet-00, IPv6 encoding defined in draft-eckert-6man-qos-exthdr-discuss, although both two documents need more detailed specificaitons. If this opinion is acceptable, the title of each EDP solution reflect its scheduling principle, rather than encoding method. However, I also think this modificaiton and other possible actions may be done based on the adopted documents. Regards, PSF Original From: JanosFarkas <Janos.Farkas=40ericsson.com@dmarc.ietf.org> To: DetNet WG <detnet@ietf.org>; Date: 2026年01月13日 17:37 Subject: [Detnet] Re: a comment on draft-eckert-detnet-tcqf _______________________________________________ detnet mailing list -- detnet@ietf.org To unsubscribe send an email to detnet-leave@ietf.org Hi, I wonder what is the preference of the group? Are distinct names preferred? Thanks and regards, János From: Janos Farkas Sent: Wednesday, January 7, 2026 11:53 PM To: 'draft-eckert-detnet-tcqf@ietf.org' <draft-eckert-detnet-tcqf@ietf.org> Cc: DetNet WG <detnet@ietf.org> Subject: a comment on draft-eckert-detnet-tcqf Hi, I have a comment on the title of the document, the name of the mechanism / draft: Tagged Cyclic Queuing and Forwarding (TCQF) The draft refers to Cyclic Queuing and Forwarding (CQF) specified in Annex T of IEEE Std 802.1Q-2022. CQF described therein is based on VLAN-tagged frames. That is, the CQF of 802.1Q is tagged CQF. Therefore, I’m afraid that the Tagged Cyclic Queuing and Forwarding (TCQF) terminology applied in draft-eckert-detnet-tcqf is not distinctive enough. If draft-eckert-detnet-tcqf gets adopted by the DetNet WG, then I’d suggest a distinct name and title for the WG document, e.g., Labelled Cyclic Queuing and Forwarding (LCQF) or some other one. Regards, János
- [Detnet] a comment on draft-eckert-detnet-tcqf Janos Farkas
- [Detnet] Re: a comment on draft-eckert-detnet-tcqf Janos Farkas
- [Detnet] Re: a comment on draft-eckert-detnet-tcqf peng.shaofu