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

[Jari Arkko <[e-mail]>]

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