[Teas] Comments to draft-liu-teas-transport-network-slice-yang-01

song.xueyan2@zte.com.cn Wed, 28 October 2020 08:18 UTC

Return-Path: <song.xueyan2@zte.com.cn>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 573543A1053; Wed, 28 Oct 2020 01:18:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id AqNfm4ECNQCJ; Wed, 28 Oct 2020 01:18:39 -0700 (PDT)
Received: from mxhk.zte.com.cn (mxhk.zte.com.cn []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F09C3A1069; Wed, 28 Oct 2020 01:18:39 -0700 (PDT)
Received: from mse-fl2.zte.com.cn (unknown []) by Forcepoint Email with ESMTPS id 454D5DDBC70145972158; Wed, 28 Oct 2020 16:18:36 +0800 (CST)
Received: from njxapp05.zte.com.cn ([]) by mse-fl2.zte.com.cn with SMTP id 09S8IY3d022637; Wed, 28 Oct 2020 16:18:34 +0800 (GMT-8) (envelope-from song.xueyan2@zte.com.cn)
Received: from mapi (njxapp05[null]) by mapi (Zmail) with MAPI id mid203; Wed, 28 Oct 2020 16:18:34 +0800 (CST)
Date: Wed, 28 Oct 2020 16:18:34 +0800 (CST)
X-Zmail-TransId: 2afd5f99295a7c40435b
X-Mailer: Zmail v1.0
Message-ID: <202010281618347184473@zte.com.cn>
Mime-Version: 1.0
From: <song.xueyan2@zte.com.cn>
To: <draft-liu-teas-transport-network-slice-yang@ietf.org>
Cc: <teas@ietf.org>
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-fl2.zte.com.cn 09S8IY3d022637
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/IXgdx0vCPPCbN6AhKlCRlRrZtJw>
Subject: [Teas] =?utf-8?q?Comments_to=C2=A0draft-liu-teas-transport-netwo?= =?utf-8?q?rk-slice-yang-01?=
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Oct 2020 08:18:42 -0000

Hi Xufeng and Co-authors,

Thank you for providing the draft-liu-teas-transport-network-slice-yang. The YANG data module based on the augment of RFC8345 is clearly defined from the perspective of network-topology (including network, nodes and links) and well reflected the characteristics of IETF network slice.  

From the Module Tree Structure specified at clause 4, the delay-tolerance is added as a leaf node and set as an Optional parameter for IETF network slice, refering to "GSMA-NS-Template: Generic Network Slice Template, Version 1.0.". I have some commens here:

1. I think the parameter set is to meet the service flexible requirements of operators and I agree to use the parameter when traffic type has no critical requirements on business performance, especially for vertical services. Considering this parameter corresponding service type is not generic and specific connectivity SLO requirements need to be satisfied for an IETF network slice,  I more suggest to add performace parameters, such as: bandwidth, latency, jitter, packet loss rate, etc. Whant do you think? 

2. One minor problem is that GSMA NG.116 has been released version 3.0, I propose to use the current version as a reference. 

Appreciate it for your response.

Best regards,