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

From: "Belotti, Sergio (Nokia - IT/Vimercate)" <[email-masked]>
Date: Tue, 4 Feb 2020 14:55:36 +0000

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

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.

Section 4

  *   4.1
     *   Transport slice definition : already provided pull request https://github.com/teas-wg/teas-ns-dt/pulls
  *   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.
  *   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.

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

Thanks

Sergio

Sergio Belotti
Senior System Engineer and Standardization Architect
IP/Optical Networks, Optics BU
Nokia
M: +39-335761776
Via Energy Park, 20871 Vimercate (MB) , Italy
[email-masked]<mailto:[email-masked]>

---

From: Kiran Makhijani <[email-masked]>
Date: Tue, 4 Feb 2020 23:43:24 +0000

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 <[email-masked]> on behalf of "Belotti, Sergio (Nokia - IT/Vimercate)" <[email-masked]>
Date: Tuesday, February 4, 2020 at 6:56 AM
To: "[email-masked]" <[email-masked]>
Cc: "Belotti, Sergio (Nokia - IT/Vimercate)" <[email-masked]>
Subject: [Teas-ns-dt] Definitions draft review

Hi all,

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

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

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

  *   5.1

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

[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

Thanks

Sergio

Sergio Belotti

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 5 Feb 2020 12:00:50 -0000

Partition seems, to me, to be a regular English word that indicates breaking up into sub-components or areas of responsibility.

For example…

8453 uses the term “partition” fairly freely and equates it with “slice”, but has no explicit definition.

8283 has a whole section on “Partitioned Network”

7926 talks about partitioning networks

7698 talks about partitioning resources (in a GMPLS sense)

7579 talks about partitioning switch matrices

7524 talks about partitioning end-to-end paths

7420 mentions a physical router being portioned into multiple virtual routers

7356, 6992 and 6981 talk about a topology being partitioned in the classic sense of broken into two disconnected pieces

7348 talks about partitioning traffic

Etc.

There is a special case meaning that is common (as in 7356) when applied to a network, but otherwise it just means divided up.

Best,

Adrian

-------

Introduction

---

From: "Belotti, Sergio (Nokia - IT/Vimercate)" <[email-masked]>
Date: Wed, 5 Feb 2020 14:29:28 +0000

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 <[email-masked]>
Sent: Wednesday, February 5, 2020 12:43 AM
To: Belotti, Sergio (Nokia - IT/Vimercate) <[email-masked]>; [email-masked]
Subject: Re: [Teas-ns-dt] Definitions draft review

Thanks Sergio,

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

Hi all,

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

Section 4

  *   4.1

[KM] Ok.

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

  *   4.2.2

[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

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

-Kiran

Thanks

Sergio

Sergio Belotti

---

From: "Rokui, Reza (Nokia - CA/Ottawa)" <[email-masked]>
Date: Wed, 5 Feb 2020 15:40:55 +0000

Thanks Sergio for your comments.

See inline please.

Reza

From: Teas-ns-dt <[email-masked]> on behalf of Kiran Makhijani <[email-masked]>
Date: Tuesday, February 4, 2020 at 6:43 PM
To: Sergio Belotti <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Teas-ns-dt] Definitions draft review

Thanks Sergio,

Hi all,

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

[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

Section 4

  *   4.1

[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

[KM] Ok.

  *   4.2.2

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

  *   5.1

[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?

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

Thanks

Sergio

Sergio Belotti

---

From: Kiran Makhijani <[email-masked]>
Date: Thu, 6 Feb 2020 07:22:23 +0000

Hello Sergio,
Many thanks for helping to improve the text. I made some refinements as per the discussion. Please find both XML and .txt file attached.
If you are interested changes between original (00) and mine (02),  you could use
https://tools.ietf.org/rfcdiff    draft-nsdt-teas-transport-slice-definition-02.txt and
https://raw.githubusercontent.com/teas-wg/teas-ns-dt/master/definitions/draft-rokui-teas-transport-slice-definition-00.txt

We will also update github soon.
-Kiran

From: "Belotti, Sergio (Nokia - IT/Vimercate)" <[email-masked]>
Date: Wednesday, February 5, 2020 at 6:29 AM
To: Kiran Makhijani <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: [Teas-ns-dt] Definitions draft review

Hi Kiran,
Thanks for reply.

Thanks
Sergio

Thanks Sergio,

Hi all,

Introduction

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%7C8d819c3965ac4d890aed08d7aa47d066%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637165097745284580&sdata=C7qLp8m91Pz7f0Pe0q0z2UcUpEQ8ZAw0T%2F7O1Oj9wZM%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.

  *   4.2.2

  *   5.1

-Kiran

Thanks

Sergio

Sergio Belotti

---

From: "Belotti, Sergio (Nokia - IT/Vimercate)" <[email-masked]>
Date: Thu, 6 Feb 2020 10:39:35 +0000

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

See inline please.

Reza

From: Teas-ns-dt <[email-masked]<mailto:[email-masked]>> on behalf of Kiran Makhijani <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, February 4, 2020 at 6:43 PM
To: Sergio Belotti <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Teas-ns-dt] Definitions draft review

Thanks Sergio,

Hi all,

Introduction

SB> Good point , I agree

Section 4

  *   4.1

[KM] Ok.

  *   4.2.2

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

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

-Kiran

SB> I’m totally agree with you.

Thanks

Sergio

Sergio Belotti

---

From: Jari Arkko <[email-masked]>
Date: Thu, 6 Feb 2020 11:14:03 +0000

Rez, Kiran, Sergio, see below in Green:

4.2.2

Jari: I suppose there’s actually two distinct things here. There needs to be a “recipe” or algorithm for a mapping, that is developed beforehand. Then there’s the actual mapping of a specific abstract slice to a specific concrete slice with specific concrete tech(s). For instance, that a particular label or VPN label is used, what nodes are involved, etc.

Would be good if you folks added something to the framework draft on this!

  *   5.1

Jari: I think they key from my point of view is that we need to define the concepts we use, no matter what they are called. At least in an earlier version of the definition draft the SLO/SLA concept was defined but in rather loose manner. I think ultimately we’ll need to define it more concretely, e.g., an SLO is a specific data structure defined in RFCs such and such that can be used to represent specific conditions.

-Kiran

Jari: What Kiran said was right. I may sound like a broken record ☺ but 1. slices are about a number of characteristics and 2. we need to define our concepts with a set of concrete networking-related characteristics at the level of a requirement rather than implementation. I’m thinking more along the lines of “I want two connections between A and B, such that connections provide at least 1000 mbit/s best effort/guaranteed bandwidth such that there is no physical sharing of any network segment or node except A or B for those two connections”,  than simply saying “I want isolated connections”.

Jari

---

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Thu, 6 Feb 2020 12:58:44 +0000

Hi Jari,

Regarding your point on isolation. I think you're referring more to disjointness among the connections requested in the intent than isolation. Isolation relates to the relationship of the requested services with respect to others in place.

Future services requesting transport slicing could request different levels of isolation, as anticipated already by some 5G cases. Additionally, different transport technologies will be able to provide different levels of isolation (from physical to logical). Thus I see convenient to consider this as part of the transport entity in charge of provisioning the transport slices. Otherwise the logic of selecting which transport technology to use (for satisfying different levels of isolation) should be outside such entity, which I think is not a good strategy since then some transport information (i.e. capabilities) should be exposed at the northbound.

Best regards

Luis

Obtener Outlook para Android<https://aka.ms/ghei36>

________________________________
From: Teas-ns-dt <[email-masked]> on behalf of Jari Arkko <jari.arkko=[email-masked]>
Sent: Thursday, February 6, 2020 12:14:03 PM
To: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>; Kiran Makhijani <[email-masked]>; Belotti, Sergio (Nokia - IT/Vimercate) <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [Teas-ns-dt] Definitions draft review

4.2.2

  *   5.1

-Kiran

Jari

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Thu, 6 Feb 2020 15:29:54 +0000

Hi Luis and Jari ,

I also think isolation is something more than path disjointness. Path disjointness could be one way to achieve isolation, while there could be other approaches, which gives the slice consumer different levels of isolation at different granularity. Thus it would be helpful to have isolation expressed as one of the characteristics of a transport slice, then it could be reflected by using particular technology to meet the requirement.

Best regards,
Jie

From: Teas-ns-dt [mailto:[email-masked]] On Behalf Of LUIS MIGUEL CONTRERAS MURILLO
Sent: Thursday, February 6, 2020 8:59 PM
To: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>; Kiran Makhijani <[email-masked]>; Belotti, Sergio (Nokia - IT/Vimercate) <[email-masked]>; [email-masked]; Jari Arkko <jari.arkko=[email-masked]>
Subject: Re: [Teas-ns-dt] Definitions draft review

Hi Jari,

________________________________
From: Teas-ns-dt <[email-masked]<mailto:[email-masked]>> on behalf of Jari Arkko <jari.arkko=[email-masked]<mailto:jari.arkko=[email-masked]>>
Sent: Thursday, February 6, 2020 12:14:03 PM
To: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>>; Kiran Makhijani <[email-masked]<mailto:[email-masked]>>; Belotti, Sergio (Nokia - IT/Vimercate) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Teas-ns-dt] Definitions draft review

4.2.2

  *   5.1

-Kiran

Jari

---

From: Eric Gray <[email-masked]>
Date: Thu, 6 Feb 2020 16:03:31 +0000

Luis,

	This is a part of why we apparently need a definitions draft.

	The term “Isolation” has very many meanings, and certainly among them are those related to “protection isolation.”

	From a service definition perspective, protection isolation (i.e. – avoiding common or shared failure points between alternate paths) is something that has been considered for some time as a thing that it is reasonable to ask for from a service.  It is clearly less than optimal if you have alternate paths that might fail at the same time, as a result of a single failure.

	You might or might not get it, simply because you ask, but – if you have it written into the SLA – you are more likely to have legal recourse if it turns out you don’t have it.  This happens more often than people wish.

	The form of isolation that some folks are asking for now has not yet passed a “reasonableness” test, because it imposes “service implementation” requirements that:
	1) Can be explicitly met already with existing services (which many operators are trying to, or mostly already have, migrated away from);
	2) Don’t result in any cost reductions over legacy services;
	3) Can be emulated in commonly deployed networks quite well.

In short, a Transport Slice may require additional guarantees about the impact each service may experience because of other network usage, but it cannot specify how those guarantees will be met.

If what a consumer wants is TDM like guarantees, then perhaps they do not really want to move away from the TDM-based services they had previously.

--
Eric

From: Teas-ns-dt <[email-masked]> On Behalf Of LUIS MIGUEL CONTRERAS MURILLO
Sent: Thursday, February 6, 2020 7:59 AM
To: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>; Kiran Makhijani <[email-masked]>; Belotti, Sergio (Nokia - IT/Vimercate) <[email-masked]>; [email-masked]; Jari Arkko <jari.arkko=[email-masked]>
Subject: Re: [Teas-ns-dt] Definitions draft review

Hi Jari,
Regarding your point on isolation. I think you're referring more to disjointness among the connections requested in the intent than isolation. Isolation relates to the relationship of the requested services with respect to others in place. 
Future services requesting transport slicing could request different levels of isolation, as anticipated already by some 5G cases. Additionally, different transport technologies will be able to provide different levels of isolation (from physical to logical). Thus I see convenient to consider this as part of the transport entity in charge of provisioning the transport slices. Otherwise the logic of selecting which transport technology to use (for satisfying different levels of isolation) should be outside such entity, which I think is not a good strategy since then some transport information (i.e. capabilities) should be exposed at the northbound.
Best regards
Luis
Obtener https://protect2.fireeye.com/v1/url?k=2ed7824c-72038ae5-2ed7c2d7-865b3b1e120b-7ffc02092a524cb2&q=1&e=cb8e3b9e-4b1e-4f1c-b525-df66e9a9adf9&u=https%3A%2F%2Faka.ms%2Fghei36

________________________________________
From: Teas-ns-dt <mailto:[email-masked]> on behalf of Jari Arkko <mailto:jari.arkko=[email-masked]>
Sent: Thursday, February 6, 2020 12:14:03 PM
To: Rokui, Reza (Nokia - CA/Ottawa) <mailto:[email-masked]>; Kiran Makhijani <mailto:[email-masked]>; Belotti, Sergio (Nokia - IT/Vimercate) <mailto:[email-masked]>; mailto:[email-masked] <mailto:[email-masked]>
Subject: Re: [Teas-ns-dt] Definitions draft review 

4.2.2
o “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.

• 5.1
o 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?

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

Jari

________________________________________

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 6 Feb 2020 21:53:20 -0000

Oh, if only someone had written about isolation in a working group draft. Perhaps we an find it described in draft-ietf-teas-enhanced-vpn-04.txt

Adrian (who is still wondering what percentage of draft-ietf-teas-enhanced-vpn will end up in the DT drafts :-)

-----Original Message-----
From: Teas-ns-dt <[email-masked]> On Behalf Of Eric Gray
Sent: 06 February 2020 16:04
To: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>; Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>; Kiran Makhijani <[email-masked]>; Belotti, Sergio (Nokia - IT/Vimercate) <[email-masked]>; [email-masked]; Jari Arkko <jari.arkko=[email-masked]>
Subject: Re: [Teas-ns-dt] Definitions draft review

Luis,

--
Eric

Hi Jari,

 
4.2.2

• 5.1

 
 
Jari

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição
-- 
Teas-ns-dt mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/teas-ns-dt