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

Xufeng Liu <> Thu, 19 November 2020 21:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AC3E63A12B5; Thu, 19 Nov 2020 13:55:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iM_pSaFXR1Dt; Thu, 19 Nov 2020 13:55:09 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::535]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C3FF73A12B8; Thu, 19 Nov 2020 13:55:08 -0800 (PST)
Received: by with SMTP id v22so7432842edt.9; Thu, 19 Nov 2020 13:55:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gBpWoSGmC2vlSRI3lfPdpIvKT5e9WZqmrJ5DL/CDl4E=; b=T/iRDnfj9skU2AOsAE0RdOXzoh/3KFxnX1uvFhy8Xvy70dAtEEy37UyC5AAmCtep/Z Hlpk77MCNY9IQ+xXaybE0FpaYYIfhvT/sBfaZoLQQ//JCbopQHpPjSFqpimzueuZs9Yl 3ytHOTXe3h/LXhVDdH3EuOoVSGofa8ms5b1pVNNofGdlmnXADqy0/7C5cNZXnPGonCN2 V+QiFNcnNEpztVdW47hWUgPATdf0V1wymv+HxW1IbedExsK1MEX7Jdby+pVLI/sAgEkO KgsJiv43cg08+3CmieuNdnjQdq0+tgtnhej4gisYHqWJ5dkC07t2s5yJ/9gBRIUp1SOb xPjw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gBpWoSGmC2vlSRI3lfPdpIvKT5e9WZqmrJ5DL/CDl4E=; b=mUcVYiGKelFQm0DXPGqKJgXnocBmgRH1a2mZH7Z9Vjtz3EDc8O0taPlzmsCB8qQ96O Z0XZCvFX/7ftKgnad8PFtu+DhqwN/xSdqazkM081QZoUKwrLXiypK7tPwkIYI7DBmhvv Jq4/jqquhQpqMwLw7RU9GAll0lYOz+uW+j2udqoeIF20XL6TFdnHIK4h9D8WKKrdYPtK h74qGGMcjTMFONgRh5fF2073FWo75C2JSqKrei5ZTirQ6XIF9M1sp4MR22w9mlnodgII /ro88JmEpeOrImeL1V0at0xU+BfP+IuG9ExfsuUtKf98/5Lf1b12nEliuc6NKG0ZVYD0 ww6g==
X-Gm-Message-State: AOAM531S7MsG31gqOr1GYNskuWFJQj5zepHV6ZZ9FQK1FwmuXk37Dzo+ EOp+Y0PjZ9/nqkw2su2IGEVbgZILeZS6FcpNXzU=
X-Google-Smtp-Source: ABdhPJzonzXkiz9G/DbQjxXA2gjbtk3dv+y7IddpfAv3BJ5zFM4rjA8/ysLoS+0vUE2t+LlxHo+UI3jPtfoY+jgQAUU=
X-Received: by 2002:a50:ccdb:: with SMTP id b27mr10444080edj.253.1605822907201; Thu, 19 Nov 2020 13:55:07 -0800 (PST)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Xufeng Liu <>
Date: Thu, 19 Nov 2020 16:54:55 -0500
Message-ID: <>
Cc:, TEAS WG <>
Content-Type: multipart/alternative; boundary="000000000000f4bbbc05b47cc71c"
Archived-At: <>
Subject: Re: [Teas] Comments to draft-liu-teas-transport-network-slice-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: Thu, 19 Nov 2020 21:55:11 -0000


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.

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.

> Appreciate it for your response.
> Best regards,
> Xueyan