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

[Eric Gray <[e-mail]>]

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 <[e-mail]> On Behalf Of LUIS MIGUEL CONTRERAS MURILLO
Sent: Thursday, February 6, 2020 7:59 AM
To: Rokui, Reza (Nokia - CA/Ottawa) <[e-mail]>; Kiran Makhijani <[e-mail]>; Belotti, Sergio (Nokia - IT/Vimercate) <[e-mail]>; [e-mail]; Jari Arkko <jari.arkko=[e-mail]>
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:[e-mail]> on behalf of Jari Arkko <mailto:jari.arkko=[e-mail]>
Sent: Thursday, February 6, 2020 12:14:03 PM
To: Rokui, Reza (Nokia - CA/Ottawa) <mailto:[e-mail]>; Kiran Makhijani <mailto:[e-mail]>; Belotti, Sergio (Nokia - IT/Vimercate) <mailto:[e-mail]>; mailto:[e-mail] <mailto:[e-mail]>
Subject: Re: [Teas-ns-dt] Definitions draft review 
 
Rez, Kiran, Sergio, see below in Green:
 
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.
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.
 
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
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?
 
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.
 
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: 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
 

________________________________________

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