Re: [Teas-ns-dt] Definitions draft review

["Belotti, Sergio (Nokia - IT/Vimercate)" <[e-mail]>]

Hi Kiran,
Thanks for reply.
See in line , but I’m substantially agree with your reply and the intent for some cases to make a clean up wording.
Available for any help.

Thanks
Sergio

From: Kiran Makhijani <[e-mail]>
Sent: Wednesday, February 5, 2020 12:43 AM
To: Belotti, Sergio (Nokia - IT/Vimercate) <[e-mail]>; [e-mail]
Subject: Re: [Teas-ns-dt] Definitions draft review

Thanks Sergio,
Please see inline for [KM]. If you are ok with the replies, I can coordinate with Shunsuke to make suggested edits.

From: Teas-ns-dt <[e-mail]<mailto:[e-mail]>> on behalf of "Belotti, Sergio (Nokia - IT/Vimercate)" <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, February 4, 2020 at 6:56 AM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: "Belotti, Sergio (Nokia - IT/Vimercate)" <[e-mail]<mailto:[e-mail]>>
Subject: [Teas-ns-dt] Definitions draft review

Hi all,
Here my comments to the draft draft-nsdt-teas-transport-slice-definition-01.

Introduction

  *   It is used the term “partitioning” that has a clear and well defined definition in other SDO, e.g. ITU-T in G.800/G.805 (section 5.3..2) , not sure in IETF. So, my suggestion would be or to change term e.g. “separation” could be used, or make a reference of a clear definition (as I reported) .
 [KM] I would prefer to keep the term partitioning as it is generally well understood and take the second option to find a good reference with in IETF docs or we could one in this I.D.
[SB] ok. I saw Adrian’s mail remember me that e.g. RFC 8453 use the term partition as equivalent of slice to indicate slice of network resources , that is your case in the introduction. I’m ok with that.
Section 3


  *   “The types of nodes used in any of these networks may include…”

I was wondering looking at the list of “types of nodes” if Service Functions like firewall or Application servers can be mentioned as nodes.

 [KM] Yes. They are (covered under endpoints section).

Section 4



  *   4.1
     *   Transport slice definition : already provided pull request https://github.com/teas-wg/teas-ns-dt/pulls<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fteas-wg%2Fteas-ns-dt%2Fpulls&data=02%7C01%7Ckiranm%40futurewei.com%7C455dab1b1975428e726008d7a9825cc4%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637164249688149296&sdata=oqsx0Hm71DCmFLa8Pr35KbW9Unvf44sUCvvbKb0CemQ%3D&reserved=0>
  *   4.2
     *   “The managing entity realizing a transport slice is referred to as realizing network operator in this document”. The sentence seems to me a bit unclear.
     *   “A transport slice is built with a combination of specific technologies on the basis of request from a higher operations system”. Maybe it is possible to simplify sentence “A transport slice is built on the basis of request from a higher operations system.” . The fact that transport slice can be realized by different technology has been already said in the text , no need for repetition.

[KM] Ok.

[SB] Are you ok also to reword the sentence above (first bullet)?

  *   4.2.2
     *   “The TSC carries the mapping to specific technologies for its realization.”. I think TSC is “providing” or “creating” the mapping to technology , since at NBI it will receive technology-agnostic information by user/orchestrator, but based on these requirements can choose the correct mapping towards right technology.

BTW this section is absolutely necessary but probably more feasible for a framework document than for a definition draft.

[KM] This is a good observation. I think “maintains” will be better.  Here’s my understanding:

Looking at the Fig 3. Slice orchestrator asks for a transport slice from TSC which uses SBI to network controller and requests to get a connectivity. For example, TSC asks controller  “I have 2 EPs with IP addresses  IP-1 and IP-2, give me link between them  with latency 10 ms and call it L-1. TSC just needs to maintain a cookie (called L-1) from network controller. It does not need to know the details of realization between EP-1 and EP-2. But network controller need to know this. So mapping of L-1 to actual connections is in network controller.

[SB] I think the sentence has to be moved to TSC Southbound (second bullet ). This is the point I was trying to address.



  *   5.1
     *   SLA discussion:   I think wording is a bit unclear. I suppose the concept is that IETF scope is to define TS in line with specific parameters representing the SLO. Is it correct my understanding? If yes my suggestion would be to simplify a bit the wording.

[KM]: Ok. I will think about simpler text and run through with you first. Our intent was to explain why we chose SLO in TS definition not SLA.



     *   Isolation discussion: this part seems to me a bit in contrast with other IETF draft already mentioned here e.g. draft-ietf-teas-enhanced-vpn, in which isolation is characterized as one of the basic requirement for a transport slice. Here the message is not so clear maybe it is just a problem of wording, but not so sure to have got the final message of this text.

[KM] enhanced VPN was independently written before this work. During NS-DT meetings, some members did not consider isolation as important – especially for the definitions draft. We wanted to capture that a transport slice need not specify that it needs “isolation” as an objective because it is inherent to underlying technology e.g. tunnel gives some isolation. So saying soft/hard isolation is not important as long as other SLOs such as bandwidth, latency, throughput, path-selection, encryption, security etc. are met. I will try to clean up the text here a bit. But I have a feeling that this topic will be raised again in framework discussion.

[SB] I’m fine with your explanation and I’m free to help to clean up if you want.

-Kiran



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]<mailto:[e-mail]>