Re: [Teas] Comments to draft-liu-teas-transport-network-slice-yang-01 Mon, 23 November 2020 08:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4C4883A0A4D; Mon, 23 Nov 2020 00:02:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.017
X-Spam-Status: No, score=-0.017 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id b9ygzibLD-rZ; Mon, 23 Nov 2020 00:02:51 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AC7F53A0B8B; Mon, 23 Nov 2020 00:02:50 -0800 (PST)
Received: from (unknown []) by Forcepoint Email with ESMTPS id 103A7418F1409E1BB939; Mon, 23 Nov 2020 16:02:45 +0800 (CST)
Received: from (unknown []) by Forcepoint Email with ESMTPS id DFAC9295646F4A27C0B3; Mon, 23 Nov 2020 16:02:44 +0800 (CST)
Received: from ([]) by with SMTP id 0AN82hOO093325; Mon, 23 Nov 2020 16:02:43 +0800 (GMT-8) (envelope-from
Received: from mapi (njxapp02[null]) by mapi (Zmail) with MAPI id mid203; Mon, 23 Nov 2020 16:02:43 +0800 (CST)
Date: Mon, 23 Nov 2020 16:02:43 +0800 (CST)
X-Zmail-TransId: 2afa5fbb6ca30806ac19
X-Mailer: Zmail v1.0
Message-ID: <>
In-Reply-To: <>
Mime-Version: 1.0
From: <>
To: <>
Cc: <>, <>
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: 0AN82hOO093325
Archived-At: <>
Subject: Re: [Teas] =?utf-8?q?Comments_to_draft-liu-teas-transport-network-sl?= =?utf-8?q?ice-yang-01?=
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 23 Nov 2020 08:02:53 -0000

Hi Xufeng,

Thank you for considering my comments.

Please see my response in-line below.

Best regards,



抄送人;TEAS WG;
日 期 :2020年11月20日 05:55
主 题 :Re: [Teas] Comments to draft-liu-teas-transport-network-slice-yang-01

Teas mailing list


Thanks for the review and comments. We have posted an updated document, addressing some of your comments.

Some replies are in-line below.
- Xufeng

On Wed, Oct 28, 2020 at 4:18 AM <> wrote:

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? 

[Xufeng]:  This model is technology-agnostic, and the parameter set is the area that we need to complete. We have put a TODO note in Sec 4. However, the performance parameters that you listed above have already been covered in other models, such as RFC8795 and Therefore, it is expected that other models would be used together with this model to achieve certain features and capabilities if such models are available and can be used together.

[Xueyan]: Agree that the data model for IETF network slice is technology-agnostic. But do you mean the performance parameters (i.e., SLO requirements) are technology-specific? It may also raises two questions: (1) If there are no SLO requirements carried in IETF network slice data model, how to map these service requirements to a technology-specific data model, such as TE topology. (2) The IETF network slice can be considered as a network topology based on service requirements from customers, a network topology data model with no SLO parameters may not be enough. What do you think? Appreciate for your any response.

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. 

[Xufeng]: Thanks for the comment. We have updated the draft to reference the newer version of GSMA NG.116.

[Xueyan]: Thank you.

Appreciate it for your response.

Best regards,