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

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

Hi Reza,
Thanks for reply, I share basically your view, just few comments below , in particularly on TSC process.

Thanks
Sergio


From: Rokui, Reza (Nokia - CA/Ottawa) <[e-mail]>
Sent: Wednesday, February 5, 2020 4:41 PM
To: Kiran Makhijani <[e-mail]>; Belotti, Sergio (Nokia - IT/Vimercate) <[e-mail]>; [e-mail]
Cc: Rokui, Reza (Nokia - CA/Ottawa) <[e-mail]>
Subject: Re: [Teas-ns-dt] Definitions draft review

Thanks Sergio for your comments.

See inline please.

Reza

From: Teas-ns-dt <[e-mail]<mailto:[e-mail]>> on behalf of Kiran Makhijani <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, February 4, 2020 at 6:43 PM
To: Sergio Belotti <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[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.
[Reza] Agreed that partitioning is better in this context..
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).

[Reza] In addition to this, my suggestion is to add “5G RAN nodes” and “5G Core nodes” to section 5.2.1 “Transport type EP”  as well since they both have IP forwarding engine

SB> Good point , I agree



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.

[Reza] I tend to agree with Sergio. The term “realizing network operator” is not well defined in the document.

My suggestion is to add this to 4.2.1.  Stakeholders and to define it



     *   “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.

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

[Reza] TSC does not creating the mapping but rather uses the existing mapping.

The idea is to provide various mapping to any technology to TSC ahead of time. This provides a tremendous flexibility to existing or even future technology to realize the Transport Slices.

When TSC receives a request to create a Transport Slice, this request optionally will have various technology agnostic polices to help TSC to decide which mapping to use.

At the end TSC should decide which mapping function to use. The details of this logic needs to be discussed in other draft such as framework draft..

I will add more detail on this topic to section “Controller” of Framework draft.

SB> The question that comes up is how and who is providing to TSC the mapping ahead of time. In the ACTN architecture , RFC 8453, MDSC controller providing a mapping functions taking customer request/commands from customer  and translating those information into a set of parameters specific to a network type and technology so that network configuration can be possible. I think there is a lot of similarity in the process but this mapping process is made internally to MDSC.





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

[Reza] Sergio, there were a few discussions with Eric and others about term SLO vs. SLA. As mentioned by Kiran, the main objective of this sub-section is to clarify why we use term SLO. Is this the case in other IETF drafts as well, i.e. differentiating between SLO and SLA?

SB> Not for my knowledge. But it is good that can be provided here.



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

-Kiran

[Reza] Good point Sergio. I am adding to above response. The isolation is one of the attribute of SLO. How it is realized in the network might be different among Operators and also might vary with the technology to realize the transport slice. For example, using the dedicated network function might be one potential solution to realize the isolation. Or having primary and secondary path completely independnet might be another way. In summary, similar to B/W, latency etc., isolation is one of the attribute of the SLO and is not related to how it is realized in the network.

SB> I’m totally agree with you.



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