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

["Dongjie (Jimmy)" <[e-mail]>]

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:[e-mail]] On Behalf Of LUIS MIGUEL CONTRERAS MURILLO
Sent: Thursday, February 6, 2020 8:59 PM
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 Outlook para Android<https://aka.ms/ghei36>

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


Rez, Kiran, Sergio, see below in Green:



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.



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

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



     *   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