Re: [Teas-ns-dt] Solicit comments on updated draft-wd-teas-transport-slice-yang-01

["Wubo (lana)" <[e-mail]>]

Hi Sergio,

Thanks for your kindly observation and helpful comments. Please see in line with [Bo].

Regards,
Bo

-----邮件原件-----
发件人: Belotti, Sergio (Nokia - IT/Vimercate) [mailto:[e-mail]] 
发送时间: 2020年4月20日 20:59
收件人: Wubo (lana) <[e-mail]>
抄送: Jari Arkko <jari.arkko=[e-mail]>rg>; [e-mail]
主题: RE: Solicit comments on updated draft-wd-teas-transport-slice-yang-01

Hi Bo, co-authors, 

These are my not-completed review of the draft (I would need some more time to review Yang details). 

Introduction:
*	Transport Slice definition : There is a definition document , please refer to it for TS definition . The definition in this draft is hiding completely an essential part of the concept of slice that is to assure to have dedicated/shared resources to provide the connectivity between the logical end point . This is indicated in the definition draft and here reported in a different way.
*	Ts-Endpoint: while the old version of definition was a bit heavy in wording appeared to me more complete. I think a mix of the new one and old one would be better . This is my proposal " is a logical identifier at an external interface to identify the logical access to which, a particular subset of traffic traversing the external interface, is mapped to a specific TS." 
*	TS-Member: Could you elaborate a little since the definition is not totally clear. TS-member should provide the link association between the end point of a slice respecting the SLO conditions. Is correct?  In the previous version of the draft there was also this definition "A TS Member is an abstract entity which represents transport
   resources mapped to this particular Transport Slice". This is more clear definition of TS Member respect the one above that I've already mentioned. Is it possible to have only one clear definition maybe encompassing the two piece of text not losing the link to resources that is essential in slicing?
*	
[Bo] Agree, will update in the next revision as you suggested.

Section 5.1
*	The options represented confused me with respect the definition of end point. My understanding of TS End Point was that it is a logical identifier representing always the logical point to which customer traffic will be connected to a TS towards Transport Network. So TS End point has always need node-id, tp-id and ts-traffic-criteria . And in fact Yang is proposing not different options  i.e. there is no choice . So text description seems not aligned with what Yang is proposing.  

[Bo] Yes, TS End point always need node-id, tp-id and ts-traffic-criteria, the only difference is that node-id, tp-id could be CE or PE according to the scenario.
1) In the enterprise VPN scenarios, for example, when a Transport Network can obtain CE neighbor information through protocols such as LLDP, the endpoint information of CE, node ID and interface ID, could be passed from the upper-layer management system to the TSC. 
2)In some 5G scenarios, a Transport Network sometimes cannot obtain the interconnection information of the RAN or CN network. Therefore, the endpoint information of PE, node ID and interface ID, needs to be passed from the upper-layer management system to the TSC. 


*	"A number of slice interconnection parameters must be agreed with a customer site and the transport slice, and one TS End Point's attributes may not be same with another TS End Point's. " Do you mean here that the characteristics of various TS- End Point can be different one to the other ? Would be good to make some example of attributes you're referring .

[Bo] OK, we think a TS- End Point has some common technology-agnostic parameters, and some technology-specific parameters, such as physical interfaces and protocols, because access technology may be different.

What do you mean here: are you referring to TS End point configuration or TS configuration . The wording is confused .
*	"At the external Interface, the particular subset of the transport is
identified either by a separate interface or by the combination of
   interface and fields in the packet" . Which external Interface ? What do you mean with "subset of the transport "??

[Bo] OK, I will correct this, "external interface" refers to the interface to a customer site, and "subset of the transport" refers to the subset of the traffic. 

I had not too much time to review Yang details , I would need some more time. 
But these some remarks:

ts-endpoints list:

container protocol description is confused : " Describes protocal between access potin and site"
status-params: the description is ambiguous and is technology specific mentioning VPN-node

[Bo] If it is agreed that the endpoint only defines technology-agnostic parameters, I will remove these definitions. I think my question is, whether Transport slice NBI model will not define technology-specific parameters on TS endpoint.

I will complete review of Yang very soon.


Thanks
Sergio

Sergio Belotti
Senior System Engineer and Standardization Architect IP/Optical Networks, Optics BU Nokia
M: [phone]
Via Energy Park, 20871 Vimercate (MB) , Italy [e-mail]





-----Original Message-----
From: Teas-ns-dt <[e-mail]> On Behalf Of Wubo (lana)
Sent: Saturday, April 18, 2020 5:08 AM
To: Jari Arkko <jari.arkko=[e-mail]>rg>; [e-mail]
Subject: [Teas-ns-dt] Solicit comments on updated draft-wd-teas-transport-slice-yang-01

Hi Jari and all,

We have just updated the draft of Transport slice YANG data model, and hope to get your feedback.
It is available at the link https://tools.ietf.org/html/draft-wd-teas-transport-slice-yang-01 , or the attachment.

To Jari:
As the discussion of last call, could you please help us to create a new nbi-model folder on github and upload the draft to this folder?

Thanks,
Bo