Re: [Teas-ns-dt] More comments on the definitions draft (part 2)

[Kiran Makhijani <[e-mail]>]

Hi Jari,
Thanks for review – certain points are not straight forward and up for discussion. What I don’t discuss here, please  assume them resolved.

In my mind the scope of the definitions document is 3 part a) define the transport slice concept, b) explain it,  c) identify relevant components (NBI, SBI, bidirectional, async fit here).


  1.  Sections 4.2.1 and 4.2.2: (on NBI and SBI)- I continue to worry that you’re trying to specify the framework.
When defining things in relation to transport slices, we identify a functional entity (transport slice controller) to explain the concept. I felt we need to further identify (hence define) the logical channels - NBI and SBI over which information will flow. Framework still has a lot to do – in terms of what type of data/operations need to go over those interfaces. If it helps, and Reza agrees, I can remove the figure – since the framework document uses it.


  1.  I think the “bidirection and async” part could be interpreted in multiple different ways.
Obviously we have data models and programmability in mind here. Existing YANG models are pull-based and provision information one way, but we need a better programmable and somewhat dynamic interface. If a fault occurs YANG-push will be needed to augment existing models. Asynchronous is to allow non-blocking mechanisms – again programmability related.

I personally feel bidirectional is important and Async was added recently on Jeff’s comments.
Would is work to clarify this in a sentence rather than removing it?


  1.  I also don’t believe terms hard and soft isolation are well defined

I can’t resolved this before deadline and need some clarifications -  will open an issue to track.

Thanks again,

Kiran


From: Jari Arkko <[e-mail]>
Date: Thursday, March 5, 2020 at 7:59 AM
To: Kiran Makhijani <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: More comments on the definitions draft (part 2)

Section 4.2:

4.2.  Transport Slice Structure

Very good otherwise, but please delete:

   As shown in Figure 1, an E2E network slice might have one or more of
   "Transport Slices" and one or more of "Other Slices" of any
   combinations.

As that really should be independent of your discussion of what is a transport slice.

   The interface to higher operations systems should
   be technology-agnostic, and slice customers don't need to recognize
   concrete configurations based on the technologies (e.g being more
   declarative than imperative).

I think you are trying  to say that whatever you request should be
agnostic, not that the interface on which you request things is
actually agnostic. E.g., you could request “100 Mbit/s connection between
A and B” but send this request over a HTTP2 interface with YANG or XML-based
data objects describing your bandwidth requirement.

How about this:

   The interface to higher operations systems should express the needed
   connectivity in a technology-agnostic way, and slice customers don't need to recognize
   concrete configurations based on the technologies (e.g being more
   declarative than imperative).

Sections 4.2.1 and 4.2.2:

I continue to worry that you’re trying to specify the framework. Why do we have two
documents? What in your view should the framework say beyond this?

More specific comments on text:

     The TSC Northbound Interface is a
      bidirectional and an asynchronous interface between a higher level
      System

I think the “bidirection and async” part could be interpreted in multiple different ways. Are you talking about logical aspects, e.g., either one can tell the other one something? Or about a specific realization of this interface? But one could still have for instance both sides be able to call the other side synchronously (as an RPC call) even if both sides can initiate an action. But I’m not sure we need to get to this level of detail.

Suggestion: delete those words.

Section 5:

5.  Transport Slice System Characteristics

It feels like this should come earlier in the document, right after the definition, because we’re talking about the SLOs in the definition.

Section 5.1:

Good stuff.

Section 5.1.1:

This needs to be framed just as the other characteristics in 5.1. I also don’t believe terms hard and soft isolation are well defined, as for instance, specific resource reservation is not required for a guarantee against bandwidth not being available.

Jari