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

Xufeng Liu <xufeng.liu.ietf@gmail.com> Wed, 09 December 2020 01:53 UTC

Return-Path: <xufeng.liu.ietf@gmail.com>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F02153A0AB3; Tue, 8 Dec 2020 17:53:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iyR_IHlQTmzC; Tue, 8 Dec 2020 17:53:20 -0800 (PST)
Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C98E33A0AB4; Tue, 8 Dec 2020 17:53:19 -0800 (PST)
Received: by mail-ej1-x62c.google.com with SMTP id bo9so647796ejb.13; Tue, 08 Dec 2020 17:53:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MLjmJ68G8WEsosg4kzkNstHEDzdXzpeTEuK1hEq3PwM=; b=K7SQfvA6C/pVNtH8PazEP+aa1QsuaJAOThiCz7GEdQY+4bLQRpSxp7kAxb0TkusI58 JQftTGkK/8YDpTPpWAsqozI2hsHbk1TTeMTlT/NUANqeHdo61urxhfqEDCGiXgPu6C+m ZP90D80K1H+2H1vH56LBXZ6cjXBLnzaFjiZw/c1WmfXQ++k2vrgNTGxfSl1XaUdQFvtN ovi3D1tkmxezRfczoZ+kVgpy11q0mzfAxgWmK/QdNj9iVAKOwyujLUv9cUrdk3LGgwAK Oj9FegtG/a0wvuMCsa0F0KoyuAJiYY2pH5i8+5iD0+XnVlNS2rMNWMYx2d8bgzLIYKQj GE8A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MLjmJ68G8WEsosg4kzkNstHEDzdXzpeTEuK1hEq3PwM=; b=AY6KMOeWMphSIPozQhGqigREkpZjNk59FVZjH0v94Cv4VXWr+9cu7Wn19HNCP098b9 IDF0dTDk0TLZxgf4fjxmMrEPj2oKoOFFXNUMCcUch4giqwemEiiCrgMKzjM7ciSWxXaK eq4Rv3hKOGb2CRL7pjGxLmMtA7a4hcomNDi65f1mYHdtFAKqgMRFLFKJRWu0drfXOIQW S1g1OA47g4/s5SA574adFUNwMGecTpv4uLkUpCvO/uB0l36ubY8/FnMxcZ9oJOk3+w5I QxX48T+K0lFeqZ3bWvA0lsbHkBcs4n9gmh3eOpms4Lt/W//n/AWBIaQ61IHszdWLayey btbQ==
X-Gm-Message-State: AOAM532c0zD1ySA38zwbdEBhf6v7TE6pTSPDcTVV3dgUd7KrHHFy4VND hlyrElls9Qbdg1BQNKSCMNEqq66HpAax7+LKCic=
X-Google-Smtp-Source: ABdhPJwFlnaHALzSOSHKmr3FIRmM8c2AZfkZNR08wgwezcsI83Zw3Y+fVrxzBSGTEgiWeuZrk+n5v5KmeP1Mw87CBJI=
X-Received: by 2002:a17:906:c007:: with SMTP id e7mr135087ejz.511.1607478798220; Tue, 08 Dec 2020 17:53:18 -0800 (PST)
MIME-Version: 1.0
References: <CAEz6PPTBeYJUARPP2EJWdbSS=RtuADxiQRgHr8z4Cm__5NLQRw@mail.gmail.com> <202011231602434987455@zte.com.cn>
In-Reply-To: <202011231602434987455@zte.com.cn>
From: Xufeng Liu <xufeng.liu.ietf@gmail.com>
Date: Tue, 8 Dec 2020 20:53:07 -0500
Message-ID: <CAEz6PPTtKFuxhs=e4NMo6iAAE8uK8ezT5nQqqxmRRi4AWkS=5A@mail.gmail.com>
To: song.xueyan2@zte.com.cn
Cc: draft-liu-teas-transport-network-slice-yang@ietf.org, TEAS WG <teas@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000c081a505b5fe52c1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/LVztgUT72GmhkoWHiGpR--fxtPo>
Subject: Re: [Teas] Comments to draft-liu-teas-transport-network-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, 09 Dec 2020 01:53:22 -0000

Hi Xueyan,

Thanks for your comments. I have put some replies in-line below.
Regards,
- Xufeng

On Mon, Nov 23, 2020 at 3:02 AM <song.xueyan2@zte.com.cn> wrote:

> Hi Xufeng,
>
>
> Thank you for considering my comments.
>
> Please see my response in-line below.
>
>
> Best regards,
>
> Xueyan
>
>
>
> 原始邮件
> *发件人:*XufengLiu
> *收件人:*宋雪雁00038118;
> *抄送人:*draft-liu-teas-transport-network-slice-yang@ietf.org;TEAS WG;
> *日 期 :*2020年11月20日 05:55
> *主 题 :**Re: [Teas] Comments to
> draft-liu-teas-transport-network-slice-yang-01*
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas
>
> Xueyan,
>
> Thanks for the review and comments. We have posted an updated document
> https://tools.ietf.org/html/draft-liu-teas-transport-network-slice-yang-02,
> addressing some of your comments.
>
> Some replies are in-line below.
> Thanks,
> - Xufeng
>
> On Wed, Oct 28, 2020 at 4:18 AM <song.xueyan2@zte.com.cn> 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
> <https://tools.ietf.org/html/draft-ietf-teas-yang-l3-te-topo>
> https://tools.ietf.org/html/draft-ietf-teas-yang-l3-te-topo. 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?
>
[Xufeng] Depending on the specific parameters, many requirements are
technology-specific. The general rules are to leave technology-specific
parameters to the technology augmentation and to specify
technology-agnostic parameters here. We are still in the process of
collecting technology-agnostic parameters.

> 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.
>
[Xufeng]: The document has given two examples of such mappings.

> (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?
>
[Xufeng]: There are always SLO parameters from the requirements. To be
generalized, the best- effort connectivity can be considered to be a
parameter.

> 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,
>>
>> Xueyan
>>
>>
>>
>>
>>
>>
>