Re: [Detnet] WG adoption poll:draft-liu-detnet-large-scale-requirements-05

Peng Liu <liupengyjy@chinamobile.com> Sun, 11 December 2022 07:37 UTC

Return-Path: <liupengyjy@chinamobile.com>
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 401BFC14CE40 for <detnet@ietfa.amsl.com>; Sat, 10 Dec 2022 23:37:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.884
X-Spam-Level:
X-Spam-Status: No, score=-1.884 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_FACE_BAD=0.001, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham 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 sqtTSfBaRo6M for <detnet@ietfa.amsl.com>; Sat, 10 Dec 2022 23:37:49 -0800 (PST)
Received: from cmccmta1.chinamobile.com (cmccmta1.chinamobile.com [221.176.66.79]) by ietfa.amsl.com (Postfix) with ESMTP id 84A31C14CEE0 for <detnet@ietf.org>; Sat, 10 Dec 2022 23:37:46 -0800 (PST)
X-RM-TagInfo: emlType=0
X-RM-SPAM-FLAG: 00000000
Received: from spf.mail.chinamobile.com (unknown[172.16.121.83]) by rmmx-syy-dmz-app04-12004 (RichMail) with SMTP id 2ee4639588c7376-fc8c5; Sun, 11 Dec 2022 15:37:43 +0800 (CST)
X-RM-TRANSID: 2ee4639588c7376-fc8c5
X-RM-TagInfo: emlType=0
X-RM-SPAM-FLAG: 00000000
Received: from CMCC-LP (unknown[120.244.156.38]) by rmsmtp-syy-appsvrnew02-12027 (RichMail) with SMTP id 2efb639588c4549-6168b; Sun, 11 Dec 2022 15:37:42 +0800 (CST)
X-RM-TRANSID: 2efb639588c4549-6168b
Date: Sun, 11 Dec 2022 15:37:36 +0800
From: Peng Liu <liupengyjy@chinamobile.com>
To: "xiong.quan" <xiong.quan@zte.com.cn>, "kiran.ietf" <kiran.ietf@gmail.com>
Cc: "Janos.Farkas" <janos.farkas@ericsson.com>, detnet <detnet@ietf.org>
References: <202212082225472246393@zte.com.cn>
X-Priority: 3
X-GUID: C5F0A220-2C67-4C7E-BBFE-37FE4F9AB071
X-Has-Attach: no
X-Mailer: Foxmail 7.2.21.453[cn]
Mime-Version: 1.0
Message-ID: <20221211153735557921109@chinamobile.com>
Content-Type: multipart/alternative; boundary="----=_001_NextPart036013510083_=----"
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/wGIqt-XGp-bUfnNafqa68p1R4u4>
Subject: Re: [Detnet] WG adoption poll:draft-liu-detnet-large-scale-requirements-05
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: Sun, 11 Dec 2022 07:37:53 -0000

Hi Quan,

Thanks for providing the gap analysis. Here are some comments for it. 

1. Section 5.2 " But these functions can not provide the deterministic latency ", maybe it is better to say 'these functions are not sufficient to provide the deterministic latency'. 
2. Section 5.2.1. There are several points of the 4 paragraphs you mentioned, such as:
'end-to-end delay and jitter are not enough in path computation'——'use multiple network metrics', 
'compute the best path in multi domains is difficult'——'deterministic routes need to be provisioned' and ' consider the bounded latency when selecting the path'  ,
'the real-time change of the network topology'——'should be programmed' and 'pre plan in control plane'
'generate two disjoint paths with very close delay'
           So my questions/comments to this sub section are: 
Why it is not enough to use delay and jitter as metrics and what else metrics should be used in your opinion?
The topology change is more common in large scale network but not to the point of frequent occurrence.
Most of them seems requiring pre planning/establishment of a large-scale detnet, which are good for deterministic networking itself but not sure to be the necessary work of the WG.
I hope that the text could be more clear to point out what are caused by the large scale or what are the gap of the current detNet but not only for the large-scale detnet. Moreover, you can use the same structure wording to make them more clear to be understood. In your presentation in interim meeting, you can list them as key points to be discussed for more feedback of the WG. If some of them could/should be merged into the large-scale detnet requirements drafts, more consensus are expected.

Regards,
Peng


liupengyjy@chinamobile.com
 
From: xiong.quan@zte.com.cn
Date: 2022-12-08 22:25
To: kiran.ietf@gmail.com; liupengyjy@chinamobile.com
CC: janos.farkas@ericsson.com; detnet@ietf.org
Subject: Re: [Detnet]WG adoption poll:draft-liu-detnet-large-scale-requirements-05
Hi Kiran and Peng,
 
Thanks for your comments and it is an important issue which needs to be discussed in details.
I presented and discussed the gap analysis at IETF 115 DetNet meeting. And now I splited this out and submitted a new draft [1] to discuss the characteristics of large-scale networks and analyzes the gaps of the existing technologies especially applying the DetNet data plane as per RFC8938. 
 
For the large-scale networks, the two characteristics should be existed simultaneously including Large-scale Dynamic Flows and Large-scale Network Topology. And the Large-scale Network Topology may be include:
*large number of nodes and links
*High speed, long-distance transmission and asymmetric links
*multiple domains
*nodes may be interconnected with different sub-network technologies
 
For the gap between the existing DetNet solutions and requirement of large-scale networks, the following aspects should be considered.
*Gap of Providing Aggregated Flows Identification in service sub-layer
~it requires large amount of control signaling to establish and maintain DetNet Data Plane DetNet per-flows or aggregated flows.
*Gap of Providing Deterministic Latency in forwarding sub-layer
~Explicit Routes, it will be challenging to compute paths due to the multiple network metrics and frequent topology changes; loose routes, inter-domain routes and multiple disjoint paths should be considered in large-scale networks.
~Resources Allocation, the resource scheduling should be supported for rational allocation ensuring deterministic latency including using underlying technologies.
~Enhancement of queuing-based mechanisms and the related DetNet-Specific Metadata should be provided to guarantee the bounded latency.
 
Hope that will help to make a clarification for the large-scale networks and why current DetNet should be enhanced.
 
[1]https://datatracker.ietf.org/doc/draft-xiong-detnet-enhanced-detnet-gap-analysis/
 
Best Regards,
Quan
 
 
<Hello Chairs, 
<I support the adoption of large-scale requirements work as a working group document. It covers several interesting scenarios which should be discussed on how Detnet will be supported in diverse set of cases.
< I am struggling to put them under the context of ‘large-scale’ networks. What authors refer to as large-scale here to me are a set of scenarios emerging  due to heterogeneity and  not necessarily the scale itself. There are 3 categories associated to the large-scale detnets in this document - per-hop variance, scale of flows, and domain-stitching. Except for flows, other two do not directly imply large-scale. 
<So I have not fully bought into the title of the document. Additionally, will it be possible to discuss how ‘current' Detnet solution does not support ‘large-scale’ scenario, and whether this is still in single administrative domain or multiple or kind of federated domains collaborating for a detent service. This could server as the purpose of this document. I will try to send my detailed comments to the list in a couple of days. 
< Cheers, Kiran
 
_______________________________________________
detnet mailing list
detnet@ietf.org
https://www.ietf.org/mailman/listinfo/detnet