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

[[e-mail]]

Hi Xufeng,






Thank you for considering my comments.


Please see my response in-line below.






Best regards,


Xueyan











原始邮件



发件人：XufengLiu
收件人：宋雪雁00038118;
抄送人：[e-mail];TEAS WG;
日 期 ：2020年11月20日 05:55
主 题 ：Re: [Teas] Comments to draft-liu-teas-transport-network-slice-yang-01


_______________________________________________
Teas mailing list
[e-mail]
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 <[e-mail]> 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. 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,



Xueyan