Subject: [Teas-ns-dt] Pull 10: Reza’s proposed text for addition to the Framework section

From: Eric Gray <[email-masked]>
Date: Wed, 25 Mar 2020 21:33:19 +0000

Pull 10: Reza’s proposed text for addition to the Framework section
There was a bit of a discussion for this Pull in GitHub comments, there seem to be other issues with the proposed figure and there was also discussion on points that overlap with other Pulls (that have already been incorporated).

I will try to capture the gist of these discussions in this E-Mail.

The discussion in GitHub (between Reza and Dhruv) was mostly about whether or not it is necessary to show multiple network controllers in the illustration (Figure 1 in Reza’s pull).

Note that this is just one issue with the proposed figure that has been raised.  Others were raised earlier.

For example, one issue already brought up with respect to this figure is that it differs (slightly) from Figure 3 in the definitions draft, under TSC Southbound Interface (SBI).  Do we need to have the same or similar figure in both drafts?

Also, there is a very similar figure in section 4 (“Applicability of ACTN to Transport Slices”) – that is used to show how the terms and concepts used in this document map to similar (or parallel) terms and concepts in ACTN work.

A couple of points have already been made in this context about the proposed text and about this figure in general:

  1.  This proposal adds text to the framework section of this framework document, yet it starts immediately with a subsection entitled “High Level Architecture.”

  1.  My earlier proposal (made on one of the calls) is that this should be changed to “High Level Description” – mostly because a framework document that jumps immediately into describing a solution – even at a high level – is missing the point;
  2.  I believe that the figure is included in this proposed addition in a slightly different form precisely because it is an attempt to represent an HLA.

  1.  It has been brought up previously that it is not clear at all why an HLA for Transport Slices would include blocks for “Customer (Tenant) portal” or “Other Slice Controller.”

It seems that the proposed figure adds only controversial “stuff” relative to figures that exist already in other closely related places, one of which is in this document.  I propose that – whatever else we do with this Pull – we should exclude this figure.

With the figure excluded, we would also need to exclude the text describing (possibly controversial aspects of) the figure.

This leaves only the subheading and first paragraph of the proposed text (with minor editorial changes), as follows:

“## High level [description of transport slice management]

“[Transport] slices are part of the one or more E2E network slices [as defined in Transport Slice Definition].  [Consequently] management and control of transport slices is part of a higher-level [system function – i.e. – putting together for example)] network functions, radio equipment, application specific components, as well as the transport slices.”

The only remaining question is “where does this go?”

This proposed text is about management, which is a specific subheading under the Framework section already (i.e. – subsection 3.1 “Management systems or other applications”).

And this text is consistent with that subsection title.

But that subsection already contains the following text:

“The transport slice system is used by a management system or other application.  These systems and applications may also be part of a higher level function in the system, e.g., putting together network functions, access equipment, application specific components, as well as the transport slices.”

The existing text essentially says the same thing – so the question is then is “is the proposed wording better?”

I think the existing text was what we came up with considering a number of comments and suggestions (likely including this Pull).  For example, “access equipment” was proposed as better than “radio equipment” because the intent is for this work to be more generally applicable than to 5G and RAN.

Hence, considering all of these points, I believe that Pull 10 is completely overcome by events and I plan to close it with no further action.

Any comments?

--
Eric