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

["Rokui, Reza (Nokia - CA/Ottawa)" <[e-mail]>]

Hi Sergio,

As per our discussion yesterday, authors decided not to use " transport-slice-selection-policy" and instead to use the concept of "slo-tag" which is a tag agreed upon between TSC and higher orchestration system. The concept is very similar to use of path profile for example in PECP. We will discuss this in our next NSDT meeting.

Cheers,
Reza


-----------------------------------------------
On 2020-04-22, 5:36 AM, "Teas-ns-dt on behalf of Wubo (lana)" <[e-mail] on behalf of [e-mail]> wrote:

    Hi Sergio,

    Thanks for the discussion.

    About the technical-specific parameter of the TS endpoint, for example, bearer technologies and protocols need to be agreed on between a CE and a PE of a TS, then the TSC may distinguish, during mapping, whether to use an L2VPN or an L3VPN to instantiate a slice.

    I'm not sure whether these are the same ones with Reza's " transport-slice-selection-policy".

    Thanks,
    Bo
    -----邮件原件-----
    发件人: Belotti, Sergio (Nokia - IT/Vimercate) [mailto:[e-mail]] 
    发送时间: 2020年4月21日 23:43
    收件人: 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,
    Thanks for you kind reply, that clarify most of my doubts.
    For your last question regarding " whether Transport slice NBI model will not define technology-specific parameters on TS endpoint", wasn't the proposed " transport-slice-selection-policy" from Reza one possibility to provide more technology-specific parameters ? Just a question for my understanding.

    Thanks
    Sergio

    -----Original Message-----
    From: Wubo (lana) <[e-mail]> 
    Sent: Tuesday, April 21, 2020 11:00 AM
    To: Belotti, Sergio (Nokia - IT/Vimercate) <[e-mail]>
    Cc: Jari Arkko <jari.arkko=[e-mail]>rg>; [e-mail]
    Subject: Re: Solicit comments on updated draft-wd-teas-transport-slice-yang-01

    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
    -- 
    Teas-ns-dt mailing list
    [e-mail]
    https://www.ietf.org/mailman/listinfo/teas-ns-dt