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

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